Email headers are the complete record of everything that happened to an email message from the moment it was composed to the moment it was delivered. Authentication results, delivery path, spam filter scores, and ISP-specific reputation signals are all encoded in the headers of every email. For deliverability investigation, email headers are the primary diagnostic tool — more informative than aggregate statistics, more immediate than monitoring dashboards, and completely accurate for the specific message they describe. Learning to read email headers fluently is the single skill that most accelerates deliverability problem diagnosis. This guide covers the specific headers and their values that determine email deliverability outcomes.
Why Email Headers Are the Primary Deliverability Diagnostic
Every email message carries a complete header section that records its origin, transmission path, and authentication results. Headers are added by each server that handles the message — the originating MTA adds the initial From, Date, Message-ID, and DKIM-Signature headers; each receiving SMTP server adds a Received header and Authentication-Results header as the message passes through. The final recipient's inbox shows only the rendered email body — but the full headers are accessible through "View source" or "Show original" in every major email client.
Headers provide information that no monitoring dashboard can: the exact SPF, DKIM, and DMARC results for a specific message as evaluated by the specific receiving server. If a recipient reports that a message went to spam, examining the headers of that specific message reveals exactly what the spam filter evaluated — authentication results, spam score, and the specific rules that triggered filtering. This per-message diagnostic precision is what makes headers the indispensable tool for deliverability investigation.
Accessing full headers: in Gmail, open the message → click the three-dot menu → "Show original." In Apple Mail: View → Message → All Headers. In Outlook: File → Properties → Internet headers. Most email clients have equivalent "view source" or "view headers" functionality. Many email analysis tools (MXToolbox Email Header Analyzer, Mail Header Analyzer at mxtoolbox.com) accept pasted header text and provide structured analysis of the authentication results and delivery path.
Reading Authentication-Results Headers
The Authentication-Results header is added by receiving mail servers to summarise the results of SPF, DKIM, and DMARC authentication checks performed at that hop. An email that passes through multiple servers (origin MTA → intermediate server → final destination) will have multiple Authentication-Results headers — one from each server that performed authentication checks. The most important is the one added by the final recipient's mail server (the last Authentication-Results header at the top of the headers section — remember headers are added in reverse chronological order, with the most recent at the top).
# Example Authentication-Results from Gmail (fully passing):
Authentication-Results: mx.google.com;
dkim=pass header.i=@brand.com header.s=mail2027 header.b=AbCdEfGh;
spf=pass (google.com: domain of bounce@mail.brand.com designates
203.0.113.10 as permitted sender) smtp.mailfrom=bounce@mail.brand.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=brand.com
# Breakdown:
# dkim=pass: DKIM signature verified; header.i=@brand.com is the signing domain
# spf=pass: sending IP is in SPF record for the MAIL FROM domain
# dmarc=pass: at least one of SPF/DKIM aligned with From: domain; policy p=REJECT
# header.from=brand.com: the From: header domain that DMARC evaluated against
# Example Authentication-Results with failures:
Authentication-Results: mx.google.com;
dkim=fail (signature verification failed) header.i=@esp-shared.com
header.b=XyZabcDe;
spf=softfail (google.com: domain of bounce@esp-shared.com does not
designate 203.0.113.99 as permitted sender);
dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=brand.com
# Breakdown:
# dkim=fail: DKIM signature failed verification
# header.i=@esp-shared.com: signing domain is ESP's domain, NOT brand.com
# spf=softfail: sending IP is not in SPF record (softfail from ~all qualifier)
# dmarc=fail: neither DKIM nor SPF aligned with brand.com (From: domain)
# dis=QUARANTINE: DMARC policy applied = message sent to spam
Reading the Authentication-Results header reveals immediately whether the deliverability problem is an authentication failure (dkim=fail, spf=fail, dmarc=fail) or a reputation/content problem (all three pass, but the message still went to spam). If authentication results show all pass, the investigation moves to reputation (Postmaster Tools spam rate check) and content quality. If authentication results show any failure, the investigation focuses on identifying and fixing the specific authentication misconfiguration before reputation can recover.
DKIM-Signature Header Analysis
The DKIM-Signature header contains the cryptographic signature added by the sender's MTA at the time of sending. Every message sent with DKIM signing has at least one DKIM-Signature header. Analysing the DKIM-Signature header reveals: which domain is signing (d=), which selector is being used (s=), which headers are covered by the signature (h=), and the signing algorithm (a=).
# Complete DKIM-Signature header example: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brand.com; # Signing domain — must align with From: domain for DMARC s=mail2027; # Selector — DNS record at mail2027._domainkey.brand.com t=1741910400; # Timestamp of signing (Unix timestamp) bh=7/2...; # Body hash — verifies message body hasn't changed h=From:To:Subject:Date:Message-ID:Content-Type; # Signed headers b=AbCdEfGh...; # The actual cryptographic signature # Critical fields for DMARC alignment: # d=brand.com — this must match the From: header domain or its parent # If d=esp-shared.com and From: header is brand.com — DMARC alignment FAILS
The DKIM-Signature body hash (bh=) is particularly useful for diagnosing failed DKIM signatures on forwarded email. When a mailing list adds a footer to the email body, the body hash in the original DKIM-Signature becomes invalid — the body content has changed. This is exactly the problem that ARC was designed to solve (by sealing the pre-modification signature in an ARC header). When DKIM fails specifically because of body modification (as opposed to header modification or key mismatch), the bh= hash mismatch is the diagnostic indicator.
Reading Received Headers for Delivery Path
Received headers record each SMTP server handoff in the message's delivery path. Each Received header is added by the receiving server and includes: the sending hostname/IP (from), the receiving hostname (by), the protocol used, and the timestamp. Reading Received headers bottom-to-top (oldest at bottom, newest at top) traces the complete delivery path from the original sender to the final recipient.
# Received header chain reading order (bottom to top):
# 3. Final recipient's server (at Google, this is the Gmail inbox):
Received: by 2002:a05:6402:3948:b0:4f8:2b1e with SMTP id
q8csp234567qua; Fri, 25 Mar 2027 08:23:45 -0800
# 2. Gmail's MX server received from the sending MTA:
Received: from mail1.brand.com ([203.0.113.10])
by mx.google.com with ESMTPS id
v12si123456pgv.456.2027.03.25.08.23.44
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 25 Mar 2027 08:23:44 -0800
# 1. The sending MTA (PowerMTA on mail1.brand.com):
Received: from submission-app.brand.com (submission-app.brand.com [10.0.0.100])
by mail1.brand.com (PowerMTA 5.0) with ESMTP id abc123
for <recipient@gmail.com>;
Fri, 25 Mar 2027 08:23:43 -0800
# Reading the chain reveals:
# - Sending IP: 203.0.113.10 (gmail's mx received from this IP)
# - Sending hostname: mail1.brand.com (must match PTR record for 203.0.113.10)
# - Protocol: ESMTPS with TLS1_3 (TLS correctly used)
# - Delivery time: 1 second from injection to Gmail receipt (healthy timing)
The Received headers also reveal: whether TLS was used (ESMTPS vs ESMTP), the exact delivery time at each hop (timestamps reveal if there was queuing delay at any server), the actual sending IP address (cross-check against the SPF authorised IP list), and the sending hostname (cross-check against the PTR record for the sending IP to verify FCrDNS).
ARC Headers in Forwarded Email
Messages that have passed through ARC-signing intermediaries (mailing lists, email gateways, forwarding services) will contain ARC-Seal, ARC-Authentication-Results, and ARC-Message-Signature headers. Each ARC header set has an instance number (i=1 for the first intermediary, i=2 for the second, etc.). The presence of ARC headers in a delivered message confirms that the delivery path included at least one ARC-capable intermediary.
# ARC headers in a forwarded message (from a mailing list): ARC-Seal: i=1; a=rsa-sha256; t=1741910400; cv=none; d=lists.example.org; s=arckey; b=SEAL_SIGNATURE; ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.example.org; s=arckey; t=1741910400; h=from:to:subject:date; bh=ORIGINAL_BODY_HASH; b=AMS_SIGNATURE; ARC-Authentication-Results: i=1; lists.example.org; dkim=pass header.i=@original-sender.com; spf=pass; dmarc=pass # The ARC chain shows: # - The original message (before list modification) had dkim=pass, spf=pass, dmarc=pass # - The list server (lists.example.org) sealed these results with ARC # - Final recipient's server can verify the ARC chain and treat message as authenticated # - Authentication-Results at final destination may show: arc=pass
Common Authentication Failures in Header Data
The most frequently encountered authentication failure patterns in email headers, with their diagnostic indicators and root causes:
DKIM fail — key not found in DNS: dkim=fail (no key for signature). Root cause: the DNS record at selector._domainkey.domain.com either does not exist or was recently deleted/changed. Resolution: verify the DKIM DNS record is published and matches the signing configuration in the MTA.
DKIM fail — body hash mismatch: dkim=fail (message has been altered). Root cause: the email content was modified after signing — either by a mailing list that added a footer, a gateway that modified headers, or a content scanner that altered the message. Resolution: investigate the delivery path for intermediaries that modify content; implement ARC sealing at the intermediary; or configure DKIM to use relaxed canonicalization (c=relaxed/relaxed) which tolerates minor whitespace modifications.
SPF fail — IP not authorized: spf=fail (IP not authorized). Root cause: the sending IP is not listed in the SPF record for the MAIL FROM domain. Resolution: add the sending IP to the SPF record or update the SPF include mechanism to cover the sending platform's IP range.
SPF permerror — lookup limit exceeded: spf=permerror (too many DNS lookups). Root cause: the SPF record requires more than 10 DNS lookups to evaluate (SPF flattening required). Resolution: implement SPF flattening as documented in the SPF flattening guide.
DMARC fail — no alignment: dmarc=fail (alignment not satisfied). Root cause: neither SPF nor DKIM aligned with the From: header domain. The most common cause is the ESP signing with d=esp-shared.com while the From: header is brand.com — no alignment. Resolution: configure custom DKIM signing with d=brand.com on the ESP.
ISP-Specific X-Headers
ISPs add proprietary X-headers that reveal their internal processing of the message. These headers are not standardised but provide valuable diagnostic information for deliverability investigation:
Gmail X-headers:
X-Forwarded-To: recipient@gmail.com # Final delivery address X-Original-To: recipient@gmail.com # Original intended recipient
Microsoft/Outlook X-headers:
X-Microsoft-Antispam: BCL:0 # Bulk Complaint Level (0=not bulk, 9=high bulk) X-Forefront-Antispam-Report: ... # Detailed EOP spam filter evaluation CIP:203.0.113.10; # Connecting IP CTRY:US; # Country of sending IP LANG:en; # Detected message language SCL:1; # Spam Confidence Level (-1 to 9, lower is better) SRV:;BULK:;PTR:mail1.brand.com; # PTR record of sending IP SFTY:;SFV:NSPM; # NSPM = Not SPaM (not spam folder) H:mail1.brand.com; # EHLO hostname PS:10; # Phishing score
SpamAssassin X-headers (many corporate gateways):
X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, RCVD_IN_DNSWL_MED,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 # score=-1.2: message scored -1.2 (below 5.0 threshold = not spam) # tests=: specific rules that triggered and their individual scores # DKIM_SIGNED,DKIM_VALID: DKIM present and valid # SPF_PASS: SPF passed # URIBL_BLOCKED: a link domain is on a URI blocklist (investigate if present)
The Header Diagnostic Workflow
When a recipient reports that an email went to spam or was rejected, the header diagnostic workflow provides systematic root cause identification:
▶ Email Header Diagnostic Workflow
Email header reading is the diagnostic skill that converts deliverability problems from mysterious black-box failures into specific, identifiable root causes with documented remediation paths. Every authentication failure, every content scoring issue, every ISP-specific filtering pattern leaves its signature in the message headers. Learn to read those signatures — and deliverability investigation becomes a diagnostic exercise rather than a guessing game.