네트워크/HTTP
Email Header Analyzer
이메일의 원시 헤더(View Source / Show Original)를 분해합니다 — 기본 필드, 타이밍이 포함된 Received 체인, SPF/DKIM/DMARC, From/Reply-To 위조 징후.
A message's full headers (View Source or Show Original in a mail client) record its entire path through mail servers, along with sender-authenticity check results. This tool breaks those headers down into readable fields and flags signs of spoofing.
How to use it
- Paste raw email headers and the tool extracts the main fields (From, To, Subject, Date) along with the Received chain and the timing of each hop.
- SPF, DKIM, and DMARC results are shown separately with an explanation of what each status (pass, fail, none) means.
- A mismatch between the From and Reply-To headers is flagged — a common sign of phishing.
Common uses
- Checking a suspicious email for signs of phishing before trusting its links or attachments.
- Debugging why a legitimate email lands in spam by checking its SPF/DKIM/DMARC status.
- Tracing an email's actual path through servers to understand a delivery delay.
Things to keep in mind
The Date header is set by the sender's client and can be inaccurate; for an exact timeline, trust the timestamps in the Received chain, which are added by the mail servers themselves.
Passing SPF/DKIM/DMARC only confirms the message is technically authorized by the sending domain — it doesn't guarantee the content itself isn't phishing or spam.
자주 묻는 질문
이메일 헤더가 메시지 본문이 알려줄 수 없는 무엇을 실제로 알려줄 수 있나요?
헤더는 이메일이 메일 서버를 거친 경로(Received 라인), 인증 결과(SPF, DKIM, DMARC), 실제 발신 서버를 드러냅니다 — 위조되거나 피싱된 이메일을 발견하는 데 유용합니다.
SPF, DKIM, DMARC가 실제로 통과했는지 어떻게 알 수 있나요?
Authentication-Results 헤더에서 pass, fail, none을 찾아보세요 — 세 가지 모두 "pass"이면 메시지가 위조되지 않았다는 강한(절대적이지는 않지만) 신호이며, 발신자에게 중요한 검사에서 실패하면 경고 신호입니다.
여기에 이메일 헤더를 붙여넣으면 어딘가에 업로드되나요?
아니요. 헤더는 브라우저 내에서 완전히 파싱됩니다 — 서버로 전송되는 것은 없으므로 실제 헤더를 분석해도 안전합니다.
Message-ID 헤더는 어디에 쓰이나요?
각 이메일에 부여되는 고유 식별자로, 메일 클라이언트가 In-Reply-To 헤더를 통해 답장을 원본 메시지의 Message-ID와 연결하여 메시지를 스레드로 묶는 데 사용합니다.
Date 헤더가 Received 헤더의 타임스탬프와 일치하지 않을 수 있는 이유는 무엇인가요?
Date는 발신자의 메일 클라이언트가 설정하며 그 시계가 동기화되지 않았다면 부정확할 수 있는 반면, Received의 타임스탬프는 실제 전달 시점에 서버가 추가하므로 더 신뢰할 수 있습니다.