Email Headers Explained

How to view raw headers

For deeper analysis, save the raw message as .eml (most clients offer "Download" or "Export as") and open with a text editor or a dedicated tool like Mailtester's header analyzer or Google Admin Toolbox Messageheader.

The header structure

Headers appear at the top of every email, one per line. Multi-line headers use indentation on continuation lines. The header section ends at the first blank line — everything after that blank line is the message body. A typical header block looks like this:

Return-Path: <bounces@example.com>
Received: from mail.example.com (mail.example.com [203.0.113.10])
    by mx.google.com with ESMTPS id abc123
    for <alice@gmail.com>
    (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384);
    Sat, 25 May 2026 09:14:23 -0700 (PDT)
Received: by mail.example.com (Postfix, from userid 1000)
    id 9876ABCDEF; Sat, 25 May 2026 09:14:21 -0700 (PDT)
Authentication-Results: mx.google.com;
    spf=pass smtp.mailfrom=bounces@example.com;
    dkim=pass header.i=@example.com header.s=mail2026;
    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=mail2026; t=1716643463; h=from:to:subject:date:message-id;
    bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=K3KqDfM...
Message-ID: <20260525091421.9876ABCDEF@mail.example.com>
Date: Sat, 25 May 2026 09:14:21 -0700
From: Newsletter <news@example.com>
Reply-To: support@example.com
To: alice@gmail.com
Subject: Your weekly update
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="boundary_abc"

[body starts here]

The Received chain

Every server that handles the message prepends a Received: header recording the handoff. The bottom Received header is the original send; the top is the final delivery. To trace a message from origin to destination, read bottom-up.

A single Received header contains:

• from — the connecting server's claimed identity (from the SMTP EHLO/HELO) and the actual reverse-DNS hostname in parentheses.
• by — the receiving server's identity.
• with — the protocol used (ESMTPS = ESMTP with TLS; ESMTP = plain ESMTP).
• id — a unique transaction identifier on the receiving server.
• for — the envelope recipient. May be omitted if multiple recipients.
• cipher / TLS info — the encryption parameters of the connection.
• timestamp — when this hop completed.

Delays between Received timestamps indicate where a message was stuck. A normal hop takes seconds; an hour-long gap means the previous server held the message in a queue. Walking down the timestamps quickly identifies which hop was the bottleneck.

The Authentication-Results header

Added by the receiving server, this records the outcome of every authentication check. Format: a semicolon-separated list of method=result pairs, often with additional context in parentheses.

Authentication-Results: mx.google.com;
    spf=pass smtp.mailfrom=bounces@example.com;
    dkim=pass header.i=@example.com header.s=mail2026;
    dmarc=pass (p=reject sp=reject dis=none) header.from=example.com

Reading this:

• spf=pass — SPF verified successfully. The smtp.mailfrom shows which domain SPF checked.
• dkim=pass — DKIM signature verified. header.i shows the signing identity; header.s shows the selector.
• dmarc=pass — DMARC alignment succeeded. The policy in effect (p=reject), subdomain policy (sp=reject), and disposition action taken (dis=none, meaning no override applied) are shown. header.from is the visible From: domain DMARC aligned against.

Failure modes look like:

spf=fail (sender IP is 198.51.100.5 not authorized) smtp.mailfrom=bounces@example.com
dkim=fail (signature did not verify) header.d=example.com header.s=mail2026
dmarc=fail (p=quarantine dis=quarantine) header.from=example.com

The reasons in parentheses point at specific fixes. not authorized means update SPF; signature did not verify means investigate message modification or key rotation; DMARC dis=quarantine means the policy was applied (message went to spam folder).

The address headers: From, Reply-To, Return-Path, To, Cc, Bcc

From:

The visible sender. What recipients see in their mail client. Format: Display Name <email@domain.com>. DMARC aligns against the domain in this header.

Return-Path:

Where bounces go. Set by the sending server based on the SMTP MAIL FROM command. Often called the "envelope sender." SPF authenticates this address, not From:. A common pattern: From: news@example.com but Return-Path: bounces+abc123@bounce.platform.com — the platform handles bounce processing without exposing your address to that load.

Reply-To:

Optional override for replies. If present, mail clients use Reply-To when the user hits "Reply." Used by mailing lists (replies go to the list, not the original poster) and by platforms that need replies to route somewhere different from From:. Recipients sometimes find Reply-To mismatches suspicious, since attackers also use it to redirect responses to themselves.

To, Cc, Bcc:

To and Cc appear in the header and are visible to all recipients. Bcc does NOT appear in the delivered message headers — it is honored only in the SMTP envelope. The presence of a Bcc address in headers (which can leak through misconfigured mail systems) is a privacy bug.

Sender:

Optional. Indicates that someone other than the From: address actually authored the message. Used by mailing lists and assistants ("on behalf of"). Mail clients display "From: X on behalf of Y" or similar when Sender differs from From:.

Tracking and content-type headers

Message-ID:

A globally-unique identifier for the message, set by the originating server. Format: <random@domain>. Used for threading (In-Reply-To and References headers point at Message-IDs), deduplication, and debugging (you can ask the receiving server to search logs for this specific ID).

Date:

When the message was created. Set by the sending mail client or server. Should be in RFC 5322 format (Sat, 25 May 2026 09:14:21 -0700). Wildly inaccurate Date headers (years off, or from the future) reduce sender reputation.

MIME-Version, Content-Type:

Declare how the body is structured. multipart/alternative means the message contains both plain text and HTML versions; the client picks one. multipart/mixed means the message has attachments. The boundary string in Content-Type separates the parts within the body.

List-Unsubscribe and List-Unsubscribe-Post:

Headers that enable one-click unsubscribe (RFC 8058). Mandatory under the Gmail/Yahoo 2024 requirements for any marketing mail. List-Unsubscribe contains the URL or mailto address that mail clients use to render the unsubscribe button. List-Unsubscribe-Post: List-Unsubscribe=One-Click signals support for one-click POST-based unsubscribe.

X-Originating-IP, X-Sender-IP, X-Mailer:

Custom (X-) headers added by various servers and mail clients. Informational; not standardized. X-Mailer shows the program that composed the message (e.g., Microsoft Outlook 16.0, Apple Mail (2.3654)) and is sometimes used in reputation scoring (custom mail-sending scripts with obviously-spam X-Mailers get penalized).

Debugging with headers: common scenarios

Scenario: Message landed in spam.

Read Authentication-Results first. If SPF/DKIM/DMARC are all pass, the spam decision is reputation- or content-based — see Why Emails Go to Spam. If any one failed, fix that first.

Scenario: Message delayed by hours.

Walk the Received chain bottom-up. Find the hop where the timestamp gap is large. That server held the message. Common causes: queue backup, grey-listing, defer-on-temp-fail.

Scenario: Sender does not appear to be who they claim.

Compare From:, Return-Path:, Reply-To:, and the signing domain in DKIM-Signature. Legitimate transactional mail often has three different domains visible in these. If From: is your bank but Reply-To: is a Gmail address and the DKIM signing domain is unknown, the message is almost certainly spoofed or compromised.

Scenario: Bounce message.

Bounces from RFC 3464-compliant servers contain a multipart/report body with a message/delivery-status part. Look inside that part for Status: (the DSN code, like 5.7.1) and Diagnostic-Code: (the exact remote server message). The code tells you what category of failure; the diagnostic gives the specific reason.

Frequently Asked Questions

In what order do I read Received headers?

Top to bottom in the raw message is reverse chronological order — newest first, oldest last. The bottom-most Received header is the original sending server; the top-most is the final receiving server. To trace a message from origin to destination, start at the bottom of the Received chain and work upward. Each hop logs when and where the message was handed off.

What is the difference between Return-Path and From:?

Return-Path (also called the envelope sender or MAIL FROM) is where bounce notifications are sent — set by the sending server and used in the SMTP transaction. The From: header is what the recipient sees in their mail client. The two can legitimately differ: marketing platforms use platform-controlled Return-Path addresses for bounce handling while showing your brand domain in From:. SPF authenticates the Return-Path, not From:.

How do I view raw email headers in Gmail?

Open the message, click the three-dot menu at the top right, select "Show original" (or use keyboard shortcut U). A new tab opens with the full raw message — headers at top, body below — plus a summary box showing SPF, DKIM, and DMARC results. The "Download Original" button saves the .eml file for offline analysis. Most other clients have similar functionality: Outlook (File → Properties → Internet Headers), Apple Mail (View → Message → All Headers).

What does the Authentication-Results header tell me?

Authentication-Results is added by the receiving server and records the outcome of SPF, DKIM, and DMARC checks. It is the single most useful header for debugging deliverability. Each result is a key=value pair: spf=pass/fail (with the checked domain), dkim=pass/fail (with the signing domain), dmarc=pass/fail (with the policy applied). The header also records the From: domain checked, the source IP, and any failure reasons in parentheses.

Why does my message have a different Reply-To than From:?

Reply-To overrides where replies should go without changing the visible sender. Common uses: a marketing platform sends as your brand domain (From: brand@example.com) but routes replies to a CRM inbox (Reply-To: support-12345@platform.com). Some recipients may flag this as suspicious because attackers also use Reply-To to redirect replies to a different domain. For trust, keep Reply-To on your own domain when possible.