Email Header Analyser

about this tool

Two questions bring people here, and the headers already answer both. Nothing is looked up and nothing is sent anywhere.

Where did it get stuck?

Every server that handled the message added a Received: line — at the top, so the list reads backwards in time. They are reversed here, because a journey makes sense read from where it started.

Each line carries a timestamp, so the gap between one hop and the next is the delay at that hop. A message that took two hours usually spent one hour and fifty-eight minutes at a single server, and that one is named.

Is it really from who it says?

From: is typed by the sender. It proves nothing at all, and a client that shows only the display name will happily show you billing@yourbank.com on a message from somewhere else entirely.

What proves something is Authentication-Results:, added by the receiving server — the one you trust, at the point of delivery:

SPF — was the sending server allowed to send for that domain?

DKIM — does the cryptographic signature verify, and was the message unaltered in transit?

DMARC — do those line up with the domain in From:? This is the one that matters, because SPF and DKIM can both pass for a domain that has nothing to do with the visible sender.

Only the topmost result for each method is read. Anything below the receiving server's own line was added by something further upstream, which the receiver does not vouch for and neither should you.

What it points out

A DMARC failure, an SPF failure, a DKIM signature that did not verify — each one named in a sentence rather than left as a code.

A Reply-To pointing at a different domain from From, which means your reply goes somewhere other than where the message appears to come from.

A display name that is written to look like an email address at another domain. That is the oldest trick there is and it still works, because most clients show the name and hide the address.

A Return-Path that differs from From is reported as a note, not an alarm: it is completely normal for a mailing list or a sending service, and it is also what forgery looks like. The DMARC line is what settles it.

No lookups

No DNS, no API, no upload. Headers carry the sender, every recipient, the subject and the full delivery route — which is not something to hand to a website that offers to check it for you.

For the DNS records these checks are made against, DNS lookup reads SPF and other TXT records.

questions

How do I get the raw headers of an email?

In Gmail, open the message and choose "Show original". In Outlook, "View source" or File then Properties. Apple Mail has View, Message, All Headers. Paste whatever that gives you.

How can I tell if an email is really from who it says?

The From line is typed by the sender and proves nothing. What matters is the Authentication-Results header the receiving server added: DMARC pass means the message is genuinely tied to the From domain, and DMARC fail is the usual signature of a forgery.

Why was my email delayed?

Each server adds a Received line with a timestamp, so the gap between consecutive hops is the delay at each one. One large gap and the rest small means a single server held the message, and the tool names it.

Why do the Received lines read backwards?

Because each server adds its line at the top rather than the bottom, so the newest is first. They are reversed here, since a journey makes more sense read from where it started.

Does this look anything up?

No. There are no DNS queries and no API calls — every answer is already in the headers you pasted, and nothing leaves your browser. That matters, because headers carry the sender, the recipient, the subject and the whole route.