Email Header Analyzer

Rebuild the route a message took, and read the authentication verdicts the receiving server wrote down.

Runs on your deviceEmailWorkingNo account needed

What this tool does

Email Header Analyzer takes the header block of a message and reconstructs the journey it made. Mail systems stack Received lines newest first, so they are reversed here into the order the message actually travelled and numbered from the sending machine down to your mailbox. Each row carries the name the sender announced in its HELO, the address the receiving host observed — often a different thing, and the one worth trusting — plus the server that accepted the handover, the protocol and TLS details, the timestamp in UTC and the gap since the hop before it.

The authentication side is a reading of the record, not a fresh test. Where the delivering server left an Authentication-Results header, its SPF, DKIM and DMARC verdicts are pulled out and listed under the table, one line each, naming the domain the verdict applied to and the host that recorded it; where it left none, an ARC-Authentication-Results line written by an earlier hop, or a plain Received-SPF header, is used instead. Nothing is re-checked here: no DNS record is queried and no signature is recomputed — the message body a DKIM hash covers is discarded along with the rest of the text below the headers. To examine a domain's own published records rather than one message's outcome, SPF Inspector, DKIM Record Checker and DMARC Inspector do that job.

Parsing happens in this browser tab and the headers are not uploaded, which matters because a header block carries recipient addresses, internal hostnames and the sender's IP. Two limits are worth holding onto before you draw conclusions from the result. Only the newest Received line was written by the server that delivered the message to you; every hop before it was added upstream and can be forged wholesale, so the earliest rows are claims rather than evidence. And the checks the parser makes — a Reply-To pointing at another domain, a display name carrying someone else's address, an absent Message-ID — come back as a flat list of notes under the table, in the order the code raises them rather than by severity, and only the ones marked with a warning sign are counted in the short summary.

How to use it

  1. Copy the raw headers out of your mail client. In Gmail, open the message menu and choose Show original. In Outlook, File → Properties → Internet headers. Both hand you the whole block.
  2. Paste them into the input box. Full message source is fine — only the text above the first blank line is read as headers, and the body is ignored. Load sample fills the box with a worked example if you want to see the shape first.
  3. Press Run and read the path from hop 1 downwards. Hop 1 is the sending machine and the bottom row is the server that filed the message in your mailbox. The Delay column is the gap between that hop's timestamp and the previous one's.
  4. Read the notes under the table. They spell out the three authentication verdicts and then every flag the parser raised, marked ⚠ where it matters and ℹ where it is context. The hint beside the button repeats the hop count, the transit time and the verdicts in short form, and Copy output takes the table as CSV with those notes appended underneath.

Processing & privacy

Runs on your device. Your file is processed directly in this browser.

Common use cases

Working out where a message really originated

The earliest hop holding a public address is the sending machine. Addresses in private ranges are labelled as such, so an internal relay is not mistaken for the origin.

Explaining why a message arrived late

The per-hop delays localise the wait. A six-hour gap at one relay points at a queue on that specific server rather than at either end of the chain.

Sizing up a suspicious invoice or password reset

A Reply-To whose registrable domain differs from the From address is raised as a warning, so a reply-hijack on a sibling subdomain stays quiet, and the notes say whether SPF, DKIM and DMARC passed at the receiving end.

Answering a deliverability complaint

When a recipient sends you the headers of mail they did receive, the recorded verdicts show whether your messages authenticated on arrival at their provider.

Questions

Are my headers uploaded anywhere?
No. The parsing runs in this browser tab, so the block — with its recipient addresses, internal hostnames and IP addresses — is never transmitted. The tool still works with the network disconnected.
Does it verify SPF and DKIM itself?
No, and the distinction matters. It reports the verdicts the receiving server recorded at delivery, which is what actually decided the message's fate. Testing a domain's live records is separate work: SPF Inspector, DKIM Record Checker and DMARC Inspector query DNS for that.
Can the hops be faked?
The early ones can. Only the newest Received line comes from the server that delivered the message to you, and it is the last row in the table. Every hop above it was written by some upstream host, and a sender who controls that host controls what it says.
Why is a delay negative, or implausibly long?
Delays are the arithmetic difference between timestamps written by two different machines. Clocks drift, and a relay running a few seconds behind the one before it yields a negative gap that describes the clocks, not the delivery.
It says no email headers were found.
The input has to start with header lines such as Received: or From:. A message forwarded as ordinary text usually loses them, and only the original recipient's copy carries the full chain.
Does it tell me where the sender is located?
No. The sending IP is shown exactly as it appears in the headers, with no geolocation and no reputation lookup attached. Blacklist Checker and MX Lookup answer those questions separately.
Can I paste the whole message, body and all?
Yes. Everything above the first blank line is treated as the header block and the rest is ignored, so a full .eml source works. To read the body instead, EML Viewer opens the message itself.

Related tools