Reading Email Headers to Diagnose Deliverability Problems
Email headers contain everything a receiving server saw when processing your email. Learning to read them is the fastest way to diagnose deliverability problems.
Email headers are the technical log of everything that happened to your email between send and delivery. They show you exactly what authentication results the receiving server saw, how the email was routed, and what filtering decisions were made. Knowing how to read them is a superpower for deliverability diagnosis.
How to get email headers
Gmail: Open the email → three dots menu → "Show original." The raw headers are at the top of the message source.
Outlook: Open the email → File → Properties → Internet headers.
Apple Mail: View → Message → All Headers.
Alternatively, use the email header parser — paste the headers and get a structured breakdown of routing, auth results, and issues.
The key headers to understand
Authentication-Results
This is the most important header for deliverability diagnosis. It shows what SPF, DKIM, and DMARC returned from the receiving server's perspective.
Good result: spf=pass dkim=pass dmarc=pass
Problem: spf=fail dkim=neutral dmarc=fail
Even if your DNS records look correct, a failing authentication-results header means something isn't working end-to-end. The header shows you what the receiver actually saw.
Received headers
Multiple Received: headers show the routing path — each server that handled the email adds one. Reading them from bottom to top shows the path from sender to recipient. An unusual number of hops (5+) or unexpected intermediaries can indicate routing issues.
X-Spam-Status / X-Spam-Score
Many receiving servers add a spam score header. A score above 5 typically triggers filtering. If you see a high score and auth is passing — it's a content or reputation issue, not an auth issue.
X-MS-Exchange headers
Microsoft Outlook/M365 adds several proprietary headers that indicate how EOP processed the message. These can show if the email hit a specific Microsoft filter.
Return-Path
The Return-Path header shows where bounce notifications are sent. If this doesn't match your sending domain or shows an unexpected ESP domain, it can affect spam filtering (SPF alignment depends on this matching your domain).
Common header patterns and what they mean
DKIM=neutral
The DKIM signature exists but couldn't be verified. This usually means the DNS record wasn't found — the selector in the email doesn't match any published DKIM key. Check with the DKIM checker.
SPF=softfail
The sending server wasn't in the authorized list but SPF is set to softfail (~all). This is a yellow flag. Some receivers treat softfail as a negative signal in combination with other issues.
DMARC=fail
Neither SPF nor DKIM aligned with the From domain. This is a strong signal that something in your sending setup isn't aligned correctly. Check that your From address domain matches what SPF and DKIM are signing for.
Long routing chain
If your email passes through 5+ servers before reaching the recipient, something unusual is happening with routing. Legitimate cold email should have 2–3 hops at most.
Using the header parser
Paste your email headers into the email header parser. It extracts the authentication results, routing path, spam scores, and key headers into a structured view, and flags any issues automatically. This is faster than reading raw headers and catches things that are easy to miss.
Run the checks first
Before replacing anything, run a free inbox placement test. You might find the issue is DNS, not the domain — and save yourself a week of unnecessary work.