Reading email headers

Every delivered email carries a forensic record of its own journey: which servers handled it and how the receiver judged its authentication. That record is the message's headers, and reading them is the single most useful manual skill in deliverability. It turns "I think the newsletter tool is set up right" into "this message was signed by d=example.com and passed DMARC at Gmail". Ten minutes of practice, and you stop guessing.

Getting to the raw source

Every mail client can show you the full headers. They just hide the door.

In Gmail, open the message, click the three-dot menu on the message itself (not the one for the page), and choose Show original. You get the complete raw message plus a convenience: a summary table at the top with Gmail's own authentication verdicts, which is the fastest free authentication check available anywhere.

In Outlook on the web, the three-dot menu on an open message has an option to view the message source (Microsoft moves this around between versions; look under View if it is not at the top level). Classic desktop Outlook keeps headers under File, then Properties, in a small box labeled Internet headers.

In Apple Mail, with the message open, the View menu has Message, then Raw Source. All Headers, in the same submenu, shows just the header block.

Whichever client you use, copy the whole thing into a text editor. Headers read badly in a mail window and beautifully in monospace.

The Received chain, bottom-up

Each server that handles a message stamps a Received header on top of the existing ones, the way a stack of papers grows. The bottom Received line is therefore the oldest: the machine where the message entered the mail system. The top one is the final hop into the recipient's provider. Read bottom-up and you are replaying the journey in order.

Two cautions. A sender can fake the lower lines, since they arrive as part of the message, so the only Received headers you can fully trust are the ones the receiving side added itself, at the top of the stack. And internal hops with private addresses (10.x.x.x and relatives) are normal; every ESP has machinery behind its public gateway.

Authentication-Results, field by field

The receiver's verdict lives in one header, Authentication-Results, added by the receiving provider when the message arrives. It is dense, but it decomposes cleanly.

spf=pass smtp.mailfrom=bounce.example.net says SPF was evaluated for the envelope sender's domain and the sending IP was authorized. Notice which domain got checked: smtp.mailfrom is the bounce domain from the envelope, which on ESP mail is usually different from the address your readers see. SPF never looks at the visible From; the SPF lesson covers why.

dkim=pass header.d=example.com header.s=mail1 says a DKIM signature verified. header.d is the signing domain, the one whose key vouched for the message and the one DMARC will compare against the From domain. header.s is the selector, the name of the specific key used. Seeing two or more dkim= entries is common and healthy: many ESPs sign once with your domain and once with their own.

dmarc=pass header.from=example.com is the combined verdict against the domain readers actually see. It passes when SPF or DKIM passed with a domain that aligns with that From domain. Alignment is the load-bearing idea here, and it has its own lesson.

Return-Path is not From

Two different senders live in every message. From is what your reader sees and replies to. Return-Path is the envelope sender captured at delivery: bounces go there, and SPF evaluates its domain. On ESP mail the two differ by design. Mailchimp, for instance, runs bounces through its own envelope domain so its systems can process the failures; your subscribers never see that address.

A mismatch between the two is not a problem in itself. What matters is whether one authentication result aligns with the From domain, which is DMARC's whole question.

Who really sent this

Headers expose the infrastructure behind whatever brand name is on the tool. The hostname in the top trustworthy Received line, the Return-Path domain and the DKIM d= and s= values name the actual machinery. beehiiv is a clean example: its DKIM records (s1 and s2) point at SendGrid infrastructure, so a beehiiv newsletter's headers show that plumbing. Nothing shady about it, most tools build on sending platforms, but when you debug you need to know whose IPs and whose reputation are actually in play.

When we parse the emails sent to a workspace's test address, the most common surprise for the owner is the d= value. The tool's dashboard says verified; the signature says the tool's own domain, because a setup step was never finished. Your domain builds no reputation from mail signed as somebody else.

A worked example

Here is an abbreviated, illustrative header block. Real ones are longer and messier, and the domains here are the reserved documentation ones, but the shape is faithful:

Return-Path: <bounces+8834@bounce.example.net>
Received: from mail-out.example.net (mail-out.example.net [192.0.2.10])
        by mx.google.com with ESMTPS id a1b2c3
        for <reader@gmail.com>;
        Fri, 17 Jul 2026 09:14:03 -0700 (PDT)
Received: from campaign-app.internal (unknown [10.0.4.7])
        by mail-out.example.net with ESMTP id x9y8z7;
        Fri, 17 Jul 2026 09:14:02 -0700 (PDT)
Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounce.example.net;
       dkim=pass header.d=example.com header.s=mail1;
       dmarc=pass header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail1;
        h=from:to:subject:date; bh=...; b=...
From: "Example Newsletter" <newsletter@example.com>
To: reader@gmail.com
Subject: The July issue

Reading bottom-up: the message started on an internal campaign server, left through mail-out.example.net at 192.0.2.10, and was accepted by Google's gateway. SPF passed for the bounce domain bounce.example.net. DKIM verified with example.com's key named mail1. DMARC passed because the DKIM domain matches the visible From domain. This is what healthy looks like, and once you have seen it a few times, a broken message reads like a wrong note in a familiar song.

Three smaller things worth glancing at

Once the main reads become routine, a few secondary details start paying rent. The timestamps on the Received lines tell you how long each hop took; a message that sat for twenty minutes between two hops was queued or greylisted somewhere, which is a clue when someone reports mail arriving late. The presence (or absence) of List-Unsubscribe and List-Unsubscribe-Post headers is the compliance layer Gmail and Yahoo now demand of bulk senders, and it is checkable in five seconds from the same raw source.

And on forwarded mail you will meet ARC-Authentication-Results and its sibling headers: a forwarder's sealed copy of the verdicts it saw before it re-sent the message. You do not need to verify ARC by hand (no human does), but recognizing the headers stops them from looking like noise.

One habit to close on: when two Authentication-Results headers disagree, trust the one your own provider added at the top. Anything below it arrived with the message and could have been written by anyone.

Headers show you one message at a time. The DMARC reports from Part 2 turn the same forensic skill outward, onto every message that claims to come from your domain. Next, the receiver's own voice when it refuses: reading bounce messages.

Terms from this lesson

• raw source - the complete message as it traveled: every header plus the body. Every mail client can display it (Show original, in Gmail's case).
• Received chain - the stack of Received headers, one per handling server, newest on top. Read bottom-up to replay the route.
• Authentication-Results - the header where the receiving provider records its authentication verdicts for the message it just accepted.
• Return-Path - the envelope sender address recorded at delivery. Bounces go there, and SPF evaluates its domain.
• header.d - in a DKIM result, the domain whose key signed the message. Its alignment with the From domain is what DMARC checks.
• header.s - the selector: the name of the specific DKIM key used, locating the public key in DNS.

Check yourself

1. Which Received header describes the first server that handled the message?

The bottom oneThe top oneThe one containing the recipient's addressThey are in random order

2. A message From newsletter@example.com shows dkim=pass header.d=mailtool.example.net. What does that mean for DMARC?

DMARC passes, because any DKIM pass is enoughThe message will be rejected outrightThe DKIM pass does not help DMARC, because the signing domain does not align with the From domain

3. Return-Path shows a domain you don't recognize, different from the From. What is the professional read?

The message is forged and should be reportedLikely normal: ESPs route bounces through their own envelope domains, and SPF checks that domainThe DNS records are misconfigured

4. Which header content can you trust without reservation?

Every Received line, since servers write themThe Subject lineThe DKIM-Signature header on its ownThe headers added by your own receiving provider, such as its Authentication-Results