Email Header Analyzer
Deconstruct raw email headers. Decode hop routing details, metadata, and security settings.
Email Header Analyzer — decode routing and security checks
Every email carries a set of headers that reveal its routing path, authentication results, and metadata. This tool parses raw email headers following RFC 5322 — including folded continuation lines — and groups them into logical sections. The Authentication-Results header is especially important: it records whether DKIM (cryptographic signature), SPF (sender IP authorization), and DMARC (policy enforcement) checks passed or failed. A failing DKIM or SPF check can indicate a forged sender or misconfigured email server. To find raw headers: in Gmail, open the email → More (⋮) → Show original; in Outlook, File → Properties → Internet headers; in Apple Mail, View → Message → All Headers.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Reading a message's routing path from its Received headers.
- Checking whether SPF, DKIM and DMARC passed for a message.
- Working out where a delay in delivery occurred.
- Investigating whether a message is likely spoofed.
- Finding the sending IP behind a suspicious message.
Frequently Asked Questions
- Which header tells me whether an email is forged?
- `Authentication-Results`, added by the RECEIVING server. It records the outcome of SPF, DKIM and DMARC checks — and because it is written by the recipient's infrastructure rather than the sender's, it is the one header in the message a forger cannot control.
- What do SPF, DKIM and DMARC each check?
- SPF checks whether the sending IP is authorised for the envelope domain. DKIM verifies a cryptographic signature over the message, proving it was not altered. DMARC ties them to the visible From address and states what to do on failure — none, quarantine or reject.
- Why can SPF pass on an obviously fake email?
- Because SPF checks the ENVELOPE sender, not the From header you see. An attacker can send from a domain they control, pass SPF for it, and put anything in the visible From. DMARC exists precisely to close that gap by requiring alignment between the two.
- How do I read the Received chain?
- Bottom to top. Each server prepends its own line as the message passes through, so the oldest hop is at the bottom and the last one to touch it is at the top. Only the hops added by servers you trust are meaningful — anything below them can be fabricated wholesale.
- What are folded header lines?
- RFC 5322 allows a long header to continue on the next line as long as that line starts with whitespace. A parser that reads line by line without joining continuations will truncate a long `Received` or `Authentication-Results` header mid-value, which is where most header parsing goes wrong.
Common errors and gotchas
- Trusting the From header, which is trivially forged — the authentication results are what matter.
- Reading Received headers in the wrong order, since they are prepended and the oldest is last.
- Treating an SPF pass as proof of legitimacy, when it only proves the sending server was authorised.
- Assuming headers are complete, since some are added or stripped by intermediate systems.
- Overlooking that a forwarded message legitimately breaks SPF alignment.