Reading email headers to diagnose a deliverability problem

Every mail client hides the full header block by default, but it is available on every message ("Show original" in Gmail, "View source" in most desktop clients) and it contains the complete, unforgeable-by-the-recipient record of how a message travelled and whether it authenticated correctly.

The three blocks that answer most questions

A full header dump is long, but almost every deliverability question is answered by three parts: the Received chain, the Authentication-Results header, and the handful of sender-identity headers (From, Return-Path, Reply-To).

The Received chain: reading it bottom-to-top

Each mail server that handles a message prepends its own Received line, so the chain reads bottom-to-top in the order the message actually travelled.

Received: by 10.60.1.1 with SMTP id a1csp123456wib;
        Mon, 15 Sep 2026 07:02:11 -0700 (PDT)
Received: from mail-relay.example.com (mail-relay.example.com [203.0.113.5])
        by mx.google.com with ESMTPS id x9si123456;
        Mon, 15 Sep 2026 07:02:10 -0700 (PDT)
Received: from app-server.internal (app-server.internal [10.0.4.21])
        by mail-relay.example.com with ESMTP id 4abc123;
        Mon, 15 Sep 2026 14:02:09 +0000 (UTC)

Read from the bottom: the message originated at app-server.internal, passed to mail-relay.example.com, which then connected to Google's receiving server (mx.google.com) from IP 203.0.113.5. Each hop's timestamp lets you spot where a delay actually occurred - a large gap between two consecutive Received timestamps tells you which hop queued or retried the message, not just that it was "slow" somewhere.

Authentication-Results: the pass/fail summary

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=sept2026 header.b=K8nQ...;
       spf=pass (google.com: domain of bounce@example.com designates
         203.0.113.5 as permitted sender) smtp.mailfrom=bounce@example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

This single header is where you confirm whether authentication actually passed, and critically, *which domain* each check passed against. dkim=pass header.i=@example.com confirms the DKIM signature validated and was for the domain you expect - a pass against the wrong domain is not useful for DMARC alignment even though it is technically a DKIM pass. spf=pass ... smtp.mailfrom=bounce@example.com tells you the envelope-from domain that was checked, which is often a dedicated bounce-handling subdomain, not necessarily the domain in the visible From header. dmarc=pass with the policy shown (p=REJECT) confirms alignment succeeded under the domain's actual published policy.

Note this header is added by the *receiving* server, so you only see it on messages you received, not ones you sent - to see how your own outbound mail is authenticating, send a test to an account you control at the provider you want to check, then inspect that message's headers.

Sender-identity headers

• From: the visible display identity recipients see.
• Return-Path (often set from the envelope MAIL FROM): where bounces are routed; frequently a dedicated subdomain like bounce.example.com rather than the visible From domain.
• Reply-To: where replies go if different from From - common in automated or no-reply sending setups.

A mismatch between From and Return-Path domains is normal for bulk senders using a dedicated bounce-handling subdomain, and is not itself a problem as long as SPF and DKIM alignment are set up correctly for the actual domain DMARC checks.

When you are troubleshooting a specific complaint - "I never received this" or "this looked wrong" - start with the Received chain to confirm the message actually reached the expected infrastructure, then move to Authentication-Results to rule authentication in or out, and only then look at the identity headers to check whether the visible sender matches what was actually configured. Working in that order avoids the common mistake of assuming a visually odd From or Reply-To address is the cause of a delivery problem when the actual cause is further up the chain.

A quick diagnostic table

What not to do

Do not rely on a mail client's simplified "sender info" panel - it often hides or summarises exactly the fields you need. Do not assume a DKIM or SPF "pass" shown by a third-party header-analyzer tool is checking alignment the same way DMARC does - read the raw Authentication-Results header yourself to confirm which domain actually passed. And do not ignore the Received chain when diagnosing delay - the bounce or delay notification text alone often omits where in the chain the actual hold-up occurred.

Where MailPilot fits

MailPilot checks SPF, DKIM and DMARC on the sending domain and tracks per-mailbox reputation daily, which means the exact signals in the Authentication-Results header - pass/fail status, alignment, and placement outcome - are already being monitored continuously rather than requiring a manual header pull every time something looks off.