Email Header Analyzer

The analysis happens in your browser

Message headers are not neutral technical data. They carry the sender's and recipients' addresses, the subject line, the names of internal servers, and often the identifiers a company would rather not publish. That is why this tool does its work locally: the text you paste is parsed by JavaScript on this page and never sent anywhere.

It is worth saying plainly rather than burying in a privacy policy — we cannot lose what we never receive. It also means the analysis works with the page open and the network gone.

How to get the headers

Every client hides them somewhere different, and the wording changes between versions. What you are looking for is the raw source or the "original" view.

• Gmail — open the message, three dots in the top right, Show original. The headers are at the top of the page that opens.
• Outlook on the web — three dots, View, View message details.
• Outlook desktop — open the message in its own window, then File, Properties, and copy the Internet headers box.
• Apple Mail — View, Message, All Headers, or press Shift+Cmd+H.
• Thunderbird — Ctrl+U for the full source.
• Yahoo, Proton, Zoho — all offer "view raw message" or "show original" in the message menu.

Copy everything from the first line down to the first blank line. That blank line is the boundary between headers and body, and the body is not needed here. Pasting the whole message works too — everything after the blank line is ignored.

Received: the path, read backwards

Every server that handles a message adds a Received line at the top of the header block, above everything already written. The block therefore ends up in reverse chronological order: the last server to touch the message is the first line you see, and the sender is at the bottom.

This tool flips them, so the first hop shown is where the message started. Each line names the host that handed the message over, the host that took it, the address it came from, and the time. The gap between two timestamps is how long the message waited at that point.

One detail worth knowing: the name in brackets is not what the sending server claimed to be. It is the result of the receiving server looking the address up in reverse DNS. When those two disagree — the server says one name, its address resolves to another — receivers notice, and it is a common reason mail lands in spam with SPF and DKIM configured perfectly.

Authentication-Results, and how much to trust it

This header records what the receiving server decided about SPF, DKIM and DMARC. It is the closest thing to a verdict a message carries.

It is also, on its own, worthless as evidence. The header is written by whoever received the message, and nothing prevents a sender from writing one themselves — a forged line is indistinguishable from a genuine one by inspection. What makes it trustworthy is the server that added it. A line added by your own provider on mail you received is meaningful. The same line in a message somebody forwarded you proves nothing at all.

This is exactly why the header block is read from the bottom up. Anything above the point where your own infrastructure took over is the sender's word for it.

Why DMARC fails when SPF and DKIM pass

This is the single most common confusing result, and it looks like a contradiction until you know what DMARC actually checks.

DMARC does not ask whether a check passed. It asks whose domain passed it. A SPF pass counts only if the envelope domain matches the domain in the visible From. A DKIM pass counts only if the signing domain matches it. Either one is enough, but at least one has to line up.

Mail sent through a provider routinely passes both and aligns with neither. The envelope belongs to the provider's bounce domain, the signature belongs to the provider, and the reader sees your name in From. Both checks are genuine, and DMARC still fails, because as far as it is concerned three unrelated domains are involved.

The fix is not to add another SPF include. It is to sign as your own domain — every serious provider supports this, usually by having you publish a CNAME at selector._domainkey.yourdomain.com that points at their key. Once the signature carries your domain, alignment follows and DMARC passes.

Strict and relaxed alignment

DMARC accepts two degrees of match, and the difference matters when subdomains are involved.

• Relaxed — the default. The organizational domains have to match, so a signature from mail.example.com is aligned with a From at example.com.
• Strict — set with adkim=s or aspf=s. The domains must match exactly, and the subdomain above no longer counts.

Strict alignment is worth having only when you know every sending path signs with the exact domain. Turning it on with a provider in the mix is a reliable way to break your own mail.

What the delays tell you

Seconds between hops are normal. A minute or more usually means one of two things. Either the receiving server had a queue, which is nobody's fault and nothing to fix, or the message was greylisted — deliberately deferred because the sender was unfamiliar, then accepted when the sending server retried a few minutes later.

Greylisting is a useful signal in itself: it happens to new sending addresses and stops happening as they build a history. Seeing it on every message from an address that has been sending for months suggests the receiving side is not recognising you, which usually traces back to reverse DNS or a rotating pool of sending addresses.

What headers cannot tell you

They describe one message on one journey. They say nothing about whether the recipient's address exists, whether the mailbox is full, whether the content triggered a content filter, or what the domain's reputation looks like across a whole campaign. A message can traverse a perfect path with three green checks and still land in Promotions.

For the parts that are configuration rather than delivery, the record checkers are more direct: they read what is published in DNS right now, rather than what one message happened to encounter.