Email Header Analyzer: How to Read Every Field That Matters (and What It Cannot Show You)
Key Takeaways
|
You paste an email header into an analyzer and everything looks right. SPF passes. DKIM passes. DMARC passes. The Received chain looks normal, and there are no obvious routing or authentication issues. Yet the email still lands in Spam.
That's because an email header only shows how a message was authenticated and routed. It doesn't record where the mailbox provider ultimately placed it. Inbox, Promotions, Junk, or Spam are filtering decisions made after the checks captured in the header.
This guide explains how to read every important field in an email header, what each one tells you about a message, and where header analysis reaches its limit when you're troubleshooting email deliverability.
What an Email Header Analyzer Actually Reads
An email header analyzer takes the raw, machine-facing metadata attached to every message and parses it, per RFC 5322, into a readable view of three things: the route the message took (the Received chain), the authentication results it collected (Authentication-Results), and the timing across each hop. Only the header text is required to run this analysis; the message body is not necessary.
A header analyzer functions as a receiver-side, after-the-fact, single-sample diagnostic. It reads one message that has already arrived at one mailbox.
Most email clients hide the header by default because it is built for machines rather than people. The fields are appended by every server the message passes through, under RFC 5321 (SMTP), which is why the header grows as the message travels rather than remaining fixed at the point of sending. A header analyzer does not alter any of this data; it simply converts dozens of technical lines into something that can be diagnosed within a minute.
How to Pull the Raw Header From Gmail, Outlook, Apple Mail, and Yahoo
Every major client exposes the raw header a few clicks deep. In most cases, only the header text is required, not the full message source.
| Client | Path to raw header | Note |
|---|---|---|
| Gmail | Open the email, then select the three-dot More menu, then Show original | Opens in a new tab with a Copy to clipboard option |
| Outlook.com / new Outlook | Select the three-dot More actions menu, then View message source or View internet message headers | Wording varies by version |
| Classic Outlook (desktop) | Open the email in its own window, then select File, then Properties | The header text appears in the Internet headers box |
| Apple Mail | Select View, then Message, then All Headers, or Raw Source for the full message | Raw Source includes the message body |
| Yahoo Mail | Select the three-dot More menu, then View raw message | Copy the full raw message |
| Thunderbird | Press Ctrl + U (Cmd + U on Mac) with the message open | Opens the raw source in a new window |
For readers troubleshooting their own outbound mail rather than an inbound message, the raw header tells only half the story. It is also worth confirming that the Gmail SMTP setup sends through the correct relay in the first place.
Once the header text has been copied, it should be pasted into a parser. MxToolbox and Google's Admin Toolbox Messageheader are two common free options; both normalize the timestamps, order the hops, and surface the authentication results without requiring the reader to parse raw text line by line.
Every Header Field That Matters, and What Each One Tells You
An email header contains dozens of fields, but only a handful are useful for troubleshooting delivery, authentication, or routing issues. Knowing what each field records, and how they relate to one another, helps you separate normal behavior from a genuine problem. This section explains the header fields that matter most, what each one tells you, and when it's worth paying closer attention.
| Field | What it is | What it tells you | What it does not |
|---|---|---|---|
| Received | One line per server hop, added as the message travels | Origin, path, and timing between hops | Whether the sending domain was authorized, which is SPF's function |
| Return-Path | The envelope sender (MAIL FROM), where bounces are directed | The domain handling delivery failures | Whether that domain matches the visible sender |
| From | The visible sender address | The claimed identity | Almost nothing on its own, since it is trivially spoofable |
| Reply-To | The address to which replies are routed | A possible redirection signal if it diverges from From | Whether that divergence is malicious, since a great deal of legitimate mail behaves this way |
| Authentication-Results | A receiver-added summary of SPF, DKIM, and DMARC | Whether the message authenticated and aligned | Whether the message reached the inbox |
| DKIM-Signature | The cryptographic signature, carrying d= and s= tags | Which domain signed the message, and with which key selector | Whether the signature belongs to the sender's own domain or to a third-party platform |
| ARC set (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) | The Authenticated Received Chain, formalized under RFC 8617 in 2019 | The original authentication results, preserved across forwarding | Whether the current hop revalidated those results, which is what cv= reports |
| Message-ID | A unique identifier assigned to each message | Whether an identifier is missing, malformed, or reused across sends | Little else about content or intent on its own |
| X-* headers | Non-standard, vendor-added fields | The actual sending infrastructure behind a corporate From | Standardization, since these vary by provider and are not guaranteed to appear |
Received functions as the routing log. It should be read from bottom to top: the oldest entry is the server that first accepted the message, and each receiving server stacks a new line above it. Together, these entries record the route, the timestamps, and the connecting IP addresses, making this the fastest way to trace where a message originated or where a delay occurred along the way.
Return-Path carries the envelope sender used for bounce handling and is added by the final receiving server. It is common, and not inherently suspicious, for Return-Path to differ from the visible From, particularly for mail sent through a third-party platform.
How to Read Authentication Results (SPF, DKIM, DMARC) in a Header
Authentication-Results is added by the receiving mail server after it evaluates SPF, DKIM, and DMARC. A typical line contains spf=pass, dkim=pass, and dmarc=pass, along with the domains each check evaluated. Together, these results indicate whether the message authenticated and whether the authenticated domains align with the sender's claimed identity, not whether the message reached the inbox.
This is the detail that most often causes confusion: SPF and DKIM can each pass while dmarc=fail. DMARC reads the SPF and DKIM results and asks: does the domain that passed align with the domain shown in the visible From?
A message can authenticate correctly on the sending platform's domain and still fail DMARC, because that domain does not match what the recipient sees in the inbox.
When something appears incorrect, the DKIM-Signature field is the next place to check. The d= tag identifies the domain that signed the message, while s= identifies the selector used to locate the public key.
When d= differs from the visible From, the message was likely signed by a third-party email service provider rather than the sender's own domain. This pattern is common for legitimate marketing and transactional mail, but it remains a useful context when verifying who actually sent a message.
The ARC set exists for one practical reason: forwarding and mailing lists rewrite content and change the sending IP, which breaks SPF and DKIM, which then fails DMARC downstream even when the original message was legitimate.
ARC preserves the original authentication results at each hop, so that a later mail server can see how the message authenticated before it was forwarded. The cv= tag on ARC-Seal reports whether that chain validated: none, pass, or fail.
Using a Header Analyzer to Spot Spoofing and Phishing
Rather than trusting a sender name or message content on its own, a header analyzer exposes the routing history and authentication results that reveal where a message actually originated.
When reviewing a suspicious message, the following fields should be checked together rather than in isolation.
- From, Return-Path, and Reply-To: These addresses do not always match, and a mismatch alone is not automatically suspicious. It is worth investigating further when Reply-To points to an unrelated domain or redirects responses somewhere unexpected.
- The Received chain: This should be read from bottom to top. Unexpected mail servers, unusual geographies, or infrastructure that does not match the sender's normal provider are signals worth pursuing.
- Authentication-Results: A dmarc=fail, or authentication that does not align with the visible From domain, is one of the stronger indicators that a message is not what it claims to be.
- Message-ID: Identifiers that are missing, malformed, or repeatedly reused across multiple messages point toward suspicious sending infrastructure.
What a Header Analyzer Cannot Tell You
A header does not record where the message landed. A header showing spf=pass dkim=pass dmarc=pass can belong to a message sitting in the spam folder. The header carries authentication results and routing information, but it has no field for inbox, spam, or promotions.
That placement decision is made after the results of the header records, based on sender reputation, engagement history, content signals, and other factors evaluated by the mailbox provider.
A header describes one message, on one path, at one point in time, as seen by one recipient. It says nothing about other sending sources, other mailbox providers, or whether the pass being read today will still hold next week, once an ESP is added, a DKIM key rotates, or a token expires quietly in the background.
A header is reactive. Only a message that has already been sent can be analyzed. By the time the header is being read, the send has already happened.
From One Header to the Full Picture: DMARC Reports, Inbox Placement, and Continuous Monitoring
A header analyzer and a deliverability platform read the same underlying signals: authentication results, routing, and sending source. The difference lies in scope and cadence. A header reads these signals once, for one message, after the fact.
Continuous monitoring reads them across every source and mailbox provider on an ongoing basis, before a small drift becomes a folder problem.
That continuous layer covers three areas a single header cannot reach.
- DMARC aggregate reports that surface every IP address and service sending under a domain: the scaled version of the single Authentication-Results line a reader would otherwise check message by message.
- Inbox placement testing across Gmail, Outlook, and Yahoo: the folder outcome no header field records.
- Ongoing authentication monitoring that catches a DKIM key rotation, a new ESP, or a configuration drift before it appears in falling inbox rates.
| Approach | What it shows | What it misses |
|---|---|---|
| Manual header reading | Routing and authentication for one message, read by hand | Does not scale beyond a handful of messages; no placement data |
| Free parser (MxToolbox, Google Admin Toolbox) | The same information, formatted and normalized for readability | Still one message, at one point in time |
| DMARC-vendor analyzer (EasyDMARC, PowerDMARC, Sendmarc) | Header parsing plus SPF, DKIM, and DMARC record checks against a domain | Domain configuration, not folder placement or ongoing monitoring across every source |
| Continuous monitoring (Mailora) | Header-level authentication, DMARC aggregate data across every sending source, and inbox placement across providers, tracked over time | Not built for a one-off parse; designed for ongoing visibility rather than a single-message lookup |
Mailora connects header-level authentication, DMARC aggregate data across every sending source, and inbox placement testing across mailbox providers into one continuous view.
A header analyzer explains what happened to one message. It does not explain what is happening to all of them, or where they are landing.
Run your first deliverability test
FAQs
How do I read an email header?
Pull the raw header from the email client in use; in Gmail, this is done through Show original. Paste the header into a header analyzer, read the Received chain from bottom to top to trace the route, and then check Authentication-Results for the SPF, DKIM, and DMARC verdicts.
What does the Authentication-Results header tell you?
It is a receiver-added summary of how the message authenticated: the spf=, dkim=, and dmarc= fields, along with the domains each check evaluated. It indicates whether the message was authenticated and aligned, not whether it reached the inbox.
Can an email header tell me whether my email went to spam?
No. A header records authentication and routing, but it has no field for folder placement. A message with spf=pass, dkim=pass, and dmarc=pass can still land in spam, because the mailbox provider decides placement after the verdicts the header captures.
Why do SPF and DKIM pass but DMARC still fails?
DMARC requires alignment, not merely a passing check. The domain that SPF or DKIM authenticated must match the domain shown in the visible From. If a message passes SPF on an envelope domain that differs from the From, and DKIM does not align either, DMARC fails despite two passing checks underneath it.
What is the difference between an email header analyzer and a deliverability test?
A header analyzer reads one message that has already arrived, covering its authentication and route at one point in time. A deliverability test checks where mail actually lands across providers and monitors authentication across every sending source continuously, answering the placement question a header structurally cannot.
Stay in the loop
Deliverability insights, product updates, and early access to new features. No spam, unsubscribe anytime.
By subscribing, you agree to our Privacy Policy. Unsubscribe anytime.