Email header analyzer — paste raw headers and see the delivery timeline, auth verdicts, and alignment in one screen.

Five independent lenses on one raw email. Each tab focuses on a single question receivers ask; together they answer 'what actually happened to this message'.

The analyzer needs the full raw header block, not just the To/From/Subject you see in the client. Recipes for the mail apps most support tickets come from:

• Gmail (web) Open the message → three-dot menu (top right of the message, not the search bar) → 'Show original'. Copy everything from the 'Original Message' section including the initial Received: block. Gmail preserves the raw form perfectly.
• Outlook desktop (Windows) Double-click the message to open it in its own window → File → Properties → the 'Internet headers' box at the bottom. Note: Outlook truncates aggressively at ~2 KB. For long chains, save the message as .eml (drag to desktop) and open in a text editor.
• Outlook web (Outlook.com / M365) Open the message → three-dot menu → View → View message source. The entire raw email opens in a new tab. Copy the header portion (everything before the first blank line).
• Apple Mail Select the message → View menu → Message → All Headers (⌘⌥U). The headers appear in the message pane; select all + copy. For very long headers, View → Message → Raw Source (⌘⌥U twice) opens the full source in a window.
• Yahoo Mail Open the message → three-dot 'More' menu → 'View raw message'. Copy the header block that opens in the new window.
• ProtonMail Open the message → three-dot menu → 'View headers'. ProtonMail shows both the raw source and a parsed view — copy the raw pane.
• Rule of thumb Any client that lets you 'View source', 'View headers', or 'Save as .eml' will give you what you need. If your client only lets you forward the message, forwards break Received: chains and DKIM signatures — don't use forwarded copies for diagnosis.

Received: headers are added by each MTA that touches the message. They stack top-down in the raw file (top = last hop, added by the destination) but describe events in chronological order bottom-up (bottom = origin). The analyzer reverses them for you so hop 1 is where the message started.

• Anatomy of a single Received: header `Received: from <sender host> (<sender-name> [<sender-IP>]) by <receiver> with <protocol> id <internal-id> for <recipient>; <timestamp>`. Every field is optional — some MTAs skip `for`, some omit the IP, some don't include a timestamp. The parser handles all of these gracefully.
• Delay per hop The gap between consecutive Received: timestamps is the time the message spent queued at the next hop before being delivered. Anything under 1s is instant. 1–10s is normal. 10–60s means the receiver was rate-limiting or greylisting. 60s+ often means content filtering / RBL checks / manual review. Anything above 5 minutes on a single hop is worth investigating.
• Slowest hop, highlighted The stats row shows the slowest hop's index and delay. That's usually the one worth debugging first when a message arrived late — it's rarely the origin server.
• IPs in parentheticals Most `from` entries include a parenthetical with the peer's rDNS name and IP: `from foo.com (foo.com. [198.51.100.5])`. The analyzer extracts the IP, useful for cross-checking against SPF, blacklists, or geo-lookup. Missing IP usually means the MTA that added the header wasn't the receiving edge — some internal relays skip this.
• When the chain is wrong Malicious mail sometimes forges Received: headers to look like it came from a trusted origin. The trust boundary is your first receiving server — anything below (further back in the chain) is unverified. Any auth verdict on your first receiver's row is authoritative; the same verdict added by a hop before yours is not.

Authentication-Results (RFC 8601) is the header where the receiving server records what its own auth checks concluded. One line per method. The analyzer consolidates verdicts across multiple Authentication-Results headers (which happens when the message crossed a forwarder that added its own auth check).

• SPF verdicts `pass` — the sending IP is authorised for the Return-Path domain. `softfail` — not authorised but sender said ~all so accept-and-flag. `fail` — not authorised, hard reject expected. `neutral` — ?all, no policy. `temperror` — DNS lookup failure. `permerror` — usually the 10-lookup limit; treat as 'no SPF' in practice.
• DKIM verdicts `pass` — the signature verified against the published public key. `fail` — signature didn't verify (usually because the message was modified in transit, or forwarded through a list that rewrote the body). `none` — no DKIM signature at all. `neutral` — DKIM record present but not signed for this message.
• DMARC verdicts `pass` — at least one of SPF or DKIM passed AND aligned with the From-domain. `fail` — neither aligned mechanism passed. `bestguesspass` — receiver's guess; not authoritative. Look at `header.from=` inside the DMARC line to see which domain's policy was applied.
• ARC (Authenticated Received Chain) RFC 8617. When a message is forwarded (mailing lists, /etc/aliases forwards, ARC-aware relays), the forwarder writes an ARC-Seal that preserves the upstream auth verdict for the destination receiver to trust. Without ARC, a forwarded message loses its SPF verdict at every hop. Presence of an ARC-Seal is a positive signal.
• BIMI Brand Indicators. Only shown when DMARC passed at quarantine/reject strength AND the sender published a BIMI record with (in Gmail/Yahoo) a Verified Mark Certificate. If you see `bimi=pass`, the sender's logo would render in supporting clients.

This is the concept that produces the most 'authentication passes but mail is bouncing' incidents. Alignment is a separate check receivers apply AFTER SPF and DKIM pass — and it's what DMARC actually enforces.

• SPF alignment (Return-Path vs From) SPF checks the domain in the SMTP envelope (Return-Path / MAIL FROM), not the domain a user sees. Alignment requires that domain to share the organizational domain with the From-header domain. `From: [email protected]` + `Return-Path: [email protected]` → aligns. `From: [email protected]` + `Return-Path: [email protected]` → does NOT align. Passing SPF but not aligning fails DMARC.
• DKIM alignment (d= vs From) Same rule applied to the DKIM signing domain (the `d=` tag on the DKIM-Signature header). `From: [email protected]` signed by `d=example.com` → aligns. Signed by `d=your-esp.com` → does not align. This is the most common ESP misconfiguration: the ESP signs with their own domain instead of yours.
• Relaxed vs strict Relaxed alignment (default, `aspf=r` / `adkim=r`) accepts same-organizational-domain matches — `mail.example.com` and `example.com` both align to `example.com`. Strict alignment (`aspf=s` / `adkim=s`) demands exact string equality. Almost every real-world DMARC uses relaxed on both.
• How DMARC decides DMARC passes when at least one of (SPF passed AND aligned) OR (DKIM passed AND aligned). It only takes one aligned pass. Practical implication: if your ESP signs with their own DKIM domain, ensure your SPF Return-Path IS your domain, or set up DKIM signing with your domain. One aligned mechanism is enough.
• What the analyzer shows For the pasted message: the From-domain, Return-Path-domain, and DKIM d= domain. Whether each aligns at relaxed and strict levels. And the inferred DMARC verdict combining pass results with alignment — the actual answer receivers computed.

Situations where header analysis is the right first move:

Email headers can leak surprisingly sensitive information — internal server names, employee email addresses in X-headers, IP allocations, ticket-tracking IDs, and sometimes even hashes of the message body. Sending them to a remote server for parsing is a compliance risk we didn't want to force on you.

• The parser is a pure JavaScript function It runs entirely in your browser. Input goes in, structured data comes out, nothing crosses a network boundary. Verify by opening your browser's DevTools → Network panel, pasting headers, and watching zero requests fire.
• No storage No cookies for this tool, no localStorage, no analytics events with the header content. Refresh the tab and the parsed data is gone.
• You can use it airgapped Load the tool once in a browser with a network connection, then disconnect the network. The parser still works — everything is bundled into the SPA.
• Open source parsing rules The parser is standard RFC 5322 / 5321 / 8601 unfold-and-tokenise logic — no proprietary heuristics. Same rules any receiving MTA applies.

• Do I need the full email or just the headers? Just the headers. The parser stops at the first blank line — which is where headers end and the body begins per RFC 5322. Pasting the full email works too, the body is simply ignored.
• How is this different from the Email Auth Checker? The Email Auth Checker at /security/email audits a DOMAIN — what CAN pass. This analyzer audits a MESSAGE — what DID pass. If you're wondering 'why did this specific email land in spam', you need message-level answers. If you're wondering 'is my domain configured for good deliverability', you need domain-level answers.
• Can I paste headers from a forwarded email? You can, but the results will be misleading. Forwarding rewrites the Received: chain and often breaks DKIM signatures. The auth verdicts will show fail because the forwarding hop isn't authenticated as the original sender. Use the 'Save as .eml' or 'View source' recipe on the original message instead of forwarding it.
• Why does 'From' match one domain but auth was checked against another? This is the alignment concept. SPF authenticates the SMTP envelope sender (Return-Path). DKIM authenticates the signing domain (d=). Neither has to match the visible From: — and receivers now check via DMARC whether they do. The Alignment tab shows exactly this cross-check.
• What does an ARC-Seal actually protect against? It protects against auth erosion at forwarders. Before ARC, forwarding through a mailing list broke SPF (the forwarder's IP isn't in your SPF) and often broke DKIM (list software rewrites headers). ARC lets the forwarder cryptographically attest 'when I got this message, SPF/DKIM/DMARC all passed'. Destination receivers who trust the ARC signer inherit that verdict.
• Does the tool detect BEC / spoofing? It gives you the raw data to make that judgement. Look at three things: (1) does the From domain match Return-Path and DKIM d= (alignment); (2) is the Reply-To different from From (classic BEC pattern); (3) what's the sending IP's reputation (paste it into IP Lookup or IP Blacklist). Automated 'this is BEC' verdicts require enterprise anti-phishing software — we surface the ingredients.
• The DKIM `l=` tag is present — what does it mean? It's a body length limit. DKIM by default signs the entire body; `l=1024` would sign only the first 1024 bytes. Anyone can append content past the limit without breaking the signature — which means the recipient sees a DKIM pass on content the original signer never authorised. It's a legitimate SMTP feature but has been used in real attacks. Treat `l=` as a caution flag.
• Some fields show '—' — is that a bug? No — it means the header didn't include that field. Message-ID is sometimes omitted by broken mailers. Return-Path is added by the receiving MTA, so if you're looking at outbound headers before delivery it won't be there yet. Missing fields are legitimate signals themselves; the parser surfaces them as-is.