Email Header Analyzer
Paste the full original headers of a message. The tool parses the routing path and authentication results in memory, labels each as a claim made by the header, and does not store what you paste.
Run Email header analyzer
No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.
What the analyzer does
Every mail server that handles a message adds fields to its header. The analyzer unfolds the header, then reads the Received chain, Authentication-Results, Received-SPF, DKIM-Signature and ARC fields, compares the From address with the authenticated domains, and looks for oddities such as a Reply-To that differs from From, a display name containing another address, several From headers or a Date far from the first hop.
Optionally it also queries today's DNS for the domains named in the header, to show the SPF record, DMARC policy or DKIM key that those domains publish now. These live results are labelled separately.
Header results are claims, not proof
Header text can be written or edited by any sender or intermediate server. A line saying dkim=pass is only a statement by whichever system wrote it. The only result worth trusting is the one added by your own receiving server, and only if you know which Authentication-Results line that is. For that reason the analyzer labels every assertion as 'claimed by the header; not independently verified', never marks an authentication result from the header as a pass, and does not cryptographically verify any DKIM or ARC signature.
Earlier Received hops are even less reliable: a sender can invent lines that appear below the real ones. The hop added by your own server, the topmost, is the one that is dependable.
How to read the result
The Received table is shown oldest hop first with claimed host names, addresses, protocol, time and delay between hops. Flags mark out-of-order or future timestamps, slow hops over an hour and private addresses. Timestamps that go backwards usually mean clock skew, though they can indicate editing.
The authentication findings list the results reported by each Authentication-Results line, call out non-passing results, and state which domain each result concerns. The alignment finding compares those domains with the From domain, since DMARC cares about alignment, not just a pass. The live DNS findings answer a different question: what the domain publishes now, which may differ from the day the message was sent.
Common problems when analysing headers
- Partial headers. Many mail clients show a summary. Use 'show original' or 'view source' to copy the whole block, from the first Received line to the last field before the blank line.
- Several Authentication-Results lines. Each server adds its own. Identify the one from your receiving domain by its authserv-id.
- Reply-To mismatch. Common in legitimate newsletters and in fraud; judge by context.
- Display name containing an address. Often used to impersonate another sender.
- Forwarded or relayed mail. SPF often fails after forwarding even when the original was fine; ARC fields may record earlier results.
- Dates far apart. Check the sender's clock and the queue delay before assuming forgery.
Handling pasted headers safely
Headers contain addresses, IP addresses, host names and sometimes internal routing details. Prerequisites: remove anything you do not want to share if you copy results elsewhere. Operational risk: the analyzer itself keeps nothing. The pasted text is analysed in memory and discarded, is not stored, and is not copied into the report, in which address local parts are masked and the Subject and body never appear. Rollback is simply not applicable, since nothing is changed, but do not paste headers of messages that you are not entitled to share.
- Open the message and choose the option that shows original headers.
- Copy everything from the first field to the blank line that separates headers from the body.
- Paste it, leave the live DNS option on if you also want today's SPF, DMARC and DKIM data, and run the analysis.
- Locate the Authentication-Results line added by your own server and compare it with the claims.
- If a message is suspicious, report it through your mail provider rather than relying on this analysis.
Limits
No signature is verified. The tool cannot confirm that a message is genuine or fraudulent, and a header that looks clean can be fabricated. It reads at most 400 header fields and 64 KB of text. It sees only what you paste, so it cannot tell you what a receiver actually decided unless that decision is in the pasted headers, and today's DNS cannot show what DNS said at delivery time.
Frequently asked questions
Are the authentication results trustworthy?
Only your own receiving server's result is evidence. The tool treats every result it reads as a claim in the header.
Is the text I paste stored?
No. It is analysed in memory and discarded, and it is not copied into reports. Addresses are masked in output.
Why does SPF fail on a forwarded message?
The forwarder's IP is not in the original sender's SPF record. DKIM survives forwarding better if the message is not altered.
Can the tool tell me if an email is phishing?
No. It shows routing and authentication claims. Judgement still needs the content, the context and the sender.
Which Received line is the most reliable?
The topmost one, added by your own server. Lines below it were written by other systems and can be fabricated.
What does the live DNS check add?
It shows what the From domain publishes today. It cannot show what existed when the message was delivered.
Scope of this tool
- Headers are untrusted text: no result is treated as proof of authentication.
- The pasted text is not stored.
Written by DNS Tools editorial · Last updated 2026-10-09