Mail Header Analyzer — Parse Email Headers, Trace Route & Authentication Online
Paste raw email headers to instantly extract sender/recipient info, trace the delivery route with hop-by-hop timing, check SPF/DKIM/DMARC authentication results, parse anti-spam scores, and identify all IP addresses. Includes plain-English explanations for every header. 100% client-side — headers never leave your browser.
What are email headers? Email headers are the metadata block that precedes a message body, defined by RFC 5322 as Name: value lines. Every mail server that handles the message prepends its own Received: line, so the block becomes a delivery log read newest-first. Alongside that route it carries the sender addresses, the Message-ID, and the SPF, DKIM and DMARC verdicts that say whether the sender was who they claimed to be.
How to Use the Mail Header Analyzer
- Open your email and find the option to view full headers. In Gmail, click the three dots → "Show original". In Outlook, open the message → File → Properties → "Internet headers". In Apple Mail, View → Message → All Headers.
- Copy all header text — it typically starts with "Received:" and ends before the blank line that separates headers from the body.
- Paste into the textarea above — parsing happens automatically as you paste.
- Review the Overview tab for key info (From, To, Subject, Date, Message-ID).
- Check the Route tab to see the hop-by-hop delivery path with timing between each server.
- Inspect the Authentication tab for SPF, DKIM, and DMARC results to verify the sender's legitimacy.
- Review anti-spam headers for SpamAssassin scores and verdicts.
- Copy a summary with one click for sharing in support tickets or documentation.
Understanding Email Headers
Email headers are metadata attached to every message as it travels from sender to recipient. Each server the message passes through adds a Received header, creating a chronological audit trail. Headers also carry authentication results (SPF, DKIM, DMARC), spam scores, content type information, and unique message identifiers used for threading and delivery tracking.
Received headers are read bottom-up: the bottommost Received header is the first hop (sender's server), and the topmost is the last hop (recipient's server). Each header records the sending server's identity, the connecting IP, the timestamp, and optionally the protocol and message size.
SPF (Sender Policy Framework) verifies the sending IP is authorized to send for the domain. DKIM (DomainKeys Identified Mail) validates a cryptographic signature proving the message wasn't tampered with. DMARC combines SPF and DKIM alignment to enforce a policy (none, quarantine, or reject) for messages that fail authentication.
How the Analyzer Reads a Header Block
Parsing starts with the folding rule from RFC 5322. A header may be wrapped across several physical lines as long as
each continuation begins with a space or tab, so the analyzer first walks the input line by line and rejoins those
continuations into one logical field before doing anything else. Without that step a long
Authentication-Results or DKIM-Signature value — routinely wrapped by the sending server —
would be read as several unrelated fragments.
Field names are then normalised to lower case, because header names are case-insensitive and the same field arrives as
Message-Id, Message-ID or MESSAGE-ID depending on which server wrote it. Fields
that legitimately appear more than once — above all Received — are kept as a list rather than overwritten,
which is what makes the full route recoverable.
The route view is built by splitting that list back into individual hops and reading the timestamp at the end of each
one. Hops are then ordered oldest first and the gap between consecutive timestamps is shown, so a message that sat in a
queue for forty minutes stands out immediately. Authentication verdicts are pulled from
Authentication-Results, IP literals are collected from the whole block for a single list you can check
against a blocklist, and SpamAssassin's X-Spam-Score and X-Spam-Status fields are read for the
score and the rules that fired.
Everything happens in the page — headers are never uploaded, and no lookup is performed against any external service, so no DNS or reputation query reveals that you are inspecting this message. Headers do get written into the page URL so an analysis can be reloaded; clear the box before sharing that link, since headers contain recipient addresses and internal hostnames.
Key Headers and What They Tell You
| Header | Purpose | What to look for |
|---|---|---|
Received | One entry per server that handled the message | The delivery path, the gap between hops, and the IP that first injected the message |
From | The address shown to the reader | Anyone can write anything here; treat it as a claim, not evidence |
Return-Path | The envelope sender, where bounces go | This is the domain SPF actually checks — a mismatch with From is what DMARC alignment tests |
Message-ID | Globally unique identifier used for threading | Normally ends with the sending system's domain; a missing or malformed one suggests a script rather than a mail client |
Authentication-Results | SPF, DKIM and DMARC verdicts | Written by the receiving server, so trust only the topmost instance added by your own provider |
DKIM-Signature | The signature itself | The d= tag names the signing domain and the s= tag the DNS selector holding the public key |
X-Spam-Score / X-Spam-Status | SpamAssassin's verdict | The required= value is that server's own threshold; the rule names show why the score was assigned |
Content-Type | Body structure and character set | multipart/alternative is normal for a message with both HTML and plain-text parts |
How SPF, DKIM and DMARC Fit Together
The three checks answer different questions and only make sense as a set.
SPF asks whether the IP that connected is listed in the DNS TXT record of the envelope sender's
domain — it validates the delivery path, not the message.
DKIM asks whether a cryptographic signature over selected headers and the body still verifies against
a public key published in DNS — it validates the content, and survives forwarding as long as nothing rewrites the
message.
DMARC adds the piece neither provides on its own: alignment. It requires that the domain SPF
or DKIM passed for is the same domain the reader sees in From, and then applies the domain owner's
published policy of none, quarantine or reject. That is why a message can show
SPF pass and still fail DMARC — the SPF pass belonged to a different domain than the visible sender.
Tips for Identifying Spam or Phishing
- Check the Return-Path vs. From — if they don't match, the sender may be spoofing the From address.
- Look for failed authentication — SPF "fail" or DKIM "fail" strongly suggests the email is not from who it claims.
- Examine the Received chain — legitimate corporate email usually originates from known mail servers, not residential IPs.
- Review X-Spam-Score — scores above 3.0 deserve scrutiny; above 5.0 is almost certainly spam.
- Watch for large delivery delays — legitimate mail typically traverses hops within seconds to minutes, not hours.
- Inspect Message-ID — a Message-ID that doesn't match the sender's domain is a red flag.
- Check the date — emails with future dates or dates far in the past may be manipulated.
Frequently Asked Questions
Gmail: Open the email, click the three-dot menu (⋮) next to Reply, select "Show original". Outlook: Open the email, go to File → Properties, look under "Internet headers". Apple Mail: View → Message → All Headers. Thunderbird: Open the email, click "More" → "View Source". Yahoo Mail: Open the email, click the three dots, select "View raw message".
SPF results range from "pass" to "fail" with intermediate states. A softfail (~all) means the sending IP is not authorized but the message shouldn't be outright rejected — it's a hint that the message may be suspicious. A neutral (?) result means the domain makes no claim. A hardfail (-all) means the IP is definitively unauthorized and the message should be rejected.
Email servers prepend new Received headers at the top of the header block. So the first server to handle the message adds its header at the very top, then each subsequent server pushes it down. When you read the headers top-to-bottom, you're reading from the most recent hop (recipient's server) to the oldest hop (sender's server). This analyzer displays them in chronological order (oldest first) for clarity.
SpamAssassin scores vary by configuration, but generally: 0-1.9 is not spam, 2.0-2.9 is borderline (often held for review), 3.0-6.9 is likely spam, and 7.0+ is definitely spam. The default threshold for flagging spam is usually 5.0. Some servers use stricter thresholds (3.0 or 4.0). Check your server's configuration for the exact thresholds.
Yes. Paste whatever portion of the headers you have. The tool will parse all recognizable headers from whatever you provide. Even partial headers (e.g., just the Received chain) will yield useful route and timing information.
A DKIM failure means the cryptographic signature in the message doesn't match the sender's public key. This could indicate the message was modified in transit, the signing domain doesn't match the From domain, or the DNS record for the signing key has changed. A none result means no DKIM signature was found at all — not necessarily malicious, but worth investigating.
No. The parser is JavaScript running in your tab, and it performs no DNS, WHOIS or reputation lookups, so nothing about the message leaves your device. Note that the raw headers are written into the page URL so an analysis can be reloaded or bookmarked — clear the input before copying that link into a ticket, because headers routinely contain recipient addresses, internal hostnames and private IP ranges.
The lower ones, yes. A sender controls From, Reply-To, Date, Message-ID and can prepend fake Received lines before handing the message off, so the bottom of the chain is only as trustworthy as the first server you recognise. What cannot be forged is what your own provider added: the topmost Received line and the Authentication-Results written by the receiving system. Read a chain from the top down and stop trusting it at the first hop you do not control.
No. SPF, DKIM and DMARC prove that the sending domain authorised the message, not that the content is honest. An attacker who registers a lookalike domain can pass all three checks perfectly, and a compromised account sends fully authenticated phishing from the real domain. Header analysis tells you where a message came from and whether it was altered; judging whether the request inside it is legitimate is a separate question.
Each Received line carries the time recorded by that server together with its UTC offset, and servers with drifting clocks or a misconfigured time zone can make a hop appear to take negative time or several hours. Compare the offsets before concluding a message was delayed. Genuine delays usually appear as one large gap at a single hop — typically a greylisting or queue retry — rather than as time spread evenly across the chain.
Use Cases
Tracing Email Delivery Path
Follow the complete delivery route of an email to identify where delays or failures occur.
Identifying Spam Sources
Track spam emails back to their source IP addresses and analyze anti-spam scores.
Debugging Delivery Failures
Diagnose why emails aren't being delivered by examining server responses and error codes.
Verifying SPF/DKIM/DMARC
Check email authentication results to verify sender legitimacy and prevent spoofing.
Analyzing Routing Delays
Measure time between email hops to identify slow servers and optimize delivery performance.