Email header analyzer
Runs in your browser
Paste the raw headers from a message — or the whole .eml file — and this lays out the route it took, how long each server held it, and what each one recorded about SPF, DKIM and DMARC.
Everything happens in this page, on your machine. The parser is JavaScript that already loaded with the page; pasting a message sends no request, so there is nothing on our side to store or hand over. Disconnect from the network entirely and it keeps working — that is the check worth doing.
To be exact about it: the page itself is not silent. Like every page here it loads our analytics, which counts the visit and never sees the message. What never leaves your browser is what you paste.
Analyze headers
Results will appear here.
How to read what comes back
Where do I find the headers?
In Gmail, open the message and pick Show original from the three-dot menu, then copy everything. In Apple Mail it is View → Message → Raw Source. In Outlook on the web, View message details. Any of those gives you the block this page wants. A saved .eml file works too.
The Received chain reads bottom-up on the wire
Every server that handles a message adds its own Received header at the top, so the raw message lists the journey backwards. This page reverses that: hop 1 is the first server to see the message, and the last row is the one that put it in the mailbox.
Each hop records the name the sending side gave (from), the server writing the line (by), the protocol, and a timestamp. The delay column is the gap between one hop’s timestamp and the previous one’s.
A negative delay is not a bug in the tool. Mail servers keep their own clocks and they disagree. Seeing it is the point; a tool that clamped it to zero would be hiding the only evidence that the clocks are off. Times are shown as written, in whatever offset each server used.
Headers are also the easiest part of a message to forge. Anything below the first server you trust was written by a machine you have no reason to believe, so read the chain from the bottom row upward and stop believing it where your own infrastructure stops.
Authentication results belong to the server that wrote them
Authentication-Resultsis the receiving server’s note to itself about checks it ran. This page reproduces it and attributes it; it does not re-run anything, because re-running SPF or DMARC needs a DNS lookup and this tool makes none.
The identity next to each result is the part that matters most and the part most often skipped. An spf=pass on smtp.mailfrom=bounces.example.net says that bounce domain is allowed to send — it says nothing about the address in the From line a reader actually sees. DMARC is the check that ties those together, which is why a dmarc=pass is worth more than either of the other two alone.
What this cannot tell you
It cannot tell you whether the message is safe. It reports what is written in the headers, and a determined sender writes whatever they like in the ones their own machine added. It also cannot verify a DKIM signature: that needs the signing domain’s public key from DNS, and fetching it would break the promise that nothing here touches the network.
If you want to stop giving out the address that ends up in these headers in the first place, that is the thing Maski does.
Email header analyzer is one of the free email tools.