Email Headers for Deliverability Diagnosis: Received Chain, Authentication-Results, and 5 Failure Scenarios

Every email carries a complete audit trail of its own delivery journey. The headers — the technical metadata above the message body that most email clients hide by default — contain authentication results, routing hops with timestamps, spam scoring, and the identity of every server that touched the message. When an email lands in spam, arrives delayed, or fails authentication, the header is almost always the fastest path to understanding exactly what happened and why.

This guide explains how to read each significant header field, extract actionable diagnostic information from the Received chain and Authentication-Results block, and use headers to diagnose the eight most common deliverability failure patterns.

How to Access Full Headers

Email clients hide full headers by default because they're verbose and technical. Here's how to access them in major clients:

• Gmail: Open message → three-dot menu (⋮) next to Reply → "Show original" → new tab shows full raw headers and message source
• Outlook desktop: Double-click to open message → File → Properties → "Internet headers" section shows headers
• Outlook Web (OWA): Open message → three-dot menu → "View message details"
• Apple Mail: View → Message → All Headers; or View → Message → Raw Source for full source
• Yahoo Mail: Open message → More (three-dot) → "View raw message"
• Thunderbird: Open message → View menu → Message Source (Ctrl+U)

For deliverability diagnosis, always use "Show original" or equivalent — not just the headers view — to see the full raw output including SMTP transaction IDs that can help you correlate with mail server logs.

The Received Chain: Reading Routing Bottom-to-Top

The most important structural feature of email headers: read the Received chain from bottom to top. Each server that handles the message prepends a new Received header, so the oldest (first hop) is at the bottom and the most recent (recipient's server) is at the top.

Return-Path: <bounce+1234@em.yourcompany.com>
  # The envelope sender / bounce address — must match SPF

Received: from mail8.em.yourcompany.com (mail8.em.yourcompany.com [167.89.x.x])
  by mx.google.com with ESMTPS id abc123xyz
  for <user@gmail.com>; Mon, 7 Apr 2025 09:14:22 +0000
  # Sending IP: 167.89.x.x — should be on your SPF record

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourcompany.com; s=smtp2025; h=from:to:subject:date;
  bh=ABC123xyz==; b=MFQCIB...
  # d= must match From: domain for DMARC alignment

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourcompany.com header.s=smtp2025;
  spf=pass (domain of bounce@em.yourcompany.com designates 167.89.x.x);
  dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=yourcompany.com;
  # All three pass + DMARC alignment confirmed

X-Spam-Status: No, score=-3.2 required=5.0
  # Negative score = well under spam threshold

Received: from mx.google.com (mx.google.com [74.125.24.27])
        by mx.yourdomain.com with ESMTPS id abc123
        for <user@yourdomain.com>;
        Fri, 12 Apr 2026 10:05:22 +0000

Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [209.85.210.46])
        by smtp.googleapis.com with ESMTPS id y5si1234567pfn.18.2026.04.12.03.05.21
        for <user@yourdomain.com>;
        Fri, 12 Apr 2026 03:05:21 +0000

Received: from yourserver.com (yourserver.com [203.0.113.10])
        by mail.sender.com with ESMTPS id z7si987654abc.15.2026.04.12.03.05.18
        for <user@yourdomain.com>;
        Fri, 12 Apr 2026 03:05:18 +0000

Reading Received headers for diagnostic information

Each Received header contains:

• from: The hostname and IP of the server sending the message (in parentheses)
• by: The receiving server's hostname
• with: The protocol used (SMTP, ESMTP, ESMTPS = SMTP with TLS, ESMTPSA = with authentication)
• id: The message ID on that server — useful for cross-referencing server logs
• for: The recipient address
• timestamp: When this hop occurred

Diagnosing delays from Received timestamps

Compare timestamps between consecutive Received headers to identify where delays occurred. Reading bottom-to-top, the time difference between each hop shows where the message spent time:

# Example: Message took 15 minutes between hops 2 and 3 (counting from bottom)
Hop 3 (top): ...03:20:15 +0000
Hop 2 (mid): ...03:05:21 +0000  ← 15-minute gap here
Hop 1 (bot): ...03:05:18 +0000  ← normal 3-second gap

A 15-minute gap at a specific hop usually means that server's queue was backing up, had a connection issue with the next hop, or experienced a temporary failure and retried. If the slow hop is the recipient's MX server, the cause is usually recipient-side queue pressure or greylisting.

Authentication-Results: The Deliverability Diagnostic Block

The Authentication-Results header is added by the receiving server and contains the outcome of every authentication check performed on the message. This is the single most important header for deliverability diagnosis.

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

Reading each authentication field

dkim= values:

• pass — DKIM signature verified successfully
• fail — Signature present but failed verification (key mismatch, message modification, or wrong selector)
• none — No DKIM signature was found on the message. This is an authentication gap.
• permerror — DNS error resolving the DKIM record; or DKIM signature syntax error
• temperror — Transient DNS lookup failure; will likely succeed on retry

Additional DKIM fields when pass: header.i = signing domain, header.s = selector used, header.b = first 8 characters of the signature (for correlation)

spf= values:

• pass — The sending IP is authorised for the envelope sender domain
• fail — The IP is explicitly not authorised (-all in SPF record)
• softfail — The IP is not authorised but the domain uses ~all (soft enforcement)
• neutral — The domain makes no assertion about this IP (?all)
• none — No SPF record found for the envelope sender domain
• permerror — SPF record has a permanent error (syntax error, too many lookups)
• temperror — Transient DNS error during SPF evaluation

Additional SPF fields: smtp.mailfrom = the envelope sender domain that was checked (not the From: header domain)

dmarc= values:

• pass — DMARC evaluation succeeded: at least one of SPF or DKIM passed and aligned
• fail — Neither SPF nor DKIM passed with alignment to the From: domain
• bestguesspass — No DMARC record exists, but sender appears legitimate by heuristic
• none — The domain has no DMARC record published

Additional DMARC fields: p= = the policy the sending domain has published, dis= = the disposition actually applied (what the receiver did)

Key Diagnostic Scenarios

Scenario 1: Authentication looks fine but email is in spam

Authentication-Results: mx.google.com;
   dkim=pass ...
   spf=pass ...
   dmarc=pass ...

If all three authentication checks pass but the message went to spam, authentication is not the problem. Look for:

• X-Spam-Score or X-Spam-Status headers showing high content score
• X-Google-DKIM-Signature absence (Gmail internal headers)
• Low domain or IP reputation — not visible in headers, diagnosed via Postmaster Tools and SNDS
• Recipient's previous engagement with your domain — no headers available, but Postmaster Tools spam rate chart is the proxy

Scenario 2: DKIM fail with valid DNS record

Authentication-Results: mx.google.com;
   dkim=fail header.i=@yourdomain.com header.s=mail ...

DKIM passes only when the signature is valid against the current DNS public key AND the message body hasn't changed since signing. Common causes of dkim=fail when you know the DNS record is correct:

• Message modified in transit: A mail server between the sender and recipient altered the message (rewriting headers, adding footers, modifying content). DKIM signs a hash of the message; any modification breaks the signature.
• Canonicalization mismatch: The DKIM signature uses simple/simple canonicalization but an intermediate server normalized the message in a way that changed the body hash. Use relaxed/relaxed canonicalization to tolerate minor normalizations.
• DNS caching a stale key: If you recently rotated DKIM keys but the receiving server's DNS cache is still serving the old public key, verification of messages signed with the new key will fail. This clears automatically as TTL expires.
• Key mismatch (wrong selector): The s= value in the DKIM-Signature header points to a selector whose DNS record doesn't match the private key used to sign. Verify by querying: dig TXT mail._domainkey.yourdomain.com and confirming the public key matches your private key.

Scenario 3: SPF pass but DMARC fail

Authentication-Results: mx.google.com;
   spf=pass smtp.mailfrom=bounce.sendingplatform.com;
   dkim=none;
   dmarc=fail (p=QUARANTINE) header.from=yourdomain.com

SPF passed but DMARC failed. This is an alignment failure. The smtp.mailfrom shows bounce.sendingplatform.com — the SPF check passed for the sending platform's domain, but DMARC requires alignment with header.from=yourdomain.com. The platforms' domain and your From: domain don't match organisationally.

Solution: Configure a custom bounce domain (Return-Path domain) on the sending platform to use a subdomain of your own domain, e.g., bounce.yourdomain.com. This makes the SPF-authenticated domain align with your From: header domain.

Scenario 4: Forwarded email failing authentication

Received: from forwarder.domain.com ...
Authentication-Results: mx.google.com;
   spf=fail ...
   dkim=fail ...

Email forwarding inherently breaks SPF (because the forwarding server's IP isn't authorised in the original sender's SPF record). DKIM may also break if the forwarder modifies the message. This is normal and expected — it's not a configuration problem with your sending. The solution for organisations receiving forwarded mail is ARC (Authenticated Received Chain), which some forwarders implement to preserve the original authentication results.

Scenario 5: 550 5.7.26 rejection (Gmail bulk sender requirement)

Action: failed
Status: 5.7.26
Diagnostic-Code: smtp; 550-5.7.26 This message does not have authentication
  information or fails to pass authentication checks. To best protect our
  users from spam, the message has been blocked.

This specific Gmail error means the message failed Gmail's 2024 bulk sender requirement: SPF, DKIM, and DMARC must all be configured for senders sending 5,000+/day to Gmail. Check:

1. SPF record exists and passes for your sending IP
2. DKIM is configured and signing outbound mail (verify via test email)
3. DMARC record is published (p=none minimum)
4. All three are aligned with your From: header domain

Header Analysis Tools

For most deliverability diagnosis, paste headers into MXToolbox first. If the issue is specifically DMARC-related, MailTested provides more granular alignment detail. If you're debugging timing/routing, Google Admin Toolbox's delivery timeline visualisation is clearest.