Email Header Analyzer

Email header analyzer

Why did this message arrive late, land in spam, or fail authentication?

Analysed in your browser. Headers are never sent to our server.

Where do I find the headers?

Gmail: open the message, then the ⋮ menu → Show original → Copy to clipboard. Outlook (desktop): open the message → File → Properties → copy Internet headers. Outlook on the web: ⋯ menu → View → View message details. Apple Mail: View → Message → All Headers.

How this analyzer works

Paste the headers of one message and the analyzer does three things:

  1. Delivery path. It reads every Received: header, oldest first, and shows each hop's sender, receiver, protocol and the delay since the previous hop. ESMTPS and similar markers show that a hop used TLS.
  2. What the receiver recorded. It reads the topmost Authentication-Results header: the verdict the final receiving server reached for SPF, DKIM and DMARC when the message arrived. It also notes ARC sets added by forwarders or mailing lists.
  3. A re-check against today's DNS. It finds the connecting IP and envelope domain and re-runs SPF. It fetches each DKIM signature's public key and verifies the header signature, and it compares every domain with the From: domain to work out DMARC alignment.

How to read the results

The recorded vs. today table is the key view:

  • Recorded fail, today pass: something has been fixed since the message was sent, or the failure was caused in transit (a forwarder, a gateway rewriting the message).
  • Recorded pass, today fail: something changed in DNS since. A DKIM key was removed, an SPF include was dropped, or the record is now over the lookup limit. Messages sent today would fail.
  • Aligned? fail: the check passed, but for a different domain than the From: address. This is the most common cause of "SPF passes but DMARC fails"; see DMARC alignment, explained.

DKIM "unverified" means the key exists, but the signature couldn't be confirmed from the pasted text. Copying headers often changes whitespace, which breaks "simple" canonicalisation, and we verify header signatures only (RSA-SHA256, and Ed25519 where your browser supports it), never the body hash. The receiver's recorded result is the authoritative one for that message.

Privacy

Headers contain names, email addresses and internal server names. The analyzer runs entirely in your browser: the headers are never sent to our server, stored or logged. The only outbound queries are DNS lookups, sent from your browser to public resolvers, for the domains and selectors in the headers. If you'd rather not paste real addresses, replace the local part (before the @) with anything you like. The analysis only needs the domains.

Which headers to paste

Copy them from the receiving mailbox, where the problem showed up, not from the sender's Sent folder: only the receiver's copy has the Authentication-Results you need. The guide to reading email headers covers where to find them in each mail client and what every line means.

Updated 26 October 2026

Related checks

  • Email Blacklist Check

    Is this mail server's IP blocklisted, and is its reverse DNS set up the way receivers expect?

  • Email Record Lookup

    Is this domain's email set up correctly: MX, DMARC, DKIM and SPF?

  • SPF Validation

    Is this IP address, or this whole range, allowed to send mail for the domain?

Guides for this check

FAQ

Why does DKIM show unverified when the receiver recorded dkim=pass?

Three reasons, in order of likelihood. Copying headers often changes whitespace, which breaks the exact bytes the signature was made over — the simple canonicalisation is unforgiving, and relaxed only forgives folding. The body hash can't be recomputed at all from a header paste, because the body was never included. And the key published at the selector may have been rotated since. Because we verify against the key live in DNS today, unverified is not a verdict on the message: the receiver's recorded result is authoritative.

Why does today's re-check disagree with what the receiver recorded?

The recorded result describes the message as it arrived; the re-check describes what DNS says now. A key removed, an SPF include dropped, or a record pushed past the 10-lookup limit changes the answer without the message changing at all. A forwarder or gateway can also change it in transit: it re-sends the message, so SPF then sees the forwarder's address rather than the original sender's.

Which headers should I paste, and what happens to them?

Paste everything down to the first blank line, copied from the receiving mailbox — 'Show original' in Gmail, 'Internet headers' in Outlook. Only the receiving copy carries the Authentication-Results line that explains what the final server decided. The paste is analysed in your browser and never sent to us; only DNS queries leave the page, and you can replace the part before the @ in any address with anything you like, because the analysis only needs the domains.