The support ticket was frustrating in its vagueness: "I'm not receiving emails from your system." The logs showed the email was sent successfully. The ESP reported it was delivered. But the customer insisted it never arrived.
The answer was buried in the email headers—a trail of timestamps, server names, and authentication results that traced the message's journey from send to (non-)delivery. Somewhere in that journey, something went wrong. But reading raw headers is like reading assembly code: technically possible, but painfully slow.
Email header analyzers parse the cryptic header data into human-readable information. They show you the path an email took, how long each hop took, whether authentication passed, and where problems occurred. When you're debugging delivery issues, they're indispensable.
How to get headers
Before you can analyze headers, you need to extract them. Every email client hides this differently.
In Gmail, open the email, click the three dots menu, and select "Show original." You'll see the raw message including all headers. Copy everything above the actual message content.
In Outlook, open the email, click File > Properties, and look for "Internet headers" at the bottom of the dialog. The text box is small and awkward, but the headers are there.
In Apple Mail, select the email, then View > Message > Raw Source. The headers are at the top of the raw message.
For programmatic access, most email APIs return headers as part of the message data. If you're debugging your own system, you can log headers when processing incoming mail.
The analyzers
Google Admin Toolbox includes a header analyzer that's simple and effective. Paste your headers, and it parses them into a readable timeline showing each server hop, timestamps, delays, and authentication results. The visualization makes it easy to spot where delays occurred or where authentication failed.
It's free, requires no account, and handles most common header formats correctly. For quick analysis, it's often the first tool to reach for.
MXToolbox Header Analyzer provides similar functionality with additional context. Beyond parsing the headers, it explains what each field means and flags potential issues. If SPF failed, it tells you why. If there was an unusual delay, it highlights it.
MXToolbox also offers related tools—blacklist checking, DNS lookups, SMTP diagnostics—that complement header analysis. When debugging delivery issues, you often need multiple tools, and having them in one place is convenient.
Mail Header Analyzer from WhatIsMyIPAddress is straightforward and fast. Paste headers, get a parsed breakdown. The interface is no-frills, but it handles the job reliably. The hop-by-hop breakdown shows the path clearly, and authentication results are highlighted.
Messageheader from Google is another Google tool (separate from Admin Toolbox) that focuses on authentication analysis. It's particularly good at explaining DMARC, SPF, and DKIM results in plain language. If you're debugging authentication failures specifically, the focused analysis is helpful.
Authentication-focused tools
DMARC Analyzer's header tool focuses specifically on authentication results. It parses SPF, DKIM, and DMARC outcomes, explaining not just pass/fail but why. If DKIM failed because of body modification during transit, it tells you. If SPF failed because the sending IP wasn't in your record, it identifies the IP.
For authentication debugging specifically, the detailed explanations save significant time compared to manually interpreting authentication-result headers.
Dmarcian's header analyzer similarly focuses on authentication, with clear visualizations of the authentication chain. Their tool shows how DMARC evaluation worked—which identifiers aligned, which checks passed, and what the final result was.
If you're implementing or troubleshooting DMARC, their tools (including the header analyzer) provide the clearest explanations available.
Developer tools
For developers who need to analyze headers programmatically, libraries exist in most languages. Python's email.parser module handles header parsing. Node.js has mailparser. These let you build header analysis into your own debugging tools or automated monitoring.
The advantage of programmatic analysis is automation. If you're processing high volumes of email and need to identify patterns in delivery issues, scripted analysis scales better than manual tool usage.
Haraka, the Node.js SMTP server, includes header analysis in its plugin ecosystem. If you're running Haraka for email processing, you can analyze headers as part of your mail flow rather than as a separate debugging step.
What to look for
Header analyzers present the data, but you need to know what matters.
Timestamps tell you about delays. Each server that handles the email adds a Received header with a timestamp. Comparing timestamps shows how long each hop took. A message that took 30 seconds total but spent 25 seconds at one hop has a bottleneck worth investigating.
Authentication results show whether SPF, DKIM, and DMARC passed. Look for the Authentication-Results header added by the receiving server. Failures here often explain why emails land in spam. The analyzers parse these results, but understanding what they mean requires knowing how email authentication works.
The path shows which servers handled the email. Unexpected servers in the path might indicate forwarding (which can break authentication) or routing issues. The path should make sense given your email infrastructure.
Spam scores, when present, show how the receiving server evaluated the message. Some servers add X-Spam-Score or similar headers. High scores indicate content or reputation issues.
Return-Path and envelope information show the technical sender, which might differ from the visible From address. Mismatches here can indicate forwarding or potential spoofing.
When headers aren't enough
Headers tell you what happened, not always why. If an email was rejected, headers might show the rejection but not the detailed reason. For that, you need SMTP logs from the sending server, which capture the actual error messages returned during delivery.
Headers also can't tell you about emails that were never sent. If your system failed before handing the email to the mail server, there are no headers to analyze. Application logs are the debugging tool for pre-send failures.
For deliverability issues beyond individual emails—reputation problems, blacklisting, systematic spam filtering—headers provide data points but not the full picture. Deliverability monitoring tools complement header analysis for broader issues.
Frequently asked questions
Why do headers show multiple Received entries?
Each server that handles an email adds its own Received header. The email might pass through your application server, your ESP's servers, intermediate relays, and the recipient's mail servers. Each hop adds a header, creating a trail of the message's journey.
What does 'softfail' mean in SPF results?
SPF softfail (~all in your SPF record) means the sending IP isn't authorized but you're not confident enough to request rejection. Receiving servers typically accept the email but may treat it with suspicion. It's a weaker signal than hardfail (-all), which requests rejection.
Can headers be forged?
Headers added by servers you don't control can be trusted (they're added by the receiving infrastructure). Headers that were present when the email was sent can potentially be forged by the sender. This is why authentication (SPF, DKIM, DMARC) matters—it provides verified information that can't be forged.
How do I find headers for an email that wasn't delivered?
If the email was never delivered, the recipient doesn't have headers to share. You'll need to check your sending server's logs for the SMTP transaction, which will show any error responses from the receiving server. The sending server's logs are your debugging resource for failed deliveries.