How to Read Email Headers (A Deliverability Debugging Guide)

When an email lands in spam, the receiving server almost always tells you why — in the headers. Every message carries a full forensic record: which servers handled it, whether authentication passed, and what the spam filter concluded. Most people never look. Learning to read headers turns "my emails go to spam and I don't know why" into a specific, fixable diagnosis.

This guide covers getting the raw headers out of the major providers, reading them in the right order, and recognizing the failure signatures that account for most deliverability problems.

Getting the raw headers

You need the message as received — so for debugging your own sending, send a test to an account you control at the receiving provider and pull the headers there.

• Gmail: open the message → three-dot menu → Show original. Gmail also shows a handy summary table (SPF/DKIM/DMARC verdicts) above the raw text.
• Outlook / Microsoft 365: open the message → three-dot menu → View → View message details. In classic desktop Outlook: File → Properties → Internet headers.
• Zoho Mail: open the message → three-dot menu → Show original (older UI: View Headers).

You'll get a wall of text. Here's how to read it.

Rule one: read Received headers bottom-up

Each server that handles a message stamps a Received: header on top of the existing ones. So the bottom Received header is the origin, and the top is the final delivery — the message's journey reads bottom-to-top.

For a normal one-hop delivery (say, Google Workspace to Gmail) you'll see only a few: the sender's server handing off to the recipient's. What you're checking:

1. Does the origin make sense? The bottom hops should belong to your provider's infrastructure.
2. Is the handoff IP right? The Received line where the recipient's server accepts the message records the connecting IP — this is the IP that SPF is checked against.
3. Any weird detours? Unexpected intermediate hops usually mean a forwarding rule or relay you forgot about, which is a classic cause of authentication breakage.

Authentication-Results: the verdict that matters most

The receiving server summarizes its authentication checks in one header. Healthy mail looks like this:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [email protected] designates 203.0.113.5 as permitted sender) smtp.mailfrom=acme-example.com;
       dkim=pass [email protected] header.s=google;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=acme-example.com

Three verdicts, and you want three passes:

• spf=pass — the connecting IP is authorized by the smtp.mailfrom domain's SPF record.
• dkim=pass — the cryptographic signature verified, and header.i= tells you which domain signed. A pass from the wrong domain (e.g., an ESP's shared domain instead of yours) is a common half-configured state.
• dmarc=pass — SPF or DKIM passed and the passing domain aligns with the visible From domain. This is the one recipients' policies actually act on.

If any of these say fail, softfail, permerror, or none, stop here — that's your problem, before any reputation discussion. Our SPF/DKIM/DMARC setup guide covers fixing each, and the record checker validates your DNS side in seconds.

Spam verdict headers

Authentication says who you are; these headers say what the filter thought of you.

SpamAssassin-style (Zoho, cPanel hosts, many others):

X-Spam-Status: No, score=1.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
       HTML_MESSAGE,SPF_PASS autolearn=ham

The score versus required threshold is the verdict, and tests= lists exactly which rules fired — it will literally name the problems (e.g., URI_SHORTENER, FROM_SUSPICIOUS).

Microsoft (Outlook.com and Microsoft 365):

X-Forefront-Antispam-Report: CIP:203.0.113.5;...;SCL:1;...
X-Microsoft-Antispam: BCL:0;

• SCL (Spam Confidence Level): −1 means a rule bypassed filtering; 0–1 is clean; 5–6 goes to Junk; 9 is high-confidence spam.
• BCL (Bulk Complaint Level): 0–3 is fine; 4+ flags you as a bulk sender with rising complaint rates.

Gmail exposes no score header — its verdict is simply where the message landed, which is why the summary table in "Show original" plus Postmaster Tools is your Gmail diagnostic toolkit.

A worked example

Here's a trimmed, realistic header block from a cold email that landed in a Microsoft 365 Junk folder — domains and IPs are examples:

Received: from MW4PR04MB1234.namprd04.prod.outlook.com ...
Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41])
        by mx.microsoft.com with ESMTPS ...
Authentication-Results: spf=pass (sender IP is 209.85.220.41)
       smtp.mailfrom=acme-example.com; dkim=pass (signature was verified)
       header.d=acme-example.com; dmarc=pass action=none
       header.from=acme-example.com;
X-Forefront-Antispam-Report: CIP:209.85.220.41;CTRY:US;SCL:6;SRV:;
       IPV:NLI;SFV:SPM;PTR:mail-sor-f41.google.com;CAT:SPM;
X-Microsoft-Antispam: BCL:0;
From: Nasir <[email protected]>
Subject: Quick question about your hiring

Reading it in order:

1. Received chain (bottom-up): the message originated from Google's infrastructure (mail-sor-f41.google.com) and was handed directly to Microsoft. One clean hop — the sender is a Google Workspace mailbox, no forwarding weirdness.
2. Authentication-Results: spf=pass, dkim=pass signed by acme-example.com, dmarc=pass. Authentication is not the problem.
3. X-Forefront-Antispam-Report: SCL:6 with SFV:SPM and CAT:SPM — EOP classified it as spam on content/reputation grounds. BCL:0 says it's not a bulk-complaint issue.

Diagnosis: a fully authenticated message junked anyway. That combination — all passes, SCL 5+ — is the signature of a reputation or content problem: a young domain with no engagement history, a spammy pattern in the copy, or a domain that's been burned before. It's precisely the case warmup exists for; DNS changes won't move it.

Common failure signatures

The bottom line

Every spam-foldered email ships with its own incident report. Check Authentication-Results first — if anything fails, fix DNS and provider settings. If everything passes and the spam verdict is still bad, the filter is judging your history, and history is built, not configured.

EmailWarmer builds that history automatically — connected mailboxes exchange real conversations that get opened, replied to, and rescued from spam. The free plan covers one mailbox, free forever.