How to Read Email Headers and Diagnose Deliverability (2026)
When email goes wrong, the conversation usually goes: "Did you get it? No? Are you sure? Can you check spam? Hmm, weird, I sent it twice." What you actually need is a forensic record of what happened to that message between the moment you hit Send and the moment it (didn't) appear in the recipient's inbox. That record exists. It's called email headers.
Every email message carries a stack of headers above the body containing the originating IP, every server hop the message passed through with timestamps, the SPF/DKIM/DMARC verdicts each receiver computed, the From and Return-Path addresses, the message ID, and more. By the time a message is in your inbox, those headers tell the complete story of how it got there — or, if you have a copy from a successful send, why a parallel send failed.
This guide walks through how to extract raw headers from any major mail client, what each section of the headers tells you, what suspicious patterns to look for, and a triage tree mapping symptoms to fixes.
What you will learn: How to find raw headers in Gmail, Outlook, Apple Mail, and Yahoo, how to read the Received-chain forensic record, what SPF/DKIM/DMARC results actually mean, the seven suspicious patterns to flag, when an auth failure means "fix DNS" vs "look elsewhere," a real-world delivery-problem walkthrough, and how to use the free MiN8T Email Header Analyzer.
1 How to Find Raw Headers in Major Mail Clients
Every email message carries a stack of headers above the body — a forensic record of how the message got from sender to inbox. By the time the message reaches you, those headers contain the IP that originated the send, the chain of mail servers it passed through, the SPF/DKIM/DMARC verdicts each receiver computed, the timestamps, the message ID, the From and Return-Path addresses. They are also the only durable record of what actually happened if something goes wrong with delivery.
The first hurdle is finding them. Mail clients hide raw headers by default because most users don't want them. Each client has its own path:
Gmail (web)
Open the message. Click the three-dot menu in the top-right of the message header. Choose Show original. A new tab opens showing the full RFC-5322 message: headers above, body below. Copy the headers (everything from the top to the first blank line that precedes the body).
Outlook desktop (Windows)
Open the message in its own window (not the reading pane). File → Properties. The Internet headers textarea at the bottom contains them. Outlook 365 web is similar: three-dot menu → View message source.
Apple Mail (macOS)
Open the message. View → Message → All Headers (or Cmd+Shift+H). The headers appear above the body in the message pane. For everything-including-the-body raw view, use View → Message → Raw Source.
Yahoo Mail
Open the message. Click the More menu. Choose View Raw Message.
Apple Mail (iOS) / Outlook mobile / Gmail mobile
Mobile clients generally don't expose raw headers. The standard workaround is to forward the message to a desktop email account and inspect there.
Once you have the headers as plain text, the work is parsing them — which is where automated tools (including ours) come in.
2 What the Received Chain Tells You
The most informative headers are the Received: entries. Each mail server that handled the message added one. Reading them tells you the path the message took.
An example:
Received: from outbound.example.com (outbound.example.com [198.51.100.42])
by mx.google.com with ESMTPS id abc123def456
for <recipient@example.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 28 Apr 2026 14:23:11 -0700 (PDT)This says: the message came from a server identifying itself as outbound.example.com (with the actual reverse-DNS name and IP shown in parentheses) to Google's incoming MX (mx.google.com) over TLS 1.3, on April 28 at 14:23:11 Pacific.
Reading the chain in order
Mail servers prepend each new Received: header to the top of the message. So the bottom-most Received: in the raw source is the first hop (the sender's outbound server), and the top-most is the last (your incoming server). Read them bottom-up to follow the path chronologically.
What to look for in each hop
- Originating IP — the IP from the bottom-most
Received:. This is the actual sending machine. If it doesn't match the published SPF record for the From: domain, the message likely failed SPF. - Hop count — how many servers were involved. Direct sender-to-receiver is 1–3 hops. 5–7 is normal for forwarded messages or messages routed through multi-server infrastructure. Above 10 starts to look unusual.
- Per-hop latency — the time delta between consecutive hops' timestamps. Healthy email moves between servers in seconds. Hops with 60+ second delays usually mean a queue backup or a relay struggling. Hops with hours-long delays mean you have a delivery problem.
- Reverse DNS mismatch — when the
fromhostname doesn't match the reverse DNS of the IP. This is a common spam signal: spammers send from IPs whose PTR records don't match their claimed identity.
The chain is a forensic record. If a customer complains "your email never arrived," the chain (or its absence past a certain hop) tells you exactly where it stopped.
3 SPF, DKIM, and DMARC Decoded
The receiving server adds an Authentication-Results: header summarizing the auth checks it ran:
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=selector1 header.b=abc123;
spf=pass (google.com: domain of bounce@example.com designates 198.51.100.42
as permitted sender) smtp.mailfrom=bounce@example.com;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.comSPF (Sender Policy Framework)
What it checks: is the IP that sent this message authorized to send for the From: domain? The domain owner publishes a TXT record listing approved IPs; the receiver compares the actual sending IP against that list.
Outcomes: pass (authorized), fail (not authorized), softfail (probably not, but be lenient), neutral (no policy), none (no SPF record published).
Common failure cause: a new ESP starts sending on your behalf and you forgot to add their include: directive to your SPF record. The fix is a DNS change, not anything in the email itself.
DKIM (DomainKeys Identified Mail)
What it checks: is the message cryptographically signed by the domain it claims to be from? The sending server signs the message with a private key; the receiver looks up the public key in DNS and verifies the signature.
Outcomes: pass, fail, policy (no policy), neutral, temperror, permerror.
Common failure cause: someone modified the message body in transit (e.g., a mailing-list software added a footer), invalidating the body hash. Or the public key in DNS is missing/expired.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
What it checks: does either SPF or DKIM align with the From: domain, AND does the domain's published DMARC policy allow this kind of message?
Outcomes: pass, fail, none, policy.
Why it matters: SPF can pass if any authorized IP sent the message, even if the From: domain is forged (because SPF technically validates the Return-Path domain, not the From). DKIM can pass even if it was signed by a different domain than From:. DMARC requires alignment — the From: domain must match either the SPF Return-Path domain OR the DKIM signing domain. This closes the loophole spammers exploit.
Common failure cause: an ESP signs DKIM with their domain, not yours. SPF passes their bounce path, not yours. DMARC sees no alignment and fails. The fix is configuring the ESP to sign DKIM with your domain.
The ARC chain (forwarded messages)
When messages get forwarded through intermediate servers (mailing lists, shared inboxes), each intermediary preserves the original auth results in an ARC-Authentication-Results: header. Reading this chain tells you what auth status the message had at each hop, even after the body was modified.
4 Suspicious Patterns to Flag
Beyond raw auth verdicts, certain patterns in the headers are worth noticing. None of these is a definitive bad sign on its own — mailing lists and ESPs trip several routinely — but combinations are diagnostic.
1. From-domain ≠ Return-Path domain
A classic spoofing tell. Legitimate marketing email often has this mismatch (the ESP uses its own bounce path) but it always shows up alongside passing DKIM with your domain. Spoofed mail has the mismatch AND no DKIM alignment AND fails DMARC.
2. DKIM signed by an unrelated domain
If the From: is support@bigbrand.com but DKIM is signed by spammer-relay.tk, the receiver's DMARC check sees no alignment and either flags the message as spam or rejects it (depending on the From: domain's DMARC policy). When you see this in headers, the message is either spoofed or sent through a misconfigured relay.
3. Hop count over 10
Healthy email is 1–5 hops. 6–10 happens with forwarding chains. Over 10 hops usually means a forwarding loop, an aggressive relay setup, or an attacker laundering the message through multiple hops to obscure the origin.
4. Per-hop latency over 60 seconds
If a server took more than a minute to forward the message to the next hop, the hop is queue-backed up or struggling. Persistent latency on a specific hop is a sign that server is having delivery issues.
5. Missing Message-ID
Every legitimate email server adds a Message-ID: header on outbound. Some receivers down-rank or reject mail that lacks one. If your campaigns are missing Message-IDs, your sending infrastructure is probably misconfigured.
6. Originating IP in a known blocklist
Tools like MXToolbox and Spamhaus maintain real-time blocklists. If your sending IP shows up there, mail from that IP gets rejected or junked by receivers that consult those lists. The fix is figuring out why you're listed (often: a misbehaving customer on a shared IP, an unsecured relay, a previous-tenant problem) and submitting a delisting request.
7. No SPF or DKIM at all
If Authentication-Results: shows spf=none dkim=none, the From: domain has no published auth. This is a soft fail signal — it doesn't prove anything is wrong, but it means the receiver has no way to verify the message is legitimate. Modern receivers increasingly junk unauthenticated mail by default.
5 When to Fix DNS vs. When to Look Elsewhere
The headers tell you what happened. They don't tell you why, and the fix depends on the why. A short triage tree:
SPF fail
Action: DNS change. Your SPF record needs to include the IPs of every authorized sender. If you've added a new ESP, add their include: directive. If you're sending from an unexpected IP, figure out why — either fix the source or add it to SPF.
DKIM fail
Action: usually a DNS or ESP-config change. If the public key isn't in DNS, publish it. If the message body is being modified in transit (mailing lists, shared inboxes), the fix is harder — either avoid the modification path or accept that DKIM won't survive it (and rely on SPF + ARC instead).
DMARC fail with passing SPF and DKIM
Action: alignment. The DKIM signing domain or the SPF Return-Path domain doesn't match your From: domain. Configure your ESP to sign DKIM with your domain (most ESPs support this; you publish a CNAME record pointing at their key infrastructure).
All three pass but mail still goes to spam
Action: not a header issue. The problem is content, sender reputation, or recipient engagement. Run the body through a content scorer (our Spam Score Checker covers 21 SpamAssassin-style rules), check your domain's sender reputation on tools like SenderScore, and audit your engagement metrics. The headers can't help here — they say everything is technically correct, which is the point.
Hop count high or per-hop latency bad
Action: not your problem to fix unless you control one of the hops. Forwarding chains are usually outside your control. The exception: if YOU are one of the slow hops (your outbound mail server is queue-backed up), fix that on the infrastructure side.
6 A Real-World Walkthrough
To make this concrete, walk through a realistic scenario: a customer reports they didn't receive your password reset email. You ask them to check spam, find nothing, ask them to send you the headers of any email they DID receive from your domain (so you can compare).
You paste their headers into a parser (e.g. our Email Header Analyzer). The output shows:
- From:
noreply@yourdomain.com— correct. - Originating IP:
198.51.100.42. You check your ESP's docs — that's their outbound IP range. ✓ - Hop count: 4. Normal.
- Authentication-Results:
spf=pass dkim=pass dmarc=pass. ✓ - DKIM signing domain:
yourdomain.com. Aligned. ✓
So this email reached the customer correctly. The auth is clean. So why didn't the password-reset email arrive?
Three possibilities:
- The reset email never sent. Check your application logs. Did the call to the ESP API succeed? Did the ESP queue it? Did it dispatch?
- The reset email sent but bounced. Check the customer's email address spelling. Check your ESP's bounce log for that recipient. A typo'd address bounces back to your
Return-Path; you should see it. - The reset email sent and delivered but is in a folder you didn't check. Promotions tab in Gmail? Junk folder? Some custom filter the customer set up?
The headers from the OTHER email proved your sending infrastructure works correctly. So the reset issue is upstream of headers — either the message didn't get sent, or it bounced, or it was filtered locally on the recipient's side. Now you know which axis to investigate.
This is the value of header analysis: it tells you what to rule out, which narrows the search space dramatically.
7 Try It in the Browser
Pasting raw headers and reading them by eye works but is slow. A parser does the same job in two seconds and surfaces the suspicious patterns automatically.
MiN8T Email Header Analyzer
Paste raw email headers, get parsed output: hop trail, originating IP, SPF/DKIM/DMARC verdicts, suspicious-pattern flags, MXToolbox + Spamhaus reputation links. Free, in-browser, nothing uploaded.
Open the Header Analyzer →What to do with the output
The headers tell you the technical state at the moment the message was received. Use them as a triage step:
- If auth is failing, fix DNS first (see Section 5).
- If auth passes but mail still goes to spam, the issue is content or reputation. Run the body through our Spam Score Checker for the content side; check IP reputation on MXToolbox / Spamhaus links surfaced by the analyzer.
- If you're seeing intermittent issues across many recipients, get continuous DMARC reporting set up. The DMARC setup guide walks through publishing the right TXT records and routing reports.
Beyond one-off triage
Header analysis is reactive — you read a single message after-the-fact. For ongoing monitoring across all your sending sources, you need DMARC aggregate-report parsing (the rua reports your domain's DMARC policy collects from receivers daily). Setting that up is a separate investment, but once running, it gives you continuous visibility into auth-fail rates by source, IP reputation trends, and spoofing attempts. MiN8T's DeliverIQ handles this if you want a managed solution; or you can self-host with tools like parsedmarc if you prefer.
Reading one set of headers is a 30-second skill. Setting up continuous monitoring is a one-day project. Both are worth doing — the first for triage, the second for prevention.
Stop Fighting Deliverability After Each Campaign
DeliverIQ monitors your domain's DMARC reports continuously, alerts on auth-failure spikes, tracks reputation across all sending sources, and surfaces issues before subscribers report them. Reactive header analysis is for when something already went wrong; DeliverIQ is the prevention.
See DeliverIQ →
