About the Email Header Analyzer
Every email carries a full record of where it came from and what each server along the way thought of it. It is written in a format designed for machines, and it is the only part of a message a forger cannot fully control — which makes it the one place worth looking when something feels wrong.
This tool reconstructs the Received chain in the order the message actually travelled (the file lists it backwards, which is the mistake almost everyone makes reading headers by hand), explains the SPF, DKIM and DMARC results rather than quoting them, and surfaces the mismatches that give a forgery away: a Reply-To on a different organisation from the From, a display name with somebody else's address hidden inside it, a subject beginning “Re:” on a message that is not a reply to anything.
It gives you observations, not a score. A number would imply a confidence nobody has, and would hide the thing that actually matters — a DMARC failure on a mailing list is ordinary; the same failure alongside a foreign Reply-To and a server with no reverse DNS is not. The parsing runs entirely in your browser. The message is never uploaded. Two optional lookups sit behind a button and send only one IP address and one domain name.
Observations, not a score. A single number would imply a confidence nobody has — what matters is which of these appear together. One DMARC failure on a mailing list is ordinary; the same failure next to a foreign Reply-To and a server with no reverse DNS is not.
The two facts the headers cannot supply on their own: who actually owns the
network the message came from, and what DMARC policy the visible From domain really publishes
— because a header claiming dmarc=pass is just text, while the domain's own DNS
record is checkable. Pressing this sends only the originating IP address and the From
domain. Not the headers, not the subject, not any email address.
Hop 1 is where the message started. Servers add their line to the top of the file, so the raw order is the reverse of the journey — this is already corrected below. Trust decreases as you go down: your own provider's entries are reliable, and everything below the first server you recognise was written by someone you do not control.
The free lookup covers the originating server. This resolves the owner of every public address in the chain, which is how you spot a message that took a detour through a network that has no business being in the path.
How to Use the Email Header Analyzer
Open the suspicious message and ask your mail client for the original source — in Gmail that is the three-dot menu and Show original; in Outlook, View message source; in Apple Mail, View → Message → Raw Source. Copy everything from the top down to the first blank line and paste it in. The analysis appears immediately, because it runs on your own machine: nothing is uploaded, and if you never press the optional lookup button this page makes no network request carrying anything of yours.
The Chain Is Written Backwards, and That Matters
Every server that touches a message adds a Received line to the top of the header
block. So the last Received in the file is the first hop the message took, and
reading top to bottom walks the journey in reverse. This tool flips them and numbers hop 1 as the
origin, which removes the single most common error people make reading headers by hand.
There is a second, subtler point about that chain: trust decreases downward. The lines
added by your own provider are reliable, because your provider wrote them and has no reason to lie.
Everything below the first server you recognise was written by machines you do not control, and a sender
can simply invent extra Received lines at the bottom to manufacture a plausible history.
Read from your own provider backwards, and stop trusting the record at the first name you do not know.
Within a single hop, the same distinction applies in miniature. A line like
from mail.paypal.com (vps-4417.example-hosting.invalid [198.51.100.42]) contains two names. The
first is what the connecting machine said it was called, which is free text anyone can set. The
parenthetical is what the receiving server observed: the reverse-DNS name that the address
genuinely resolves to. When those two disagree, the second one is the true one.
SPF, DKIM and DMARC: Only One of Them Checks What You See
This is the point most explanations bury, and it decides how much weight to give each result.
- SPF asks whether the server that delivered the message was on the list of servers permitted to send for a domain. But the domain it checks is the envelope sender — a hidden address used for bounces, which you never see and which need not match the From line at all.
- DKIM verifies a cryptographic signature proving the message was not altered after
signing. But the signature says which domain made it, and that domain is chosen by whoever sent the
message. A valid DKIM signature from
bulk-mailer-xyz.neton a message claiming to be from your bank is perfectly valid and completely meaningless. - DMARC is the one that ties either of those to the address you can actually see. It requires that SPF or DKIM passed for a domain aligned with the visible From. This is why a DMARC result is weighted far more heavily here than an SPF or DKIM pass on its own — and why “SPF: pass” on a phishing email is not the contradiction it looks like.
One caveat worth holding on to: Authentication-Results is itself just a header, and a
forger can write one. It is trustworthy only when the server named in it is your own provider. The same
caution applies to a dmarc=pass that appears below an unfamiliar relay in the chain. This
is exactly why the optional lookup checks the From domain's published DMARC policy in DNS:
that record is not something the sender can write.
The Mismatches That Give a Forgery Away
Authentication failures are the strong signal, but they are not the only one, and some of the most effective fraud passes authentication perfectly because it is sent from a domain the attacker really does own.
- Reply-To on a different organisation. The mechanic at the centre of business-email-compromise: the message looks like it came from a party you know, and your reply goes somewhere else. Note that a Reply-To on the same organisation is completely normal — shared mailboxes and no-reply addresses do it constantly — which is why this tool distinguishes the two rather than flagging every Reply-To.
- An address hidden in the display name.
From: "Bank Support <help@bank.com>" <fraud@elsewhere.ru>renders in most mail clients as nothing but Bank Support <help@bank.com>. The address your client will actually reply to is the second one. This is worth stating plainly because writing a parser that falls for it is easy — ours did, on the first attempt, until the test built to catch it caught it. - A reply to nothing. A subject beginning “Re:” on a message carrying no
In-Reply-ToorReferencesheader. Genuine replies almost always carry one. Faked threads borrow the credibility of a conversation that never happened. - An originating server with no reverse DNS. Legitimate mail infrastructure almost always has a reverse-DNS name. Its absence is common on compromised hosts and disposable servers.
Why There Is No Score
It would be easy to add up the signals and print “73% likely phishing”, and it would be worse than useless. The weight of any single observation depends entirely on the others. A DMARC failure is routine on mailing-list traffic, which rewrites subjects and appends footers and breaks DKIM as a matter of course. The same failure alongside a Reply-To on an unrelated domain, a fake reply thread and an originating host with no reverse DNS is a different object altogether. A number flattens exactly the structure that carries the meaning, so this tool lists what is true and leaves the judgement where it belongs.
How This Was Tested
The parser was built against a corpus of 28 real messages pulled from the public IETF mail archive — 122 Received hops in total, including IPv6 relays, folded headers, amavis and Postfix formats, and mailing-list rewriting. Every hop must parse, the chain order must reverse correctly, and timestamps must advance along the journey. Hand-built adversarial fixtures cover the shapes a clean corpus never contains: forged Reply-To, the display-name trick, a fabricated reply thread and a lying HELO. 778 assertions pass, and the display-name test found a genuine bug in the first version of the address parser, which took the wrong bracket pair.
Checking whether a link in that message is safe? The Phishing Link Analyzer examines the destination without visiting it. Wondering whether the address was exposed in a breach in the first place, the Breach Directory covers that. Checking your own domain's sending setup rather than someone else's message, the Email Deliverability Analyzer is the one you want. Browse every Security & Privacy tool for more.
Frequently Asked Questions
Is my email uploaded anywhere?
No. The parser is JavaScript running in your own browser, and the headers you paste are never sent to our server or anywhere else. There are exactly two optional lookups, behind a button you have to press: the network owner of the originating IP address, and the DMARC policy published by the From domain. Those send one IP address and one domain name respectively, and nothing else — not the subject, not any email address, not the body. If you never press the button, this page makes no network requests with your data at all.
Why is the Received chain backwards?
Because every server that handles a message adds its own Received line to the top rather than the bottom. So the last Received header in the file is the first hop the message took, and the first one you see is the last handoff before it reached you. This tool reverses them for you and numbers hop 1 as the origin, which is the single most common thing people get backwards when reading headers by hand.
What is the difference between SPF, DKIM and DMARC?
SPF checks whether the server that delivered the message was authorised by the envelope sender's domain — a hidden address, not the one you see. DKIM checks a cryptographic signature proving the content was not altered, made by whichever domain chose to sign it. Both can pass for a message whose visible From address is a complete forgery, because neither one looks at the From line. DMARC is the check that ties them to it: it requires that SPF or DKIM passed for a domain that aligns with the From address you can actually see. This is why a DMARC result carries far more weight here than an SPF or DKIM pass on its own.
Can these headers be faked?
Partly, and knowing which part matters. Anyone can write whatever they like into From, Reply-To, Subject and Message-ID, and anyone can invent extra Received lines at the bottom of the chain. What they cannot forge is what the receiving servers wrote: each Received header added by a server you trust records the IP address it genuinely saw connecting. So read the chain from the top down — from your own provider backwards — and treat everything below the first server you recognise with suspicion. Authentication-Results is likewise only trustworthy when it was written by your own provider.
The analysis says DMARC failed. Is the email definitely fake?
It means the message could not prove it came from the domain in its From line, which is a strong signal but not a verdict. Mailing lists break DKIM routinely and innocently by modifying subjects and footers, and some forwarding setups break SPF the same way. What makes a DMARC failure damning is company: a failure alongside a Reply-To on an unrelated domain, an originating server with no reverse DNS, and a fake reply thread is a very different thing from a lone failure on a message from a list you subscribed to.
