Email Header Analyzer

Paste a message's raw headers — or drop in the whole .eml — and get the story they tell: the Received chain hop by hop with the delay at each step, the SPF, DKIM and DMARC verdicts your provider recorded, whether Reply-To and Return-Path quietly point at different domains than the From, and the body's links defanged and its attachments flagged. Every finding is listed with its reason and its weight. It runs entirely in your browser: headers are a map of your mail path, and maps should not be uploaded for inspection.

Or drop an .eml file anywhere in this box, or pick one:

The sample is fabricated — a "bank alert" that fails DMARC, replies to a different story than it tells, links to a raw IP and carries a statement.pdf.exe.

How to get a message's headers

Every mail client hides them one menu deeper than it should. In Gmail, open the message, click the three-dot menu and choose "Show original" — the full header block is at the top of what appears, above the encoded body. In Outlook on the web it is "View message source" under the same three dots; in desktop Outlook, open the message, then File → Properties shows the internet headers in a box at the bottom. Apple Mail uses View → Message → All Headers, or Raw Source for the whole file. To hand the analyser the complete evidence, save or export the message as an .eml (Gmail's "Download message", Apple Mail's File → Save As in raw source format) and drop the file in — headers, body and attachment names are all read from it. Headers alone are enough for the chain and authentication analysis; the .eml adds the link and attachment checks, which is where a good third of phishing evidence lives.

What this reads — and what it honestly cannot

The scope is stated plainly so the score is never mistaken for more than it is. This analyser reads headers and extracts what the body contains. It does not verify DKIM signatures — it reports the verdict your receiving server recorded in Authentication-Results when the message arrived, which is the verification that counts, done at the only moment it could be done with the original message intact. It does not re-run SPF against DNS, and it does not check URLs against threat feeds or open them: links are defanged (hxxps, dots bracketed) so you can read the real destination safely, and flagged for shape — raw IP hosts, @-sign tricks, punycode, shorteners, link text that names one domain while going to another. The score is a sum of those labelled findings, shown next to the findings themselves: points for a Reply-To on a different domain, for a recorded DMARC failure, for an executable wearing a document's name. Read the list, not just the band. The companion article, anatomy of a phishing email header, dissects one message end to end, and the sending-side companions — the email deliverability check for your records and the DMARC report analyser for the feedback they generate — cover the mirror-image job of not looking like the sample. Why legitimate mail still lands in spam despite all three protocols is covered in why your email lands in spam.

Frequently asked questions

What can email headers actually prove?

The headers a receiving server writes are evidence; the ones a sender writes are claims. Your provider's Authentication-Results records what its checks found when the message arrived, and the Received hops stamped by servers on your side of the internet are hard to forge retroactively. The lower hops — the ones nearest the sender — can be written by anyone, which is why this analyser reports what each hop says and flags timing that does not add up, rather than declaring a chain genuine. The worked walkthrough is anatomy of a phishing email header.

The message passed DMARC. Does that mean it is safe?

It means the From domain is genuinely backed by whoever controls that domain — nothing more. A lookalike domain (your bank's name with a letter swapped, registered fresh with perfect SPF, DKIM and DMARC) passes every check while being entirely fraudulent, and so does real mail from a compromised account at the real domain. Authentication answers "is this really from the domain it claims", never "should you trust what it asks". Read the ask, not just the authentication.

Does this tool verify the DKIM signature itself?

No, and it says so rather than implying otherwise. This analyser reads the Authentication-Results header recorded by the receiving server at delivery time — the verdict of a verification that already happened. Re-verifying here would mean fetching the sender's key from DNS and reproducing the exact canonicalisation of the original headers, which is a mail server's job, not a header reader's. The same honesty applies to URLs: they are extracted and defanged for inspection, not checked against threat feeds.

Is it safe to paste a suspicious email here?

Yes — the analysis runs in your browser and nothing you paste is transmitted or stored. That matters more than it might seem: headers contain your address, your provider's internal hostnames and IP addresses, and the full path a message took to reach you. Pasting them into an AI chat or an online paste service to ask "is this phishing?" publishes exactly the metadata an attacker would like to enumerate. A local reader is the right shape for the job.

The score is low but the message still feels wrong. Which do I trust?

Your instinct. The score only counts signals visible in headers and the extracted body links — it cannot read tone, urgency engineering, a faked invoice total, or the fact that your "CEO" never writes like this. A low score means the headers carry no strong technical evidence against the message; it is a floor for suspicion, not a clearance. If the ask is money, credentials or secrecy, verify it on a channel you already trust, whatever the headers say.