Email Header Analysis: Reading Authentication Results

Why Headers Matter

When an email fails to deliver, lands in spam, or triggers a DMARC failure report, the headers are the forensic evidence. Every mail server that handles a message stamps it with headers — structured per RFC 5322 (Internet Message Format) — recording what it checked, what passed, and what failed. The mxio Header Analyzer parses these headers and presents the authentication results in a structured, readable format.

This guide explains where to find headers, how to read the critical fields, and what common failure patterns look like.

Finding Email Headers

Each mail client stores headers differently. You need the full, raw message source — not just the visible fields.

Copy the full header block and paste it into the mxio Header Analyzer for instant parsing.

The Authentication-Results Header

The most important header for diagnosing email authentication is Authentication-Results, defined in RFC 8601. It is added by the receiving mail server and summarizes the SPF, DKIM, and DMARC evaluation results for that message.

A typical Authentication-Results header:

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

Reading Each Result

SPF result — spf=pass or spf=fail followed by smtp.mailfrom= showing the envelope sender (the RFC 5321 MAIL FROM identity). A pass means the sending IP was authorized by the domain's SPF record per RFC 7208. A fail means it was not. A softfail (spf=softfail) means the domain flags unauthorized senders but does not request hard rejection.

DKIM result — dkim=pass with header.d= showing the signing domain and header.s= showing the selector. A pass means the cryptographic signature verified successfully per RFC 6376. A fail means the message was modified in transit or the signature was invalid. See DKIM Body Hash Not Verified for common causes.

DMARC result — dmarc=pass with the policy in parentheses and header.from= showing the From domain. DMARC passes when at least one of SPF or DKIM passes with alignment to the From domain per RFC 7489. See Why Is DMARC Failing? when this shows dmarc=fail.

Tracing the Delivery Path

The Received: headers form a chain that traces the message from origin to destination per RFC 5322 Section 3.6.7. Each server that handles the message prepends a Received: header, so they read bottom-to-top — the bottom-most Received: header is the originating server, and the top-most is the final receiving server.

Key information in each Received: header:

• from — The server that handed off the message
• by — The server that received it
• timestamp — When the handoff occurred

Comparing timestamps across the chain reveals delivery delays. A gap of minutes or hours between two hops can indicate greylisting, network issues, or queue backlogs.

Common Red Flags

Missing Authentication-Results — The receiving server did not perform authentication checks. This is rare with major providers but occurs with some legacy or misconfigured servers.

spf=none — The sending domain has no SPF record published. This is not a failure but means SPF provides no information about the sender.

dkim=fail with body hash did not verify — The message body was modified after signing, typically by a mailing list, forwarding service, or security gateway that rewrites content.

dmarc=fail despite spf=pass — SPF passed but the domain in the Return-Path does not align with the From: header domain. DMARC requires alignment, not just a pass. This is a common issue with third-party services that use their own envelope sender. See the complete email authentication guide for how alignment works.

Multiple dkim= entries — The message was signed by more than one domain. This is normal when a message passes through a sending service (e.g., signed by both example.com and sendgrid.net). What matters is whether at least one signature aligns with the From domain.

Analyze your email headers now