메일 헤더 보는 법: 발신자 추적과 피싱 판별

받은편지함에 보이는 발신자 이름과 주소는 겉포장일 뿐이다. 메일이 실제로 어디서 출발해 어떤 서버를 거쳐 도착했는지, 발신 도메인이 인증을 통과했는지는 전부 원본 헤더(raw header)에 기록되어 있다. 피싱 메일은 표시 이름(display name)과 From 주소를 마음대로 꾸밀 수 있지만, 수신 서버가 직접 찍는 기록까지 위조하기는 훨씬 어렵다. 그래서 헤더를 읽을 줄 알면 “은행에서 온 것처럼 보이는 메일”이 진짜인지 몇 분 안에 판별할 수 있다.

이 글은 Gmail·Outlook에서 원본 헤더를 여는 법부터, Received 체인을 아래에서 위로 읽어 발신 서버를 추적하는 법, From·Return-Path·Reply-To 불일치와 Authentication-Results의 SPF/DKIM/DMARC 판정을 해석하는 법까지 실제 피싱 사례로 순서대로 설명한다. 복사한 헤더는 이메일 헤더 분석기에 붙여넣으면 체인과 인증 결과를 자동으로 풀어서 보여준다.

원본 헤더 여는 법 — Gmail·Outlook·기타

메일 클라이언트마다 메뉴 이름이 다르지만 대부분 두세 번의 클릭이면 된다.

• Gmail(웹): 메일 열기 → 오른쪽 위 ⋮(더보기) → 원본 보기(Show original). 상단에 SPF/DKIM/DMARC 요약까지 함께 표시되고, “클립보드에 복사” 버튼으로 전체 헤더를 바로 복사할 수 있다.
• Outlook(웹, outlook.com/M365): 메일 열기 → ⋯(기타 작업) → 보기 → 메시지 원본 보기(View message source).
• Outlook(데스크톱): 메일을 더블클릭해 새 창으로 연 뒤 파일 → 속성→ “인터넷 헤더” 상자에서 복사.
• 네이버 메일: 메일 열기 → 본문 상단의 ▼또는 “머리글 보기” 메뉴. Apple Mail은 보기 → 메시지 → 모든 헤더.

복사한 텍스트 전체(빈 줄 위의 헤더 블록)를 헤더 분석기에 붙여넣으면 아래에서 다룰 항목을 자동으로 분류해 준다. 원리를 알면 도구 결과도 훨씬 정확히 해석할 수 있으니 계속 읽어보자.

Received 체인 — 아래에서 위로, 첫 Received가 출발점

메일이 서버를 거칠 때마다 각 서버는 헤더 맨 위에 자기 Received: 줄을 쌓는다(스택 구조). 따라서 가장 아래 Received가 최초 발신 서버, 가장 위가 내 메일함에 넣은 수신 서버다. 발신자를 추적할 때는 반드시 아래에서 위로 읽는다.

1. 맨 아래 Received의 from 뒤 호스트명과 괄호 안 IP가 출발지 후보다.
2. 한 줄 위로 올라가며 by(받은 서버)와 다음 줄의 from이 이어지는지 확인한다.
3. 타임스탬프가 아래에서 위로 갈수록 늦어지는지 본다. 순서가 뒤집혀 있으면 조작 의심.

여기서 중요한 신뢰 원칙: 발신자가 쓴 줄은 위조 가능, 내 쪽 서버가 찍은 줄은 신뢰 가능이다. 공격자는 자기 서버에서 가짜 Received 줄을 미리 몇 개 끼워 넣을 수 있다. 하지만 내 수신 서버(예: Gmail의 mx.google.com)가 기록한 맨 위쪽 줄들과, 그 서버가 직접 관측한 “접속해 온 IP”는 위조할 수 없다. 그래서 실무에서는 신뢰할 수 있는 내 서버가 처음 외부에서 받은 지점의 IP를 진짜 출발지로 본다.

From·Return-Path·Reply-To — 세 주소가 어긋나면 의심하라

이메일에는 “보낸 사람”이 하나가 아니다. 세 가지가 각각 다른 층에서 동작한다.

• From: — 메일 앱에 표시되는 주소. 발신자가 마음대로 적을 수 있는 완전 위조 가능필드다. 표시 이름은 더더욱 자유(예: “국민은행 <random@evil.com>”).
• Return-Path: — 반송(bounce)이 돌아갈 SMTP 봉투 주소. 수신 서버가 기록하며 SPF 검사가 이 도메인 기준으로 이뤄진다. From과 도메인이 다르면(뉴스레터 대행사는 예외) 경고 신호.
• Reply-To: — 답장이 가는 주소. 피싱에서 흔한 수법이 From은 그럴듯하게 꾸미고 Reply-To만 공격자 주소로 바꿔 답장을 가로채는 것이다.

세 주소의 도메인이 서로 다르고 그 이유가 설명되지 않으면(대량발송 대행, 티켓 시스템 등) 피싱 가능성을 높게 봐야 한다.

Authentication-Results — SPF·DKIM·DMARC 판정 읽기

수신 서버는 인증 검사 결과를 Authentication-Results: 한 줄에 요약한다. 예를 들면:

Authentication-Results: mx.google.com; spf=fail smtp.mailfrom=evil.com; dkim=none; dmarc=fail (p=REJECT) header.from=kbstar.com

• spf — Return-Path 도메인이 그 발송 IP를 허용하는지. pass/fail/softfail/none. 도메인의 실제 SPF 레코드는 SPF 조회 도구로 확인할 수 있다.
• dkim — 서명이 유효한지와 서명 도메인(header.d=). 서명 자체가 없으면 none. 도메인에 DKIM 공개키가 올라와 있는지는 DKIM 조회 도구로 셀렉터를 넣어 확인한다.
• dmarc — SPF나 DKIM 중 하나라도 pass이면서 그 도메인이 From: 도메인과 정렬(alignment)되는지. 여기서 fail이면 “From에 적힌 도메인의 주인이 보낸 게 아니다”에 가깝다.

핵심은 정렬이다. spf=pass여도 그 pass가 evil.com(Return-Path) 기준이고 From은 kbstar.com이라면 DMARC 관점에서는 실패다. 판정 줄에서 header.from=과 smtp.mailfrom=, header.d=의 도메인이 일치하는지 꼭 비교하자.

실전 예제 — “은행 보안 알림” 메일 판별

받은편지함에는 이렇게 보인다: “KB국민은행 <security@kbstar.com> — [긴급] 계정 보안 확인 필요”. 원본 헤더의 핵심 줄만 뽑으면:

• From: "KB국민은행" <security@kbstar.com>
• Reply-To: kb-verify@secure-check.top
• Return-Path: <bounce@mail-blast77.xyz>
• Received: from mail-blast77.xyz (203.0.113.45) by mx.google.com ... (맨 아래 신뢰 구간)
• Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=mail-blast77.xyz; dkim=none; dmarc=fail header.from=kbstar.com
• Message-ID: <a91f...@mail-blast77.xyz>, X-Mailer: BulkSenderPro 2.1

판독 결과를 정리하면:

1. From 표시 이름은 은행이지만 Return-Path·Message-ID·실제 발신 서버가 전부 무관한 도메인(mail-blast77.xyz)이다.
2. spf=pass처럼 보여도 그것은 공격자 자신의 도메인 기준 pass일 뿐, dmarc=fail header.from=kbstar.com이 결정타다 — kbstar.com의 주인이 보낸 메일이 아니다.
3. Reply-To가 또 다른 제3의 도메인으로, 답장을 가로채려는 전형적 패턴.
4. X-Mailer가 대량발송 도구인 점도 정황 증거.

판정: 피싱. 링크를 누르지 말고 스팸 신고 후 삭제한다. 이런 판독을 매번 손으로 하기 번거롭다면 헤더 전체를 헤더 분석기에 붙여넣는 것으로 충분하다.

헤더 필드 치트시트 — 무엇을 알려주고, 위조 가능한가

정리하면: 발신자가 적는 필드(From, Reply-To, 아래쪽 Received)는 참고만 하고, 내 수신 서버가 기록한 것(맨 위 Received, Authentication-Results)을 근거로 판단한다. 도메인 쪽 설정이 궁금하면 SPF 레코드와 DKIM 키를 직접 조회해 교차 검증하자.