Email Header Analyzer: Check SPF, DKIM, DMARC, and Routing Signals
Use this Email Header Analyzer to read the SPF, DKIM, DMARC, address-alignment, timestamp, and Received-routing signals already recorded in a raw email header. The parser runs in this page: it does not upload the pasted header, contact a mail server, open links, perform DNS lookups, or verify a cryptographic signature.
![]() |
| 이메일 헤더 분석기(Email Header Analyzer) |
Email Header Analyzer
Paste a raw email header to review authentication, sender alignment, routing, and timestamp signals before you trust the message.
이메일 원본 헤더에서 인증, 발신자 정렬, 전달 경로, 발송 시각 신호를 확인합니다.
Paste the full header
Use “Show original,” “View source,” or “View message details” in your email service. Do not paste the message body.
Sender and time
- From
- —
- Return-Path
- —
- Reply-To
- —
- Message date
- —
- First received
- —
- Message-ID
- —
Signals to review
No analysis yet.
Received route · oldest hop first
No routing entries found.
Important limits
This tool reads header text only. It does not contact mail servers, open links, upload data, validate cryptographic signatures, or query a reputation database. Header fields can be forged. A “pass” result means the pasted header reports a pass; it is not independent verification.
이 도구는 헤더 문자열만 읽습니다. 메일 서버 접속, 링크 열기, 데이터 전송, 암호 서명 검증, 평판 조회를 하지 않습니다. 헤더는 위조될 수 있습니다. Pass 표시는 붙여넣은 헤더에 기록된 결과이며 독립 검증이 아닙니다.
If the message asks for money, credentials, or urgent action, verify the sender through a trusted channel you find independently.

Start with evidence, not a verdict. A header can help you spot inconsistencies, but no single PASS or FAIL result proves that a message is safe or malicious.
How to use the analyzer
- Open the message's full source or original-header view in your mail service.
- Copy the header only. Avoid pasting the message body or attachments.
- Paste it into the tool and select Analyze header.
- Review authentication and alignment together, then read the Received route from the oldest visible hop.
Three examples and what they mean
1. SPF and DKIM pass, but DMARC fails
From: Billing Team <notice@accounts.example> Return-Path: <bounce@mailer.example.net> Authentication-Results: mx.example.org; spf=pass smtp.mailfrom=mailer.example.net; dkim=pass header.d=mailer.example.net; dmarc=fail header.from=accounts.example
The individual checks report PASS, but the authenticated domains do not align with the visible From domain. DMARC can therefore fail. Review the sender through a separately found trusted channel before acting.
2. Authentication and the visible sender align
From: Person <person@example.com> Return-Path: <bounce@example.com> Authentication-Results: mx.example; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
This is a more consistent set of signals. It still does not inspect the message body, the destination of a link, the sender's intent, or whether an authorized account was compromised.
3. Forwarding or mailing-list changes create mixed results
From: Updates <news@example.com> Authentication-Results: inbox.example; spf=fail smtp.mailfrom=forwarder.example.net; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
Forwarding can break SPF because the final connecting server differs from the original authorized sender. An aligned DKIM result may still support a DMARC pass. Treat the combination and the receiving provider's evaluation as context, not a universal rule.
How to interpret the results
- SPF: the receiving system reports whether an SMTP identity was authorized for the connecting host. SPF does not authenticate the display name.
- DKIM: the receiver reports whether a domain signature verified. A valid domain signature is not the same as proof of a specific human author.
- DMARC: the receiver combines authentication with alignment to the visible From domain. RFC 9989 is the current DMARC specification and replaced RFC 7489 in May 2026.
- Return-Path and Reply-To: a different domain can be legitimate for delivery services or support workflows. Unexpected differences deserve review.
- Received route: each server normally prepends a Received field. The tool reverses the visible list to show the oldest pasted hop first, but forged or missing fields remain possible.
False positives and limits
- The analyzer parses text already present in the pasted header. It does not independently repeat SPF, DKIM, or DMARC validation.
- Authentication can pass for mail sent through a compromised but authorized account or system.
- Forwarding, mailing lists, gateways, and message rewriting can produce legitimate mismatches or failures.
- Headers can contain forged lines. Give more weight to fields added by a mail system you trust.
- The route view does not provide geolocation, reputation, malware analysis, or ownership verification.
FAQ
Does a DMARC pass mean the email is safe?
No. It indicates that the receiver reported an aligned SPF or DKIM result under DMARC. It does not judge message content, link destinations, account compromise, or sender intent.
Why can SPF fail after forwarding?
SPF evaluates the connecting host against an SMTP identity. A forwarder's host may not be authorized by the original domain, so forwarding can change the outcome.
Can a different Reply-To be legitimate?
Yes. Ticketing systems, marketing platforms, and delegated support workflows may use another domain. Compare the context and verify unusual requests independently.
Which Received line is the original hop?
Mail systems normally prepend new Received fields, so the oldest visible hop is usually at the bottom of the raw header. Missing or forged fields can make the history incomplete.
Does this page send my header anywhere?
The analyzer itself makes no network request with your pasted text. The surrounding blog page still loads its normal web resources. Avoid pasting message bodies, attachments, or unnecessary personal data.
Related tools
- Suspicious URL Risk Checker — inspect URL structure without a reputation lookup.
- Disguised File Name Checker — review misleading extensions and bidirectional-text tricks.



댓글
댓글 쓰기