이메일 헤더를 읽어 피싱 메일을 알아보는 방법

모든 이메일에는 우리가 읽는 본문 위에 헤더 영역이 있습니다. 메일 앱은 이를 숨기지만, 여기에는 메시지가 어느 서버에서 왔는지, 어느 도메인이 이를 보증했는지, 답장이 실제로 어디로 가는지가 기록되어 있습니다. 본문이 완벽해 보이는 피싱이라도 대개 여기서 정체가 드러납니다.

저희는 수신 메일 서버를 운영하기 때문에, 메시지가 이상하게 동작할 때마다 원본 헤더를 읽습니다. 이 가이드에서는 실제와 비슷한 피싱 헤더를 한 줄씩 살펴본 다음, 모든 검사를 통과하는 더 어려운 경우를 보여 드립니다. 읽으면서 가지고 있는 메시지의 헤더를 저희 이메일 헤더 분석기에 붙여넣어 보세요. 분석은 브라우저에서 이루어지며 헤더는 저희 서버로 전송되지 않습니다.

1단계: 메일 앱에서 헤더 꺼내기

모든 메일 프로그램은 기본적으로 헤더를 숨깁니다. Gmail에서는 메시지를 열고 '답장' 옆의 점 3개 메뉴를 눌러 원본 보기를 선택하세요. Outlook on the web에서는 점 3개 메뉴를 연 뒤 보기, 메시지 원본 보기를 선택합니다. Mac의 Apple Mail에서는 보기, 메시지, 모든 헤더를 차례로 선택합니다. Outlook for Windows, Yahoo 등의 메뉴 경로는 헤더 분석기 페이지에 정리되어 있습니다.

첫 번째 빈 줄 위쪽을 모두 복사하세요. 그 부분이 헤더입니다. 그 뒤에 오는 본문은 필요 없습니다. iPhone과 iPad의 기본 메일 앱은 헤더를 전혀 보여 주지 않으므로, 메시지를 컴퓨터로 전달하거나 웹메일에서 확인하세요.

피싱 메일의 헤더를 한 줄씩 읽기

다음은 계정 알림을 사칭한 전형적인 피싱 메일의 헤더를 중요한 줄만 남기고 줄인 것입니다. 도메인과 주소는 가상의 예시지만, 패턴은 저희가 반복해서 보는 그대로입니다. 헤더는 최신 항목이 위에 쌓이므로, 메시지를 나에게 전달한 서버는 위쪽에, 메시지가 출발한 곳은 아래쪽에 있습니다.

Return-Path: <[email protected]>
Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=mail.example.net;
    dkim=none;
    dmarc=fail (p=none) header.from=examplebank.com
Received: from mail.example.net (unknown [203.0.113.45])
    by mx.example.com with ESMTPS; Thu, 29 Oct 2026 09:14:07 +0000
Received: from desktop-4kq2 (unknown [198.51.100.23])
    by mail.example.net with ESMTPA; Thu, 29 Oct 2026 09:14:05 +0000
From: "Example Bank Security" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Unusual sign-in: confirm your account within 24 hours
Date: Thu, 29 Oct 2026 09:14:02 +0000
Message-ID: <20261029091402.4471@desktop-4kq2>

각 줄이 알려 주는 것

Return-Path

반송 메일이 가는 주소로, 봉투 발신자(envelope sender)라고도 합니다. 여기서는 은행 도메인이 아니라 mail.example.net입니다. 이것만으로는 별로 증명되는 것이 없습니다. 메일 발송 업체를 통해 보내는 뉴스레터도 똑같이 보이기 때문입니다. 다음 줄을 읽을 때를 위해 기억해 두세요.

Authentication-Results

메시지가 도착했을 때 내 메일 서비스가 기록한 판정입니다. SPF는 통과했지만, 공격자의 서버인 mail.example.net에 대해서입니다. DKIM 서명은 없습니다. 그리고 내가 실제로 보는 From 도메인을 확인하는 유일한 검사인 DMARC는 examplebank.com에 대해 실패했습니다. 헤더 전체에서 가장 쓸모 있는 줄이 바로 이것입니다.

Received(맨 위)

내 메일 서비스의 서버인 mx.example.com이 203.0.113.45에서 메시지를 받으면서 추가한 줄입니다. 내 메일 서비스가 쓴 줄은 믿을 수 있습니다. 그 아래는 모두 내가 전혀 모르는 컴퓨터들이 쓴 것입니다.

Received(맨 아래)

가장 오래된 단계이므로, 체인은 아래에서 위로 읽습니다. 메시지는 스스로를 desktop-4kq2라고 부르는 컴퓨터에서 시작해, 로그인된 제출(ESMTPA)로 mail.example.net에 넘겨졌습니다. 은행의 알림 시스템은 누군가의 데스크톱에서 돌아가지 않습니다. 도용했거나 빌린 메일함이라면 그렇습니다.

From

표시 이름은 Example Bank Security이고 주소는 examplebank.com이라고 주장합니다. 이 칸에는 누구나 아무것이나 입력할 수 있습니다. 위의 DMARC 실패가 이 From 줄이 위조되었다는 증거입니다.

Reply-To

'답장'을 누르면 내 답장은 세 번째 도메인인 example.org로 갑니다. 전화나 로그인을 요구하는 은행이 다른 사람의 도메인에서 답장을 받을 이유는 없습니다. 답장으로 정보를 보내라고 하는 피싱은 거의 항상 이 값을 설정합니다.

Subject와 Date

긴급함과 마감 기한의 조합입니다. Date는 보내는 컴퓨터가 주장하는 시각일 뿐이지만, Received 타임스탬프와 비교해 보세요. Date와 첫 단계 사이에 몇 시간이나 며칠의 차이가 있다면, 메시지가 도착하기 전에 스팸 대기열에 머물렀을 수 있습니다.

Message-ID

보내는 소프트웨어가 만드는 고유 ID입니다. 대기업 시스템은 자사 도메인을 붙입니다. 이 ID는 desktop-4kq2로 끝나며, 맨 아래 Received 줄에 나온 바로 그 가정용 컴퓨터입니다. 여기서의 불일치는 힌트일 뿐 증거는 아닙니다. 정상적인 소프트웨어 중에도 일반적인 ID를 쓰는 경우가 많기 때문입니다.

종합하면 이야기는 분명합니다. 은행에서 왔다고 주장하는 메시지가 데스크톱에서 낯선 사람의 메일 서버를 거쳐 발송되었고, 은행 자체의 인증에 실패했으며, 세 번째 도메인으로 답장을 받으려 합니다. 어디를 봐야 하는지 알면 1분도 안 되어 이 결론에 도달할 수 있으며, 헤더 분석기는 DMARC 실패와 Reply-To 불일치를 자동으로 표시해 줍니다.

SPF, DKIM, DMARC 쉽게 이해하기

이 세 가지 검사는 보낸 사람이 입력한 텍스트가 아니라, 받는 서버가 메시지를 검사한 뒤 기록하는 헤더 부분입니다. 각각 다른 질문에 답합니다.

SPF

이 서버는 봉투 발신자 도메인의 메일을 보낼 권한이 있는가? 도메인 소유자는 허용된 서버 목록을 DNS에 공개하고, 받는 쪽은 접속한 IP 주소를 이 목록과 비교합니다. SPF가 확인하는 것은 Return-Path 도메인이지 내가 보는 From 주소가 아닙니다. 피싱이 자기 도메인으로 SPF를 통과할 수 있는 이유입니다. 용어집의 SPF도 참고하세요.

DKIM

메시지가 어떤 도메인에 의해 서명되었고, 그 이후 변경되지 않았는가? 보내는 서버가 암호화 서명을 추가하고, 받는 쪽은 서명자의 DNS에 있는 공개 키로 이를 확인합니다. header.d= 값이 서명한 도메인을 나타냅니다. 관련 없는 도메인의 유효한 서명은 From 줄의 브랜드에 대해 아무것도 말해 주지 않습니다.

DMARC

From 줄의 도메인이 SPF나 DKIM을 통과한 도메인과 일치하는가? 이 정렬(alignment) 단계가 검사 결과를 내가 실제로 읽는 이름과 연결합니다. DMARC는 또한 도메인 소유자가 실패한 메일을 어떻게 처리할지 받는 쪽에 지시할 수 있게 합니다. 아무것도 하지 않기(p=none), 격리, 거부 중 하나입니다. 진짜 회사가 이 정책을 강제하지 않았다면 위조 메시지도 받은편지함에 도착할 수 있는 이유입니다.

각 결과의 의미

더 어려운 경우: 모든 검사를 통과할 때

신중한 공격자는 은행 도메인을 아예 위조하지 않습니다. 비슷한 도메인을 등록하고 SPF, DKIM, DMARC를 제대로 설정한 뒤 그 도메인으로 보냅니다. 그러면 헤더는 흠잡을 데 없어 보입니다.

Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=examplebank-secure.com;
    dkim=pass header.d=examplebank-secure.com;
    dmarc=pass header.from=examplebank-secure.com
From: "Example Bank" <[email protected]>

인증이 증명하는 것은 examplebank-secure.com이 이 메일을 보냈다는 사실입니다. 그 도메인이 내 은행의 것인지는 알려 주지 못합니다. 그 부분은 내가 확인해야 하며, 결국 도메인 자체를 아주 천천히 읽는 것이 핵심입니다. 저희가 가장 자주 보는 수법은 다음과 같습니다.

• 덧붙인 단어. 진짜 이름에 -secure, -login, -support, -verify 등을 붙인 것.
• 바꿔치기한 글자. m 대신 rn, 알파벳 o 대신 숫자 0, 글자를 두 번 쓰거나 빠뜨린 것.
• 다른 끝부분. 이름은 맞지만 회사가 쓰는 것 대신 .co, .net이나 새로운 최상위 도메인을 쓴 것.
• 진짜 이름을 하위 도메인으로. examplebank.com.account-check.net에서 실제 도메인은 account-check.net입니다. 도메인은 오른쪽부터 읽으세요.
• 비슷하게 생긴 문자. 키릴 문자 а는 라틴 문자 a와 똑같아 보입니다. 원본 헤더에서 이런 도메인은 xn--으로 시작하는 형태로 나타나는 경우가 많은데, 라틴 문자가 아닌 도메인 이름을 인코딩한 방식입니다.
• 표시 이름으로 속이기. 무료 웹메일 도메인 주소 앞에 "Example Bank"를 붙인 것. 많은 휴대폰은 이름만 보여 주므로, 눌러서 주소를 확인하세요.

도메인이 그 회사의 것인지 확실하지 않다면, 메일 안의 어떤 것도 이용해 확인하지 마세요. 회사 주소를 직접 브라우저에 입력해 비교하세요.

이메일 헤더의 위험 신호, 중요도 순

증거에 가까운 신호도 있고, 여러 개가 겹쳐야 의미가 있는 신호도 있습니다. 저희는 대략 다음과 같이 판단합니다.

의심스러운 메일을 5분 안에 확인하는 순서

1. 1

   전체 헤더 복사하기

   위에서 설명한 대로 '원본 보기'나 '메시지 원본 보기'를 사용해, 모든 Received 줄을 포함한 헤더 전체를 복사하세요.

2. 2

   헤더 분석기에 붙여넣기

   저희 이메일 헤더 분석기는 From, Reply-To, Return-Path를 나란히 보여 주고, SPF, DKIM, DMARC 결과를 표시하며, 전달 경로를 오래된 순으로 나열합니다. 분석은 브라우저에서 이루어집니다.

3. 3

   DMARC를 From 도메인과 대조하기

   dmarc=와 그 옆의 도메인을 찾으세요. 아는 브랜드인데 실패했다면, 거기서 멈추고 메시지를 삭제해도 충분합니다.

4. 4

   모든 도메인을 오른쪽부터 천천히 읽기

   From, Reply-To, DKIM을 통과한 도메인은 모두 그 회사의 것이어야 합니다. 위에서 소개한 비슷한 도메인 수법에 주의하세요.

5. 5

   Received 체인을 아래부터 읽기

   가장 아래 줄이 메시지가 시작된 곳입니다. 믿을 수 있는 것은 맨 위에 내 메일 서비스가 추가한 줄뿐입니다. 보낸 사람은 가짜 Received 줄은 물론, 그 아래에 가짜 Authentication-Results 줄까지 넣을 수 있습니다.

6. 6

   클릭하지 말고 링크 확인하기

   헤더에는 본문의 링크가 나오지 않습니다. 컴퓨터라면 각 버튼 위에 마우스를 올리고 창 구석에 나타나는 주소를 읽어 보세요. 회사의 진짜 도메인으로 가지 않는 링크가 있다면 그것만으로도 떠날 이유가 됩니다.

피싱이라고 생각되면

• 클릭하거나, 답장하거나, 첨부파일을 열지 마세요. 답장하면 그 주소를 누군가 읽고 있다는 사실이 확인되고, 첨부파일은 악성 코드가 들어오는 흔한 경로입니다.
• 다른 방법으로 회사에 연락하세요. 회사 주소를 직접 브라우저에 입력하거나 카드나 계약서에 적힌 번호를 사용하세요. 메일에 적힌 번호는 절대 쓰지 마세요.
• 메일 앱에서 신고하세요. Gmail에서는 점 3개 메뉴에서 피싱 신고를 선택합니다. Outlook에서는 보고를 누른 다음 피싱 신고를 선택합니다. 이렇게 하면 그 서비스를 쓰는 모든 사람을 위해 필터가 학습합니다.
• Anti-Phishing Working Group에 전달하세요. 주소는 [email protected]이며, 신고 내용은 보안 업체와 브라우저에 공유됩니다.
• 미국에서는 FTC에 신고하세요. 신고처는 ReportFraud.ftc.gov이며, 특히 돈이나 개인 정보가 관련된 경우라면 신고하세요.
• 이미 비밀번호를 입력했다면, 지금 바로 진짜 사이트에서 비밀번호를 바꾸고, 2단계 인증을 켜고, 같은 비밀번호를 쓴 다른 모든 곳에서도 바꾸세요. 내 이메일이 데이터 유출에 포함됐는지 확인하는 방법 가이드에서 노출 직후 1시간 동안 할 일을 다룹니다.

출처

• IETF, RFC 7208: Sender Policy Framework (SPF). pass, fail, softfail, neutral의 의미를 포함합니다.
• IETF, RFC 6376: DomainKeys Identified Mail (DKIM) Signatures.
• IETF, RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC). 2026년에 발행되어 RFC 7489를 대체했습니다.
• IETF, RFC 8601: Message Header Field for Indicating Message Authentication Status. Authentication-Results 헤더를 정의합니다.
• 미국 연방거래위원회(FTC), How to Recognize and Avoid Phishing Scams. FTC와 APWG 신고 주소 관련.
• Anti-Phishing Working Group, Report Phishing.