이메일 헤더 분석기
메일 원본 헤더에서 경로·지연·SPF/DKIM/DMARC 결과를 분석합니다.
이메일이 늦게 도착하거나, 스팸함으로 빠지거나, 발신지가 의심스러울 때 가장 확실한 단서는 메일 원본 헤더입니다. 이 이메일 헤더 분석기에 메일 클라이언트에서 복사한 전체 헤더를 붙여넣으면 From·To·Subject·Date·Message-ID 요약, 메일이 거쳐 온 서버(Received hop)별 경로와 구간별 지연 시간, 그리고 SPF·DKIM·DMARC 인증 결과를 한눈에 정리해 줍니다.
모든 분석은 브라우저 안에서만 처리되며 헤더 내용은 어떤 서버로도 전송되지 않습니다. 메일 지연 원인 추적, 발신 도메인 위조(스푸핑) 점검, 그리고 인증 정책이 제대로 적용됐는지 확인할 때 사용하세요.
메일 헤더는 어디서 복사하나요?
대부분의 메일 서비스는 원본 보기 기능을 제공합니다. Gmail은 메일을 연 뒤 우측 더보기 메뉴에서원본 보기, Outlook은 메일 더블클릭 후 파일 → 속성의 인터넷 헤더, Apple Mail은보기 → 메시지 → 원본에서 헤더를 볼 수 있습니다. 거기서 헤더 블록 전체를 복사해 위 입력란에 붙여넣으세요.
Received 경로를 어떻게 읽나요?
헤더의 Received 줄은 메일이 거쳐 온 서버가 위에서부터 차곡차곡 쌓입니다. 즉 맨 위가 최종 수신 서버, 맨 아래가 최초 발신 서버입니다. 이 도구는 이를 발신→수신 순서(시간순)로 뒤집어 hop마다 다음을 보여줍니다.
- from / by: 어느 서버에서 어느 서버로 넘겨졌는지
- 타임스탬프: 해당 hop이 메일을 받은 시각
- 지연(초): 직전 hop과의 시간 차이 — 큰 값이 있으면 그 구간에서 병목이 발생한 것입니다
SPF·DKIM·DMARC 결과의 의미
Authentication-Results 헤더에는 수신 서버가 판정한 인증 결과가 담깁니다.
- SPF: 발신 IP가 도메인의 허용 목록에 있는지 (
pass면 정상) - DKIM: 본문/헤더가 서명으로 위변조 없이 보장되는지
- DMARC: SPF/DKIM 정렬(alignment)과 도메인 정책을 종합한 최종 판정
세 가지가 모두 pass면 발신지 신뢰도가 높습니다. fail이나 softfail이 보이면 스푸핑이거나 발송 설정이 잘못된 것이니, 인증 레코드 점검이 필요합니다. 도메인의 SPF·DKIM·DMARC 레코드를 각각 조회하거나, 이메일 도달성 종합 점검로 한 번에 진단해 보세요.
인증 결과 값 빠른 참조
Authentication-Results에는 spf=pass처럼 메커니즘과 결과가 짝지어 기록됩니다. 같은 단어라도 의미가 다르니 아래 표로 구분하세요.
| 값 | 어디서 | 의미와 대처 |
|---|---|---|
spf=pass | SPF | 발신 IP가 Return-Path 도메인의 허용 목록에 있음. 정상. |
spf=softfail | SPF | 레코드 끝이 ~all. 허용되지 않았지만 거부도 아님 — 보통 스팸 점수만 가산. |
spf=neutral | SPF | 레코드가 ?all로 판단을 유보. 사실상 정보 없음에 가까움. |
spf=none | SPF | 해당 도메인에 SPF 레코드 자체가 없음. 레코드 발행 필요. |
dkim=pass | DKIM | DKIM-Signature의 d= 도메인 공개키로 서명 검증 성공. 본문 무결성 보장. |
dkim=fail | DKIM | 서명 불일치. 중계 중 본문 변형(푸터 삽입 등)이나 키 회전이 원인인 경우가 많음. |
dmarc=pass | DMARC | SPF 또는 DKIM이 From 도메인과 정렬되어 통과. 최종 신뢰. |
dmarc=fail (p=reject) | DMARC | 정렬 실패 + 정책이 거부. 정상적인 발송이면 즉시 인증 설정 점검. |
실제 헤더 한 줄씩 읽어보기
아래 같은 Authentication-Results와 From이 있다고 가정해 봅니다.
From: Billing <billing@mail.shop.com>Return-Path: <bounce@sg.mailgun.net>Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=sg.mailgun.net; dkim=pass header.d=shop.com; dmarc=pass header.from=shop.com
해석: SPF는 sg.mailgun.net(Return-Path 도메인) 기준으로 pass지만, 이 도메인은 From의shop.com과 다릅니다 — 즉 SPF 정렬은 실패입니다. 그래도 DMARC가 pass인 이유는 DKIM 서명의 header.d=shop.com이 From 도메인과 일치해 DKIM 정렬이 통과했기 때문입니다. DMARC는 둘 중 하나만 정렬되면 통과하므로, 외부 발송 대행(Mailgun 등)을 쓸 때는 SPF보다 DKIM 정렬을 챙기는 것이 안전합니다.
흔한 실수 / 함정
- SPF는 From이 아니라 Return-Path를 본다 — 화면에 보이는
From주소가 아니라 봉투 발신자(smtp.mailfrom/Return-Path) 도메인으로 검사됩니다. 그래서From이 위조돼도 SPF는 통과할 수 있습니다. - X-Forwarded나 사내 게이트웨이가 추가한 Received를 최초 발신지로 오해 — 맨 아래 Received가 항상 진짜 발신 서버는 아니며, 내부망 IP(
10.x·192.168.x)가 찍힌 hop은 조직 내부 중계일 뿐입니다.
자주 묻는 질문
헤더 내용이 외부로 전송되나요?
Received 줄이 시간순으로 안 맞는데요?
SPF가 pass인데 DMARC가 fail인 이유는?
지연이 큰 hop이 보이면 무조건 문제인가요?
Authentication-Results 헤더가 없으면요?
관련 가이드
- 메일 헤더 보는 법: 발신자 추적과 피싱 판별원본 헤더를 열어 실제 발신 서버를 추적하고 SPF·DKIM·DMARC 결과로 위조 메일을 가려내는 법.