Email Header Analyzer

Every mail client hides these somewhere different. The header block is everything above the first blank line of the raw message.

• Gmail — open the message, then the three-dot menu → Show original.
• Outlook / Microsoft 365 — open the message, File → Properties, and copy the internet headers box.
• Apple Mail — View → Message → Raw Source.
• Thunderbird — View → Message Source, or Ctrl+U.

Pasting the whole raw message is fine. Everything after the first blank line is ignored, so the body is never read.

Headers are unfolded per RFC 5322, then read in order — order and repetition both carry meaning, because each relay prepends its own Received: line as the message passes through. Reversing that stack reconstructs the route the message travelled, and the timestamps on each line give the delay at every step.

The three authentication verdicts are not recalculated here; they are read from the Authentication-Results header written by the server that accepted the message. SPF asks whether the sending IP was permitted to send for the envelope domain. DKIM checks a cryptographic signature over the message. DMARC ties those back to the From: address a person actually sees — which is the only one of the three that constrains what is displayed.

The findings then look for the gaps between those fields: a Return-Path that disagrees with From, a Reply-To pointing somewhere else entirely, a display name containing one address while the message comes from another, a Message-ID minted by an unrelated domain, and hops that carried the message in cleartext.

Headers below the first trusted hop can be forged. Anyone can write whatever Received: lines they like into a message before sending it. Only the hops added by servers you actually trust — typically your own provider’s, at the top of the chain — are evidence. Everything beneath them is a claim by the sender.

A passing DMARC result does not mean the message is safe. It means the domain is genuinely the sender. Compromised accounts send perfectly authenticated mail, and attackers routinely register their own domains and authenticate them properly.

A failure is not proof of an attack, either. Mailing lists, forwarding rules and some legitimate bulk platforms break alignment as a matter of course. The findings are evidence to weigh, not a verdict to act on alone.

The results here are only as good as the paste: if the receiving server did not record an Authentication-Results header, those verdicts simply are not in the data, and this page will say so rather than guess.

Raw headers are not innocuous. They carry internal hostnames, private IP ranges, mail platform identifiers, recipient addresses and often the structure of an organisation’s mail estate. That is exactly the material you should not paste into a server you do not control.

So this tool has no server. The parser and the entire analysis are JavaScript running in your browser: there is no upload, no logging, no analytics and no storage. You can disconnect from the network and the page will still work. Read the privacy statement.