Email Header Analysis — Understanding Authentication Results

Published April 2026 · 15 min read

Every email you receive carries a detailed log of its journey through the internet — the email headers. These headers contain critical information about authentication results: whether SPF passed, whether DKIM signatures verified, and whether DMARC policy was satisfied. Understanding how to read these headers is essential for diagnosing deliverability problems, investigating phishing attempts, and validating your own email infrastructure.

What Are Email Headers?

Email headers are metadata fields attached to every message that record its path from sender to recipient. While the body of an email is what the recipient reads, the headers are the envelope — they contain routing information, authentication results, timestamps, and processing details.

Headers follow the format Header-Name: value and are read from bottom to top (the oldest headers are at the bottom, the newest at the top). This is a critical point that trips up many people analyzing headers for the first time.

How to View Email Headers

Each email client has a different way to access full headers:

Gmail — Open the message, click the three-dot menu, select "Show original"
Outlook — Right-click the message → View → Internet Headers
Apple Mail — View → Message → All Headers
Thunderbird — View → Source (Ctrl+U)

For automated analysis, use our Email Header Analyzer tool which parses and interprets all authentication headers instantly.

The Authentication-Results Header

The Authentication-Results header (defined in RFC 7001) is the single most important header for understanding email authentication. It's added by the receiving mail server and records the results of SPF, DKIM, and DMARC checks.

Structure of Authentication-Results

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=selector1 header.b=XyZ123;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

Each authentication method is listed on its own line within the header, with a semicolon separating them. Let's break down each section.

SPF Results

The SPF portion of Authentication-Results shows whether the sending IP address is authorized:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=example.com

Possible SPF results:

spf=pass — The sending IP is listed in the domain's SPF record
spf=fail — The sending IP is explicitly not authorized
spf=softfail — The IP is not in the SPF record but the ~all mechanism was used
spf=neutral — The domain makes no assertion about the IP (?all)
spf=none — No SPF record found for the domain
spf=temperror — DNS lookup failure (temporary)
spf=permerror — SPF record is malformed (permanent)

Tip: The smtp.mailfrom tag in the SPF result shows the envelope sender domain (the MAIL FROM address). This may differ from the header From address — that's why DMARC alignment checks both.

DKIM Results

DKIM results show whether the cryptographic signature on the message verified correctly:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=selector1

Key tags within the DKIM result:

header.i= — The signing identity (the domain that signed the message)
header.s= — The DKIM selector used for verification
header.b= — The signature hash (sometimes abbreviated)

Possible DKIM results:

dkim=pass — The signature verified successfully
dkim=fail — Signature verification failed (key mismatch, body altered, etc.)
dkim=neutral — Valid signature but the signing domain doesn't match
dkim=none — No DKIM signature present
dkim=permerror — Permanent error in the DKIM record or signature
dkim=temperror — Temporary DNS failure during verification

DMARC Results

DMARC results tell you whether the message satisfied the domain's published DMARC policy:

Authentication-Results: mx.google.com;
       dmarc=pass header.from=example.com

Possible DMARC results:

dmarc=pass — The message passes DMARC (at least one of SPF or DKIM is aligned and passes)
dmarc=fail — Neither SPF nor DKIM passes with alignment
dmarc=none — No DMARC record published for the domain
dmarc=temperror — Temporary DNS error fetching the DMARC record
dmarc=permerror — DMARC record is malformed

Common Pitfall: A message can have spf=pass and dkim=pass but still dmarc=fail. This happens when the domains don't align — for example, SPF passes for mailchimp.com but the From address is newsletter@example.com. DMARC requires domain alignment, not just authentication pass.

The Received Headers

Received headers trace the message's path through mail servers. Each server that handles the message adds a Received header at the top:

Received: by 2002:a05:6512:1102:b0:3ce:9d9f:8a5f with SMTP id
  2c6401f24de8b9ef; Mon, 25 Apr 2026 10:30:22 -0700 (PDT)
Received: from mail.example.com (mail.example.com. [203.0.113.50])
  by mx.google.com with ESMTPS id x12ab34c56ef78gh
  for <recipient@gmail.com>; Mon, 25 Apr 2026 10:30:20 -0700 (PDT)

When reading Received headers:

Read from bottom to top — The bottom Received header is where the message originated, the top is where it landed last.
Look at the "from" and "by" fields — "from" identifies the sending server, "by" identifies the receiving server.
Check for TLS — The "with ESMTPS" (note the S) indicates TLS was used. "with ESMTP" without the S means plaintext.
Note IP addresses — IPs in Received headers can be cross-referenced with SPF records to verify authorization.

The DKIM-Signature Header

The DKIM-Signature header is added by the sending server and contains the cryptographic signature details:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector1;
  h=from:to:subject:date:message-id:content-type;
  bh=2jUSOH9NhtXe5zYyN1L+lRn3WUoL2v8=;
  b=XyZ123AbC...truncated...

Key fields:

d= — The signing domain
s= — The selector (used to look up the public key in DNS at selector._domainkey.domain)
a= — The signature algorithm (rsa-sha256 is standard; ed25519-sha256 is newer)
h= — Headers included in the signature (these headers cannot be modified without invalidating the signature)
bh= — Hash of the message body

ARC Headers (Authenticated Received Chain)

ARC is a newer standard (RFC 8617) designed to solve a specific problem: when a mailing list or forwarding service modifies a message, it breaks DKIM signatures, which often causes DMARC to fail. ARC preserves the original authentication results through intermediary hops.

ARC Header Types

ARC adds three headers to a message:

ARC-Authentication-Results — The authentication results as seen by the first intermediary
ARC-Seal — A cryptographic seal over the ARC chain, verifying that previous ARC headers haven't been tampered with
ARC-Message-Signature — A DKIM-like signature over the message as it was received by the intermediary

The ARC-Seal includes an instance number (i=1, i=2, etc.) that increments with each intermediary hop. A validator can check the entire chain to verify the original authentication results.

Other Important Headers for Authentication Analysis

Received-SPF

Some mail servers add a Received-SPF header independently of Authentication-Results:

Received-SPF: pass (google.com: domain of sender@example.com
  designates 203.0.113.50 as permitted sender)
  client-ip=203.0.113.50;

This is an older format, but you'll still see it from some MTAs. Check both Authentication-Results and Received-SPF for completeness.

Feedback-ID

The Feedback-ID header is used by Gmail and other providers to correlate DMARC reports with specific email campaigns. It contains identifiers that help you trace feedback loop complaints back to the originating campaign.

List-Unsubscribe

The List-Unsubscribe header signals that a message is from a mailing list and provides a mechanism for unsubscribing. Gmail and other providers display an "Unsubscribe" button based on this header. Its presence helps distinguish legitimate bulk mail from spam.

Diagnosing Common Authentication Failures

SPF Failure in Headers

If you see spf=fail in Authentication-Results:

Check the sending IP address from the Received header
Compare against the domain's SPF record (v=spf1 TXT record)
Common causes: new sending infrastructure not added to SPF, third-party senders missing from SPF, or SPF record exceeding the 10 DNS lookup limit

DKIM Failure in Headers

If you see dkim=fail:

Check if the message was modified in transit (check Content-Transfer-Encoding)
Verify the DKIM selector exists in DNS: dig TXT selector._domainkey.domain
Look for header modifications (Subject line changes by mailing lists are common)
Check if the key is too large or uses an unsupported algorithm

DMARC Failure Despite SPF and DKIM Pass

This is one of the most confusing scenarios. The most likely cause is alignment failure:

SPF alignment — The envelope sender domain (in MAIL FROM) must match the header From domain. If your SPF record authorizes mailchimpapp.net but the From address is newsletter@yourdomain.com, SPF alignment fails.
DKIM alignment — The signing domain (d= in DKIM-Signature) must match the header From domain. If Mailchimp signs with d=mailchimpapp.net and your From is @yourdomain.com, DKIM alignment fails.

Use our Email Header Analyzer to automatically check alignment issues — paste in any email's raw headers and get an instant diagnosis.

Using Our Header Analyzer Tool

Manually parsing email headers is time-consuming and error-prone. Our Email Header Analyzer automates the entire process:

Paste the raw email headers into the tool
The analyzer parses Authentication-Results, Received, DKIM-Signature, and ARC headers
It highlights SPF, DKIM, and DMARC results with pass/fail indicators
It traces the message path, showing each hop with TLS status
It identifies alignment issues that cause DMARC failures

Analyze Email Headers →

Practical Example: Full Header Analysis

Let's walk through analyzing a real email header scenario. Suppose you're investigating why your transactional emails are landing in spam at Gmail.

Step 1: Get the Original Message

In Gmail, open the message, click the three-dot menu, and select "Show original." Look for the Authentication-Results header.

Step 2: Check Authentication

Authentication-Results: mx.google.com;
   dkim=pass header.i=@example.com header.s=selector1;
   spf=pass smtp.mailfrom=example.com;
   dmarc=pass header.from=example.com

All three pass — so authentication isn't the problem. Move on to other factors.

Step 3: Check TLS in Received Headers

Received: from mail.example.com (mail.example.com. [203.0.113.50])
  by mx.google.com with ESMTPS id ... for <user@gmail.com>

The "with ESMTPS" confirms TLS was used. If you saw "with ESMTP" (no S), that would be a TLS delivery problem worth investigating with TLS-RPT.

Step 4: Consider Other Factors

If authentication and TLS both pass, consider:

Sender reputation — Check with blacklist monitors
Content filtering — Review email content for spam-like patterns
Volume and engagement — Are recipients marking emails as spam?
List-Unsubscribe header — Is it present for subscription emails?

Forensic Header Analysis for Phishing Investigation

When investigating a phishing email, headers are your primary evidence:

Identify the True Source

Read Received headers from bottom to top. The bottommost "from" field reveals the true originating IP. Cross-reference this with:

The IP's geographic location (does it match the claimed sender?)
Whether the IP is listed in DNSBL blacklists
The reverse DNS hostname of the IP

Check for Spoofed Authentication

Phishing emails often show spf=fail or dkim=fail or dmarc=fail in Authentication-Results. If the domain has a DMARC policy of p=reject, the message should have been blocked — if it wasn't, the receiving server may not be enforcing DMARC.

Look for Header Anomalies

Missing Authentication-Results — Indicates the receiving server didn't perform authentication checks
Multiple From addresses — Some phishing emails inject a second From header
Reply-To mismatch — A Reply-To address differing from the From address is a common phishing technique
X-Headers — Custom headers like X-Mailer can reveal the sending software

Best Practices for Email Authentication Monitoring

Set up DMARC reporting — DMARC aggregate reports (RUA) give you ongoing visibility into authentication pass/fail rates across all receivers.
Deploy TLS-RPT — TLS reporting adds transport security visibility alongside authentication monitoring.
Use a header analyzer regularly — Don't wait for problems. Periodically check headers on your own emails to verify authentication is working.
Monitor forensics reports (RUF) — DMARC forensic reports include the actual headers of failed messages, making them invaluable for diagnosing authentication problems.
Align your infrastructure — Ensure SPF, DKIM, and From domains are aligned for DMARC pass. Use our free checker to verify your setup.

Analyze Your Headers Now

Paste your email headers into our Email Header Analyzer for instant authentication diagnostics. Or check your domain's overall email security posture:

Check Your Domain Now →

Related guides: DMARC Setup · SPF Records · DKIM Setup · TLS-RPT Setup