Every delivery question has its answer in the headers. How to trace a message's path through Received lines and decode Authentication-Results like a postmaster.
When a customer says your invoice went to spam, or a campaign underperforms at one provider, the diagnostic evidence is already sitting in the delivered message. Full headers record every server that handled the mail, every authentication check the receiver ran, and often the spam verdict itself. Reading them fluently is the single highest-leverage skill in deliverability debugging, and it takes about one article to learn.
Getting the raw headers
Every client hides them somewhere. Gmail exposes them under "Show original", which also renders a convenient SPF/DKIM/DMARC summary table. Outlook desktop buries them in file properties; Outlook web offers "View message details". Apple Mail shows them via "All Headers". For anything systematic, get the raw source into a text editor rather than squinting at a preview pane.
Tracing the path: Received headers
Each server that accepts a message prepends a Received header, so the chain reads in reverse: the bottom Received line is the origin, the top is the final delivery hop. Each line names the handing-off host (from), the accepting host (by), the protocol, and a timestamp. Walking the chain bottom-up reconstructs the full route, and the timestamp deltas between hops expose where a message sat in a queue.
1Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41])
2 by mx.google.com with SMTPS id abc123
3 for <user@gmail.com>; Sun, 13 Jul 2025 06:14:22 -0700 (PDT)
4Received: from out-3.smtp.esp-partner.com (out-3.smtp.esp-partner.com [198.51.100.3])
5 by mail-sor-f41.google.com with ESMTPS
6 Sun, 13 Jul 2025 06:14:20 -0700 (PDT)
7Received: from app-server-7.internal (unknown [10.2.3.7])
8 by out-3.smtp.esp-partner.com with ESMTPA id xyz789;
9 Sun, 13 Jul 2025 06:14:19 -0700 (PDT)Three patterns show up constantly in practice. Large timestamp gaps between two hops mean queuing, usually deferrals at the receiving side; correlate with 4xx responses in your MTA logs. An unexpected intermediate host means forwarding or a security gateway you did not know about, which explains many authentication anomalies. And an origin hop showing an unexpected application server answers the classic who sent this question during incident response.
The verdict line: Authentication-Results
The Authentication-Results header (RFC 8601) is where the receiving provider records its checks. It names the server that performed the evaluation and lists each mechanism's outcome with the identifier it evaluated. This header, stamped by the final receiver, is the authoritative answer to did our authentication work, far more reliable than any sender-side assumption.
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=s2025b header.b=K9dQ2mXe;
spf=pass (google.com: domain of bounce@mail.example.com designates
198.51.100.3 as permitted sender) smtp.mailfrom=bounce@mail.example.com;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.comRead the identifiers, not just the verdicts. dkim=pass tells you a signature validated; header.i tells you whose. spf=pass evaluates the envelope domain in smtp.mailfrom, which is why SPF can pass while DMARC's SPF alignment fails, the distinction our DMARC aggregate reports article covered in XML form. dmarc=pass with the policy in parentheses confirms alignment succeeded and shows the policy the receiver saw.
The failure vocabulary
Beyond pass and fail, the intermediate results carry diagnostic meaning. neutral and none mean no usable record or signature. temperror is a DNS lookup problem, often transient, and a spike of them points at your DNS provider. permerror means the record itself is broken, a malformed SPF string or an unparseable DKIM key, and will fail identically for every receiver until fixed. dkim=fail with body hash mismatch in the comment means content was altered in transit, the signature of a rewriting gateway or list.
The supporting cast
A handful of other headers rounds out the picture. Return-Path records the envelope sender the receiver saw, the address bounces go to and the domain SPF evaluated. Received-SPF is a per-hop SPF result some receivers add with the checked IP inline. ARC headers (ARC-Authentication-Results and friends) preserve the original authentication verdicts across forwarding, covered in our ARC article. X-headers vary by provider: Microsoft's X-Forefront-Antispam-Report encodes its spam scoring compactly, and while Google publishes no equivalent, the absence of an X-header is not the absence of a verdict.
A repeatable five-minute workflow
Header triage
- 1
Check Authentication-Results first
Any result other than pass on all three mechanisms is the lead suspect. Note the exact identifiers evaluated.
- 2
Confirm the identifiers match intent
The DKIM d= should be your domain, not your ESP's. The Return-Path domain should be your configured bounce domain. Mismatches explain alignment failures instantly.
- 3
Walk the Received chain bottom-up
Verify the origin is your infrastructure, look for surprise intermediaries, and read timestamp gaps for queuing evidence.
- 4
Compare against a healthy specimen
Keep a known-good delivered message from each major provider as a reference. Diffing a problem message against the baseline surfaces what changed.
- 5
Archive the evidence
Save headers from incident messages. Provider escalations and postmaster forms ask for them, and patterns across incidents only emerge from kept records.
Header fluency compounds. The first read takes ten minutes with this article open; the twentieth takes ninety seconds and immediately sorts authentication problems from routing problems from queuing problems. For a skill that costs one afternoon, it retires more guesswork than any tool subscription in the deliverability budget.
Frequently Asked Questions
Can I trust Authentication-Results in a forwarded message?
Why do I see multiple Authentication-Results headers?
What does dkim=pass but dmarc=fail mean?
Is there a tool that does this analysis automatically?
Key Takeaways
- Received headers stack newest-first; read bottom-up to reconstruct the delivery path and its timing
- Received lines below your own infrastructure's hops are forgeable and only the receiver-stamped hops are trustworthy
- Authentication-Results from the final receiver is the authoritative SPF, DKIM, and DMARC verdict, identifiers included
- permerror means a broken record failing everywhere; temperror means DNS trouble; body hash mismatch means content was modified in transit
- Keep known-good reference headers per provider and diff problem messages against them
Related articles
Greylisting, Tarpitting, and Other Receiver Defenses Senders Should Understand
Receiving servers defend themselves with deliberate delays, temporary rejections, and traps for impatient senders. How each defense works and how a good MTA passes them.
Building a Deliverability Monitoring Stack
Postmaster Tools, SNDS, FBLs, DMARC reports, TLS-RPT, bounce logs, engagement data: the full observability stack, what each layer catches, and the alerts worth paging on.
Duplicate Sends: Idempotency in Email Pipelines
Everyone has received the same email twice. The retry loops, queue semantics, and race conditions that cause duplicates, and the idempotency patterns that stop them.