Email Header Analyzer

Every email carries a layered audit trail in its headers. The Received: chain documents every relay the message passed through — added newest-first by each MTA so the bottom-most line is the originator and the top-most is the inbox. Reading bottom-up gives you the geographical and infrastructural path: domain/IP of the sender every intermediate relay the receiving MX the local SMTP delivery. When delivery is intermittent or seemingly slow the Received chain shows you exactly which hop is sitting on the message — usually a greylist on the receiving side or a queue back-up on the sender's side. The Authentication-Results header (RFC 7601) is what the receiving MTA wrote down after running SPF / DKIM / DMARC checks. SPF answers 'is this IP allowed to send for this domain?'. DKIM verifies a cryptographic signature against a public key in DNS. DMARC checks alignment — does the visible From-domain match the domain that SPF or DKIM authenticated? The three together are the difference between a message landing in the inbox and getting silently dropped or quarantined. The findings here are calibrated to the failure modes that actually drop mail in 2026: SPF fail/none DKIM missing DMARC fail with a non-none policy and Reply-To/From domain mismatches that look like phishing.

SPF: pass / fail / softfail / none / neutral / temperror / permerror. Pass = sending IP is on the From-domain's allowlist. Fail = explicit reject. Softfail = expected to land in spam. None = no SPF record published. Permerror = malformed SPF (often >10 DNS lookups — easy to hit with stacked include: chains). DKIM: pass / fail / none / permerror. Pass = signature verified body intact. Fail = signature didn't match (usually means the body was modified by a forwarder or the public key was rotated mid-flight). None = unsigned. DMARC: pass / fail. Fail = neither SPF nor DKIM aligned with the visible From-domain. The receiving MTA then applies the From-domain's published DMARC policy (none / quarantine / reject) to decide what to do. The operationally important rule: aim for SPF=pass + DKIM=pass + DMARC=pass on every legitimate sender. The hardest one to get right is DMARC alignment when you use an ESP — the envelope-From the ESP sends from often differs from your visible From and you need DKIM signing on your domain (d=) to align. Most ESPs (Mailgun SendGrid Postmark Resend) document the exact DNS records to add for alignment; it's a 10-minute task once and pays off forever.

Three address fields three different purposes frequent point of confusion. From: is the visible sender — what the user sees in the email client. Reply-To: where replies are routed (often unset defaulting to From). Return-Path: where bounces and delivery errors go — set by the MTA from the SMTP envelope-MAIL-FROM. Phishing sends often manipulate this triplet: a visible From: User paired with Reply-To: User captures the user's reply at the attacker's address while the From looks legit. Or the Return-Path is on a totally different domain than the visible From — common for legitimate ESPs but also the easiest spoofing vector. The analyzer here flags a Reply-To that's on a different domain than From (medium severity — frequently legit for support/ticketing but high-frequency phishing signal). It also flags a Return-Path on a different organisational domain than From (info — almost always benign but worth noting). DMARC alignment is the actual cryptographic check that catches spoofing; these field-level warnings are heuristics that catch obvious mismatches even when DMARC isn't in play.

Gmail web: open the message click the ⋮ overflow menu top-right choose 'Show original' — paste the entire 'Original Message' content. Outlook desktop: open the message File → Properties → Internet headers — copy the box. Apple Mail: View menu → Message → All Headers (Cmd+Opt+U) then select all + copy. iOS Mail: long-press the from line → Show Header. The exact paste should start with Delivered-To: or Return-Path: and end before the body — leading and trailing whitespace are tolerated.

Three common causes: (1) the SPF record is on the wrong domain — SPF is checked against the envelope-MailFrom (Return-Path) domain NOT the visible From. If you send from User but your envelope-from is User the SPF check happens against bounces.example.com. (2) the receiver doesn't run SPF for some reason (rare in 2026). (3) DNS lookup limit blown — SPF caps at 10 DNS lookups including nested includes; once exceeded receivers report 'none' or 'permerror'. Use this tool's findings + a DNS check to verify the record actually resolves where you expect.

Neither SPF nor DKIM aligned with the visible From-domain. SPF aligns when the envelope-MailFrom is on the same organisational domain as From. DKIM aligns when the d= tag in a verified signature is on the same organisational domain as From. DMARC PASSES when EITHER aligns; FAILS when both miss. The receiver then applies the From-domain's published DMARC policy: p=none (just record the failure) p=quarantine (spam folder) p=reject (block at SMTP). 'DMARC fail' is the loudest single signal that a message is either spoofed or has misconfigured ESP routing.

Gmail-to-Gmail mail still passes through multiple internal MTAs even within Google's infrastructure: an inbound queue content-scanning anti-spam then delivery. You'll typically see 4-7 hops even on a same-org message. This is normal and not a delivery problem. What matters is hop *latency* — if you see a single hop with a 60-second-plus delay that's a slowdown worth investigating (greylisting disk-full at a relay network interruption).

Authenticated Received Chain (RFC 8617) — a way for forwarders to vouch for the original SPF/DKIM/DMARC results so they survive forwarding which normally breaks SPF (new envelope-from) and sometimes DKIM (body modified). Mailing lists forwarders and auto-forwarding from one mailbox to another typically add ARC headers. When you see arc=pass in the auth-results the receiver chose to trust the forwarder's vouching. ARC is increasingly important — without it mailing lists silently fail DMARC and end up in spam.

Yes for the obvious mechanical patterns: From/Reply-To domain mismatch Return-Path on an unrelated domain DMARC fail SPF/DKIM none. It can't catch phishing where the attacker compromised a legitimate sending domain (in which case all auth checks pass and the headers look fine) or where the attacker uses look-alike domains (yourbank-support.com vs yourbank.com — the headers look 'clean' but the domain itself is hostile). For those you need brand-monitoring + user training not header analysis.

Microsoft 365 / Exchange Online add a slew of vendor-specific headers (X-MS-Exchange-* X-Microsoft-Antispam-* X-Forefront-*) that document the receiver's spam-filter verdict and routing decisions. They're useful but not standardised. The analyzer here doesn't decode every Microsoft-specific header — focus is on the cross-vendor spec headers (Authentication-Results Received From/Reply-To/Return-Path). For Microsoft-specific debugging the Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com) is the canonical tool.