본문으로 건너뛰기
AZ Tools

이메일 헤더 분석

RFC 5322 연속 라인 펼치기, From/To/Subject/Date/Message-ID 추출, 모든 Received 라인 파싱(시간 순으로 역배열)·인접 홉 간 실시간 지연 계산, Authentication-Results에서 spf/dkim/dmarc 결과 추출. 메일이 왜 스팸 처리됐는지 진단·위조된 Received 체인 발견·어느 MTA가 지연 일으켰는지 특정에 유용.

  • 보낸이"Alice Sender" <alice@example.com>
  • 받는이user@recipient.com
  • 제목Hello there
  • 날짜Mon, 02 Jun 2026 09:15:38 +0000
  • Message-ID<abc123@example.com>
인증
SPFpassDKIMpassDMARCpass
홉 (오래된 → 최신)
  1. #1
    from sender-host.example.com → by mail.example.com
    Mon, 02 Jun 2026 09:15:40 +0000 (UTC)
  2. #2+2s
    from mail.example.com → by mx.recipient.com
    Mon, 02 Jun 2026 09:15:42 +0000 (UTC)

모든 처리는 로컬 — 헤더가 브라우저를 떠나지 않음.

사용법

  1. 원본 헤더 전체 붙여넣기 (헤더와 본문 구분하는 빈 줄 이전 전부).
  2. 메타데이터 블록·인증 뱃지·홉 목록 확인.

자주 묻는 질문

원본 헤더는 어디서 얻음?
Gmail: 메일의 ⋮ 메뉴 → "원본 보기". Outlook: 파일 → 속성 → 인터넷 헤더. 대부분의 다른 클라이언트도 "소스 보기" 또는 "원본 보기" 옵션 있음.
홉 지연이 가끔 음수로 나오는 이유?
서버 간 시계가 몇 초 어긋나는 경우 흔하고, 일부 MTA는 Received 라인을 소급 기록. 작은 음수는 정상; 큰 음수(또는 홉 누락)는 위조된 헤더 가능성.
Received 체인은 어디까지 믿을 수 있나?
내가 통제하는 인프라가 붙인 부분까지만이다. 각 서버는 메시지를 받을 때 자기 줄을 맨 앞에 덧붙이므로, 신뢰할 수 있는 첫 홉보다 위에 있는 것은 내가 운영하지 않는 기계가 쓴 것이고 통째로 조작될 수 있다. 체인은 내 쪽에서 바깥으로 읽고, 가장 이른 홉들은 증거가 아니라 주장으로 취급하라.
SPF를 통과했는데도 명백한 스팸인 이유는?
SPF는 봉투 발신자의 도메인을 보내는 서버 주소와 대조할 뿐이고, 그 도메인이 수신자에게 보이는 도메인일 필요는 없다. 자기 소유의 도메인으로 SPF를 통과시키면서 화면에는 남을 흉내 낸 From 주소를 띄울 수 있다. 보이는 From이 실제로 인증된 SPF나 DKIM과 일치하도록 요구하기 위해 존재하는 것이 DMARC다.

관련 도구