Understanding Email Headers: A Technical Guide

Email headers are the structured metadata attached to every message; they record where a mail came from, every server it passed through, which authentication checks passed, and which address should receive bounces. If you can read headers, you can diagnose almost any deliverability issue without guessing. This guide explains email headers explained in practice, field by field.

The format is defined by RFC 5322, the Internet Message Format, which has been the backbone of email since 2008 (it replaced RFC 2822). Google reported that its 2024 bulk sender rules cut unauthenticated traffic to Gmail users by 65% in the first few months (Google Security Blog, 2024); nearly every deliverability failure tied to those rules shows up in the headers first.

Table of Contents

What are email headers?

Email headers are the lines at the top of a raw message that hold metadata: sender, recipient, date, subject, routing history, authentication results, and a long tail of optional fields. They sit above the body, separated by a single blank line. Most mail clients hide them; every mail server reads them.

RFC 5322 splits headers into required and optional. The required ones are short: an Origination Date (usually the Date: field) and an Originator Address (the From: field). Everything else, including To:, Subject:, Message-ID:, Received:, and all the authentication headers, is optional at the spec level. In practice, modern mail systems reject or spam-fold messages that skip the common ones.

RFC 6854 tightened the From: and Sender: grammar in 2013 to allow group syntax, which is why you'll sometimes see headers that look like From: undisclosed-recipients:; on bulk mail. It's legal; it's also a small deliverability red flag to some filters.

How do email headers work?

Every time an email hops from one server to the next, the receiving server prepends a new Received: line. The result is a stack of headers that reads, from top to bottom, newest to oldest. Combined with the authentication results and the envelope data, that stack tells you the exact path a message took and which checks it passed along the way.

The transport itself runs over SMTP, defined in RFC 5321. SMTP handles the envelope (the MAIL FROM and RCPT TO commands your server speaks); RFC 5322 handles the message that rides inside. The two are related but distinct, and the difference matters when you're chasing a bounce problem.

Here's a realistic example of what a full, raw header looks like on a message delivered to a Gmail inbox (fabricated but structurally accurate):

Return-Path: <bounces+847291-abcd@send.example.com>
Delivered-To: jordan@customerdomain.com
Received: by mx.google.com with SMTPS id 7c8d3e9f1a2b4c5d
        for <jordan@customerdomain.com>
        (Google Transport Security);
        Tue, 15 Apr 2026 09:14:22 -0700 (PDT)
Received: from mta-04.send.example.com (mta-04.send.example.com. [198.51.100.42])
        by mx.google.com with ESMTPS id g17-20020a17090a674b
        for <jordan@customerdomain.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384);
        Tue, 15 Apr 2026 09:14:22 -0700 (PDT)
Received-SPF: pass (google.com: domain of bounces+847291-abcd@send.example.com
        designates 198.51.100.42 as permitted sender)
        client-ip=198.51.100.42;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=mailneo202604 header.b=K9x3nQl2;
       spf=pass (google.com: domain of bounces+847291-abcd@send.example.com
            designates 198.51.100.42 as permitted sender)
            smtp.mailfrom=bounces+847291-abcd@send.example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=mailneo202604;
        h=from:to:subject:date:message-id:list-unsubscribe;
        bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
        b=K9x3nQl2...signature...Q==
Message-ID: <20260415161422.847291.abcd@send.example.com>
Date: Tue, 15 Apr 2026 16:14:22 +0000
From: "Avery at Example" <hello@example.com>
Reply-To: support@example.com
To: jordan@customerdomain.com
Subject: Your April shipment is on the way
List-Unsubscribe: <https://click.example.com/u/abc123>, <mailto:unsub+abc123@send.example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="==_boundary_847291=="
X-Mailneo-Campaign-ID: cmp_01HZAE6W9Y7TQ2X
X-Mailneo-Subscriber-ID: sub_01HZA7MK3R

That's about 25 lines of metadata for what the recipient sees as a one-line greeting. Every line earns its place.

What headers should you look at first when debugging deliverability?

Start with four: Authentication-Results, the topmost Received: line, Return-Path, and From:. Those four answer most of the questions you'll ever have about a single message (did auth pass, which IP handed it off, where will a bounce go, and what the recipient actually saw as the sender).

If the message looks fine but never landed, open the raw source (every mail client has a way; more on that below) and read in this order:

1. Authentication-Results: did SPF, DKIM, and DMARC all pass?
2. The topmost Received: line; which IP delivered to the final mailbox?
3. Return-Path: does it match the d= domain in the DKIM signature?
4. From:: is this the domain the recipient expects?
5. Message-ID: unique? Does the domain match what you sent from?

From there, the rest of the header stack fills in context. A mismatch between Return-Path and From: isn't automatically wrong (it's how ESPs handle bounces), but it's the single most common reason a DMARC alignment check fails silently.

Litmus, in its 2024 State of Email report, found that 77% of marketers said deliverability has gotten harder in the past 12 months; the share of respondents who regularly inspect headers to diagnose issues was under 20%. There's a gap there worth closing.

What does the Received chain tell you?

The Received: chain is a stamped log of every mail server that handled the message, added by each server as the mail passes through. It reads bottom-up: the oldest hop (usually the originating submission) sits at the bottom of the stack, and the most recent hop (the final delivery to the recipient's mailbox) sits at the top.

Each line records a few things: the sending host, its IP address, the receiving host, the SMTP extensions used, a unique transport ID, and a timestamp. If mail crossed four servers, you get four Received: lines, and you can subtract timestamps to see where time was spent. A jump of 40 seconds between hops is fine. A jump of 40 minutes between hops points at a retry queue, usually a greylisting policy or a temporary rejection.

One useful sanity check; does the IP in the bottom Received: line match what your SPF record allows? If not, someone sent mail claiming to be you, or your SPF is out of date. Both are worth fixing.

You can paste a raw header into Mailneo's email header analyzer and it'll rebuild the hop chain visually, with timing deltas flagged per hop. (I use it daily; running it by eye on a 7-hop message with international time zones is a fast way to misread a timestamp.)

What does Authentication-Results tell you?

Authentication-Results is the single most important header for modern deliverability. It records whether SPF, DKIM, and DMARC each passed, failed, or errored, and its syntax is standardized by RFC 8601. Every major mailbox provider writes one.

A pass across the board looks like this:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=mailneo202604 header.b=K9x3nQl2;
       spf=pass smtp.mailfrom=bounces+847291-abcd@send.example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Three things to read for here:

• The method (dkim, spf, dmarc) and its result (pass, fail, neutral, softfail, temperror, permerror).
• The identifier that was checked (header.from, smtp.mailfrom, header.i, header.s). These tell you which domain and selector were used.
• For DMARC specifically, the policy (p=) and the disposition (dis=). A p=REJECT with dis=NONE means the policy is enforcement-grade but the mail passed, so nothing was quarantined.

If SPF passes but DKIM fails, you've probably got a forwarding issue or a body-rewrite on a mailing list. If DKIM passes but SPF fails, your MAIL FROM domain is probably out of alignment with your ESP's IPs. If DMARC fails with both passing individually, it's an alignment issue (the domain in From: doesn't match either the SPF or DKIM domain).

For a fuller walkthrough of each protocol, see our SPF vs DKIM vs DMARC comparison, plus the per-protocol guides on SPF, DKIM, and DMARC.

What is the difference between Return-Path and From?

Return-Path is the envelope sender (where bounces go, set by the SMTP MAIL FROM command); From: is the header sender (what the recipient sees in their inbox). They're often different, and the difference trips up almost every new sender.

Say you send through an ESP. The From: might be hello@yourcompany.com (so the recipient recognizes you). The Return-Path will typically be bounces+sub12345@send.esp-domain.com (so the ESP catches bounces and suppresses future sends to bad addresses). That's standard practice; it's also how DMARC alignment can fail if your DKIM signature is over the ESP's domain rather than yours.

The fix is DKIM-aligning the signature to your domain, not the ESP's. Any decent ESP will let you set this up during onboarding. If you're seeing DMARC failures with SPF and DKIM both passing, this is the first thing to check.

How do you view full email headers in Gmail, Outlook, and Apple Mail?

Every major mail client hides headers by default; every one has a three-click path to see the raw source. Here's the exact path in each.

In Gmail (web), open the message, click the three-dot menu in the top-right of the message (not the toolbar), pick "Show original". You'll get a new tab with auth results at the top and the full raw message below. Google's support page covers this officially, including a download option for the raw .eml.

In Outlook on Windows, open the message in its own window (double-click it), then File > Properties. The headers show up in the "Internet headers" box at the bottom. Microsoft's documentation also covers the path on Outlook for Mac and Outlook on the web, which are slightly different (on the web: the ... menu > View > View message source).

In Apple Mail, select the message, then View > Message > All Headers (or Raw Source for the full thing). Thunderbird uses View > Message Source, per Mozilla's support docs.

[SCREENSHOT: e.g., "Gmail 'Show original' view with Authentication-Results highlighted"]

Once you have the raw headers, paste them into a tool that can do the structural parsing for you. Reading raw headers by eye on a coffee-stained laptop at 11pm is a recipe for missing the obvious.

Common issues you can diagnose from headers

Most of the deliverability problems I see in support tickets come down to five patterns, and all of them show up in the headers if you know where to look.

Spoofing is the first pattern. A message that appears to come from your domain but has SPF fail and a Received: line originating from an IP you don't control. DMARC with p=reject blocks this at the provider level, which is why the authentication stack matters.

Broken SPF after a vendor change is another frequent one. The topmost Received: line shows a new IP; your SPF record doesn't include it yet. Authentication-Results will show spf=fail or softfail. Fix is a DNS update.

DKIM body-rewrite failures happen when a mailing list or gateway alters the body and the DKIM signature no longer validates. Authentication-Results shows dkim=fail with a bodyhash reason. Options are narrower here; ARC (Authenticated Received Chain) helps, as do tighter canonicalization choices.

Delayed delivery also shows up clearly. The Received: timestamps jump by several minutes or hours between hops. Usually greylisting (a short temporary reject) or a queued retry on the sending side.

Missing List-Unsubscribe is the newest headache. Google and Yahoo's 2024 bulk-sender rules require one-click unsubscribe on marketing mail over 5,000/day, per Google's sender guidelines. The spec is RFC 8058; the header must include both List-Unsubscribe: and List-Unsubscribe-Post: List-Unsubscribe=One-Click. If either is missing, Gmail is now quietly spam-foldering the campaign.

[MY EXPERIENCE: e.g., "describe a deliverability issue you diagnosed from a customer's email headers — what you looked at first, what pointed to the fix"]

A note on X-headers: anything starting with X- is nonstandard. ESPs add them for their own tracking (X-Mailneo-Campaign-ID, X-Mailgun-Variables, X-SES-Outgoing, X-Postmark-Server). They don't affect delivery; they help you trace a message back to its campaign or subscriber inside your ESP. Useful for support tickets, not for auth.

Common headers and what they mean

Here's a quick reference for the headers you'll see in almost every marketing email.

Header	What it means	Required by RFC 5322?
From	The author of the message; what the recipient sees as the sender.	Yes
To	The primary recipient. Can hold multiple addresses.	No (but effectively always present)
Subject	Free-text subject line shown in the inbox list.	No
Date	When the message was composed, in RFC 5322 date format.	Yes
Message-ID	A globally unique identifier for the message; format is <local@domain>.	No (but essential for threading and deduplication)
Received	One line per server hop, stacked in reverse chronological order.	No (added by transport)
Return-Path	The envelope sender; where bounces go. Set by the final MTA.	No (added on delivery)
Reply-To	Where replies should go if different from From.	No
DKIM-Signature	The cryptographic signature; includes d= domain and s= selector.	No (but required for modern deliverability)
Authentication-Results	Results of SPF, DKIM, and DMARC checks; syntax from RFC 8601.	No (added by receiving server)
List-Unsubscribe	One-click unsubscribe URL and/or mailto:. Required for bulk senders.	No (but required by Gmail/Yahoo bulk rules)

A quick note on Message-ID format

Message-ID looks like <20260415161422.847291.abcd@send.example.com>. The left-hand side is meant to be unique per message (timestamps, random strings, campaign IDs; most ESPs combine the three). The right-hand side is a fully qualified domain, usually the sending MTA's hostname. Reusing a Message-ID across two different messages is a common bug and will break threading in Gmail.

The spec says the ID must be "world-unique", per RFC 5322 section 3.6.4; in practice, that's a UUID or a high-resolution timestamp plus a random suffix. If you see <abc@localhost> in a real production message, something is wrong with the sending server's config.

[ORIGINAL DATA: the three header anomalies you see most often in Mailneo customer deliverability tickets, ranked by frequency]

Key takeaways

• RFC 5322 requires only From: and Date:; everything else in a modern email header is technically optional but practically mandatory.
• The Received: chain reads bottom-up; the first hop is at the bottom, the final delivery at the top.
• Authentication-Results is the single most useful header for deliverability debugging, and its format is standardized in RFC 8601.
• Return-Path (the envelope sender) and From: (the header sender) are allowed to differ, and usually do on ESP-sent mail; DMARC alignment checks whether the DKIM signing domain lines up with From:.
• Missing or malformed List-Unsubscribe headers will now spam-folder bulk campaigns at Gmail and Yahoo, per their 2024 sender rules.

Frequently asked questions

Can email headers be forged?

The visible parts (From:, Subject:, even Received: lines) can be forged by anyone. The authentication headers (DKIM-Signature, and the Authentication-Results added by a trusted receiving server) are what actually prove origin. That's why SPF, DKIM, and DMARC matter; see our email authentication glossary entry for a short definition.

Why does my Received chain show a different IP than my sending server?

Because ESPs and transactional mail services send from their own infrastructure, not yours. If you send via an ESP, the bottom Received: line will show that ESP's IP range. That's expected. What matters is that the IP is authorized by your SPF record and that the DKIM signature is aligned with your domain.

How do headers relate to bounces?

Bounce messages are returned to the Return-Path address, which is the envelope sender set during the SMTP handshake. If the Return-Path domain is your ESP's domain (common), the ESP handles bounce parsing and updates suppression lists; see our bounce rate glossary entry for what those numbers actually mean.

Do I need to inspect headers for every campaign?

No. You only need to read headers when something's wrong: a spike in spam complaints, a mysterious bounce, a DMARC aggregate report showing failures. For a full deliverability framework (including when to pull headers), see our email deliverability guide.

What's the fastest way to decode a header stack?

Copy the raw headers, paste into Mailneo's email header analyzer, and read the authentication result summary first. If auth is clean, work down the hop chain for timing anomalies. Tools beat eyeballs once you've got more than five hops to trace.

Related resources

• Mailneo email header analyzer: paste raw headers, get a parsed view with auth results and hop timing
• Email deliverability guide: the cluster pillar, covers the full stack end-to-end
• SPF vs DKIM vs DMARC: side-by-side comparison of the three protocols you'll read in every Authentication-Results header
• What is DKIM?: DKIM-Signature header tags and how signing works
• Email authentication glossary: short definition with cross-links