Email Header Analyzer
Trace delivery hops, read SPF, DKIM and DMARC results, and see whether they actually cover the From address.
Related tools
About this tool
Email Header Analyzer takes the raw source of a message - everything above the first blank line - and reconstructs what happened to it. It unfolds the folded header lines (RFC 5322), turns every Received line into a delivery hop with the server that handed the message over, the server that took it, the timestamp and the delay since the previous hop, and reads the SPF, DKIM and DMARC verdicts out of the Authentication-Results (RFC 8601) and Received-SPF (RFC 7208 §9.1) headers. It then asks the question the badges do not answer: which domain was actually authenticated. SPF authenticates the envelope domain and DKIM authenticates the signing domain, and a message is only covered when one of those aligns with the domain in the From header (RFC 7489 §3.1) - so a pass on somebody else's domain next to a forged From is named for what it is. Alongside that it reads the display name, the Reply-To and the Return-Path for the tricks a reader sees first, and walks the Received chain for gaps, backwards timestamps and a first hop that looks like a home connection. Only the results written by the server that delivered the message are counted: an Authentication-Results line written by any other server, and an ARC set carried along from an earlier hop (RFC 8617), are shown and marked, never counted, because any machine on the way can write them. It does not verify a DKIM signature itself, query DNS for SPF or DKIM records, contact any server named in the headers, or read the message body and attachments. The score is a reading of these headers and not a verdict on the message: everything below the receiving server can be written by whoever sent it, so the strongest thing the page will say is that a domain was authenticated and aligned.
Nothing you paste leaves your browser, and a .eml or .txt file you open or drop is read by the browser's own File API and parsed the same way - it is never uploaded. The headers are unfolded and parsed by JavaScript on the page: no request goes to the XGM API, no DNS query is sent for the domains, selectors or addresses that appear in them, and no server named in a Received line is contacted. The SPF, DKIM and DMARC badges are copied out of the Authentication-Results and Received-SPF headers your receiving server already wrote, so there is nothing left to look up anywhere. The spoofing assessment below them is built from the same text: it compares the From domain with the domain SPF and DKIM actually authenticated, reads the display name, Reply-To and Return-Path, and walks the Received chain. Results written by a server other than the one that delivered the message are shown but not counted, because any machine on the way can add them. The score is a reading of these headers, not a verdict on the message, and everything below the receiving server can be written by whoever sent it - so the strongest thing the page will ever say is that a domain was authenticated and aligned. The JSON and Markdown exports are generated in the page and saved by your own browser, and the text in the box is not stored with the result.
How to use it
- Open the Email Header Analyzer tool.
- Paste or type the input you want to inspect.
- Read the result, which is computed in your browser; the input is not sent to XGM.
- Copy the output only after checking it looks correct.
- Use related XGM tools if you need a broader diagnostic view.
FAQ
DKIM shows “not found” although I know the message was signed. Why?
The badges are read from the Authentication-Results header that your receiving server wrote (RFC 8601), not from the DKIM-Signature itself. If your provider does not add that header, or you pasted only part of the source, there is no verdict to show. The analyzer never fetches the public key from DNS, so it cannot recompute a signature the receiver did not already check.
Which row is the sender, the first or the last?
Each server prepends its own Received line, so in the raw source the newest hop is at the top (RFC 5322 §3.6.7). The table reverses that order: hop 1 is the oldest, normally the machine that first accepted the message, and the last row is the server that delivered it to your mailbox.
Why is a delay negative, and why does that raise a warning?
Each hop's delay is its own timestamp minus the previous hop's, and every server stamps with its own clock. A few seconds of drift is normal, so only differences of more than 60 seconds backwards are flagged. A large negative delay means either a badly set clock on one relay or Received lines that were added by the sender rather than by a real server.
SPF says pass but DMARC failed. How?
SPF authenticates the envelope sender in MAIL FROM, which is what the Return-Path header records (RFC 7208 §2.4). DMARC only counts a pass when that domain is aligned with the domain in the From header (RFC 7489 §3.1), so a mailing service that bounces to its own domain passes SPF and still fails DMARC. The analyzer points this out when the Return-Path domain is neither the From domain nor a subdomain of it, in which case DKIM has to carry the alignment.
The score is high. Does that mean the message is safe?
No, and the page will not say so. The score only measures how far these headers back the From address: whether the server that delivered the message reported a passing result, whether that result covers the domain in the From line, and whether the path and the addresses fit together. A real account that has been taken over sends perfectly authenticated phishing, and everything in the headers below the receiving server can be written by whoever sent the message. The strongest statement available is “authenticated and aligned for that domain”, which is about the domain, not about the contents.
Can the Received lines be trusted?
Only from the first server you control downwards. Everything a message carries before it reaches your provider can be written by the sender, so headers claiming a respectable origin prove nothing. The trustworthy parts are the hops added by your own infrastructure and the Authentication-Results line it wrote, which is why the tool bases the SPF, DKIM and DMARC badges on that header.
Read the full Email Header Analyzer guide