Inputs
Example
Paste full RFC 5322 headers to inspect raw and chronological hops, recorded SPF/DKIM/DMARC outcomes, trust classification, and parser findings.
Email Message Header Analyzer
Parse full message headers locally, preserve raw Received order, and classify recorded Authentication-Results without claiming cryptographic or reverse-DNS verification.
Useful when a delivery problem needs raw Received order and clearly labelled recorded Authentication-Results rather than an implied fresh verification.
Reading mail headers in the right direction
Full message headers answer most questions people ask about a suspicious or misbehaving mail — who really handed it over, which systems it crossed, what the receiving side concluded about SPF, DKIM, and DMARC, and where time was lost. The catch is that headers are written for machines, stacked newest-first, rewritten by intermediate systems, and salted with fields that look meaningful but are trivially forgeable. Read naively, they mislead more often than they inform.
This analyzer turns a pasted RFC 5322 header block into structured recorded evidence: Received fields in raw newest-first order plus a separate chronological view, Authentication-Results with authserv-id, method versions, properties and caller-configured trust classification, DKIM and ARC field presence, list headers, and parser findings. Recorded pass or fail values are not fresh authentication results. Everything runs locally in the browser — nothing is uploaded.
From summary to hop-by-hop evidence
Start with the summary, then read Authentication-Results and the Received chain side by side. Each relay prepends its entry, so the raw newest-first order and the chronological view are shown separately. Configure only authserv-id values you actually trust; without an explicit trust anchor, even the closest candidate is labelled unverified and lower claims are treated as potentially sender-injected.
Use the timeline hints to see where latency actually accrued — queueing at one relay looks very different from slow DNS at another. For authentication questions, compare what Authentication-Results states with the DKIM and ARC fields actually present: a missing signature, a broken chain, or a result recorded for a different domain than expected is usually the whole answer. When headers come from a forwarded or list-processed mail, rewrites are normal — read the findings with that context in mind.
A local parser, deliberately
The pasted header block is parsed entirely in the browser and is not sent to any server by this tool — worth knowing, because headers often carry personal data, internal hostnames, relay IPs, and message IDs. The parser extracts and organizes; it does not fetch DKIM keys, does not verify signatures cryptographically, and is not a forensic mail gateway. Its statements are readings of recorded evidence, not fresh validation.
Frequently asked questions
Why is the Received chain sometimes confusing?
Each relay prepends its own header, and some systems rewrite or omit details for privacy or architecture reasons. The chain is a set of claims of varying trustworthiness — which is why the parser pairs it with timestamps and findings instead of taking it at face value.
What exactly does Authentication-Results tell me?
What a named authserv-id recorded for SPF, DKIM, DMARC, or ARC at delivery time. The value becomes receiver evidence only when that authserv-id and its header position belong to a trust boundary you control; otherwise it remains an unverified claim. The tool performs neither fresh DNS authentication nor cryptographic verification.
Does the tool verify DKIM signatures cryptographically?
No. It parses DKIM and ARC fields and reports on their shape and consistency, but it does not fetch public keys or recompute signatures. Cryptographic verification is what the receiving system's own validation is for.
Is it safe to paste sensitive headers?
The tool does not upload them — parsing stays in this browser session. The judgment call is about your screen and your machine, not about a server: treat headers as the private routing data they are.
Which header fields are trustworthy?
Only fields anchored in systems and header boundaries you control. Configure the trusted authserv-id explicitly; topmost-looking Authentication-Results are otherwise only candidates, not automatically trusted. From, Subject, Date, Message-ID, lower Received fields, and unanchored authentication claims can be forged.
What are ARC headers for?
ARC preserves authentication results across forwarding steps that would otherwise break SPF or DKIM — mailing lists are the classic case. The analyzer shows the chain, so you can see whether an intermediary vouched for results it observed earlier.