Email Header Analyzer

What the Header Analyzer does

Every email carries a block of headers above the content. Each server that handles the message adds lines to the top. Read in the right order, they tell you where the message came from, which servers touched it, how long each step took, and what each receiver concluded about its authenticity.

The analyzer parses those headers and shows:

• Summary: From, To, Subject, Date, Message-ID and Return-Path.
• Authentication results: SPF, DKIM and DMARC verdicts from each Authentication-Results header (RFC 8601), with the server that added them.
• The Received chain: each hop, in order from sender to recipient, with timestamps and the delay between hops.
• DKIM signatures: signing domain (d=) and selector (s=) from each DKIM-Signature header.
• Alignment: whether the domains that passed SPF or DKIM match the visible From domain, which is what DMARC needs.
• ARC headers, if present, which some forwarders add to record earlier authentication results.

It runs in your browser. Nothing is uploaded. The parsing happens on your device, so you can safely analyze headers from internal mail.

How to read the results

• Pass. The receiving server reported a pass, and the domain aligns with From where alignment matters.
• Warning. Something passed but with a caveat, such as DKIM passing for a domain that doesn't align with From, a softfail, or a long delay between two hops.
• Fail. The receiver reported fail, permerror or temperror, or DMARC failed.
• Not tested. The header doesn't contain that result. Many internal messages, for example, have no Authentication-Results header at all.
• Not applicable. The result doesn't apply here, such as DMARC for a message whose From domain publishes no DMARC policy (the receiver reports dmarc=none).

Reading the Received chain

Received headers are added at the top, so the first one you see is the last hop. The analyzer reverses them so you read the journey from start to finish. Each line looks roughly like this:

Received: from mail.sender.example (mail.sender.example [203.0.113.10])
  by mx1.receiver.example with ESMTPS id abc123
  for <you@receiver.example>; Fri, 9 Oct 2026 09:14:02 +0000

from is the server that handed the message over, by is the server that accepted it, and with ESMTPS means the hop used TLS. Large gaps between timestamps point to queuing, greylisting or an outage.

Reading Authentication-Results

Authentication-Results: mx1.receiver.example;
  spf=pass smtp.mailfrom=bounce.example.com;
  dkim=pass header.d=example.com header.s=s1;
  dmarc=pass header.from=example.com

Trust this header only when the server named first is yours or your filtering service's. Any Authentication-Results header below your own servers' entries could have been written by the sender.

Common problems and what they mean

spf=fail on mail that went through a forwarder. SPF checks the last server that delivered the message. After forwarding, that's the forwarder, not the sender. DKIM usually survives forwarding, so DMARC can still pass.

dkim=fail (body hash did not verify). Something changed the message after it was signed. Mailing lists that add footers, and gateways that rewrite links or add banners, are typical causes.

dmarc=fail with spf=pass and dkim=pass. Neither passing domain aligns with From. A marketing tool may sign with its own domain. Configure custom DKIM for your domain in that tool.

Microsoft 365 behind a filtering gateway shows compauth=fail. Microsoft is evaluating the gateway's IP instead of the original sender. Enable Enhanced Filtering for Connectors on the inbound connector so it looks past the gateway.

Limitations

• Headers above your own servers can be forged. The analyzer shows what the headers say; it can't verify them.
• It doesn't re-check SPF or DKIM itself. It reports what receiving servers recorded at delivery time, and DNS may have changed since.
• Spam scores and filter verdicts (for example X-Spam-* or Microsoft's X-Forefront-Antispam-Report) are vendor-specific. We show them but can't always explain them.
• Timestamps depend on each server's clock. A negative delay usually means a clock is wrong, not that mail traveled back in time.

Related

For a step-by-step walkthrough, read Why did this email land in spam?.