Skip to content
DMARC
Diagnosis of a received message

Free email header analyzer

What a message really says about its sender.

A message displays a sender; its headers say who actually delivered it. This analyzer reads the SPF, DKIM and DMARC verdicts recorded by the receiving server, recomputes alignment and rebuilds the route hop by hop.

  • Free
  • No account
  • Instant result
  • Runs in the browser

Analyze a message

The analysis runs in the browser: headers are sent to no server.

Gmail: "Show original". Outlook: "Properties" then "Internet headers".

How it works

  1. 1

    Copy the original message

    In Gmail, "Show original"; in Outlook, "Properties" then "Internet headers". The header block alone is enough.

  2. 2

    Paste it into the field

    The analysis runs in the browser: headers are sent to no server, and the message body is never read.

  3. 3

    Instant verdict

    SPF, DKIM and DMARC verdicts appear with their alignment, the ARC chain and the route through every server crossed.

Why it matters

A phishing message displays a credible sender; only the headers added by the receiving server say where it truly came from. Conversely, a legitimate message that landed in the spam folder leaves the cause in those same headers: a missing signature, alignment broken by a third-party sender, or a relay that breaks SPF.

Invisible spoofing

A "From:" field is forged in one line. Without reading the authentication verdicts, nothing on screen separates the real from the fake.

Broken alignment

SPF can be valid for a third-party sender’s envelope without covering the displayed domain — DMARC then fails despite a "pass".

Unexplained spam folder

Without its headers, a filtered message never gives up its cause: missing signature, intermediate relay or delivery delay.

What headers contain

A message carries dozens of technical fields that mail clients hide. "Authentication-Results" (RFC 8601) holds the SPF, DKIM and DMARC verdicts issued by the server that accepted the message. "DKIM-Signature" names the signing domain and its selector. The "Received:" fields, prepended by each relay, retrace the route backwards. "ARC-Seal" (RFC 8617) attests to the original verdicts when a relay modified the message in transit.

Key point — An "Authentication-Results" header can be written freely by the sender: only the one added by the receiving server counts. The analyzer shows its authserv-id so the question stays on the table.

How the analyzer works

The analysis is text processing run in the browser: splitting fields, unfolding continuation lines, reading the verdicts, then recomputing alignment between the signing domain, the envelope domain and the "From:" field. No network request, nothing retained. In exchange, no signature is recomputed: since the message body is not supplied, the analyzer reads existing verdicts instead of redoing them.

Frequently asked questions

Are the pasted headers sent anywhere?
No. The analysis is performed by the browser, on the page itself. Nothing is transmitted to a server, nothing is retained, and closing the tab erases everything.
Does the analyzer really verify the DKIM signature?
No, and that limit is deliberate: verifying a signature requires the complete message body. The analyzer reads the verdict issued by the receiving server, which did have the whole message.
Why does DMARC fail when SPF passes?
Because SPF validates the envelope domain, not the one displayed in the "From:" field. When a third-party sender ships with its own envelope, SPF passes without being aligned — DMARC then requires a DKIM signature from the displayed domain.

Read what a message does not show

Analyze a message

Free and instant — the analysis stays in the browser, no account required.