How to read email headers (SPF, DKIM, and DMARC)

When an email fails DMARC or bounces with an SPF error, the first place to look is the Authentication-Results header. It’s where every major mailbox provider records the outcome of SPF, DKIM, and DMARC checks (pass or fail, and why).

Unfortunately, Gmail, Outlook, and Yahoo each format this information slightly differently. A field that Google shows as smtp.mailfrom= appears as header.d= in Microsoft’s version. The fields mean similar things, but reading them wrong leads to the wrong diagnosis.

This guide covers how to find authentication headers in each major inbox provider, what every field in the Authentication-Results block means, and how to use that information to troubleshoot SPF, DKIM, and DMARC failures.

Key takeaways

• SPF, DKIM, and DMARC work together to verify sender identity.
• You can find Authentication-Results the raw source of every message.
• Each inbox provider displays headers slightly differently.
• DMARC alignment is critical—passing SPF or DKIM isn’t enough without it.

What is an email header?

An email header is a block of metadata attached to every email message. It records the message’s origin, routing path, sender, recipient, and authentication status. This information isn’t visible in the standard email view — you have to open the raw source or message source to see it.

Headers consist of key-value pairs, defined by RFC 5322. A typical header block includes:

Field	What it contains
From	The visible sender address
To	The recipient address
Subject	The message subject line
Date	When the message was sent
Message-ID	A unique identifier for this message
Received	A log of each mail server the message passed through
Authentication-Results	SPF, DKIM, and DMARC check outcomes
DKIM-Signature	The cryptographic signature added by the sending domain

For authentication and security purposes, the most important field is Authentication-Results, and that’s what the rest of this article covers in detail.

Why email headers matter

Email headers give you a transparent look into how an email traveled to your inbox and whether it was authenticated along the way. If you’re working in security, IT, or deliverability—or just want to verify a sender—headers are your first stop.

Headers can help you:

• Validate sender identity
• Spot spoofed or unauthenticated messages
• Troubleshoot deliverability issues
• Understand policy alignment (for DMARC)

Email authentication in email headers

There are three core standards used to authenticate email messages. Email authentication consists of: 

• SPF: Verifies the IP address sending the email is authorized by the domain owner.
• DKIM: Confirms the content wasn’t altered and that it was signed by the sending domain.
• DMARC: Combines SPF and DKIM results to determine whether to allow, quarantine, or reject a message.

These three standards work together to help establish the identity of a sender. You can see the results of these evaluations in every email you get.

What you see in the email headers depends on your email service provider. They all show authentication results for SPF, DKIM, and DMARC checks in standard headers, but each has subtle variations in how they display the information. 

Below, we will show how you can see the authentication results for SPF, DKIM, and DMARC. For an email to pass DMARC, it must pass either SPF or DKIM with an aligned identifier. What this typically means is that the domain used for the SPF or DKIM check and the domain publishing the DMARC policy must at least be part of the same DNS namespace. 

For example, marketing.company.com and mail.company.com are both part of the company.com namespace, and are therefore aligned. Some services require that you set up both if the sending service supports it.

How to read the Authentication-Results header

Each of the three major mailbox providers includes a header labeled “Authentication-Results” in every message they deliver to a mailbox on their systems. This header contains not only the results (pass/fail) of any SPF, DKIM, and DMARC checks that were performed, but also finds other information that contributed to this check. 

Here is how some large email providers represent this information.

Google:

Authentication-Results: mx.google.com;

       dkim=pass header.i=@valimail.com header.s=google2048 header.b=Z8L6tjHb;

       spf=pass (google.com: domain of [redacted]@valimail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=[redacted]@valimail.com;

       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=valimail.com

Yahoo:

Authentication-Results: atlas321.free.mail.ne1.yahoo.com;

 dkim=pass header.i=@valimail.com header.s=google2048;

 spf=pass smtp.mailfrom=valimail.com;

 dmarc=pass(p=REJECT) header.from=valimail.com;

Microsoft:

Authentication-Results: spf=pass (sender IP is 209.85.222.48)

 smtp.mailfrom=valimail.com; dkim=pass (signature was verified)

 header.d=valimail.com;dmarc=pass action=none

 header.from=valimail.com;compauth=pass reason=100

However, they each have their own differences. 

What each field means:

SPF fields:

• spf=pass / fail / softfail / neutral — the SPF verdict
• smtp.mailfrom= — the domain used in the SMTP MAIL FROM command (the envelope from). This is what SPF actually checks, not the visible From address
• (sender IP is X.X.X.X) — the sending server’s IP address (Microsoft format)
• designates X.X.X.X as permitted sender — Google’s notation showing both domain and sending IP

DKIM fields:

• dkim=pass / fail / none — the DKIM verdict
• header.i=@domain.com — the domain that signed the message (Google/Yahoo format)
• header.d=domain.com — the signing domain (Microsoft format)
• header.s=selector — the DKIM selector used to find the public key in DNS
• header.b=XXXXXX — the first characters of the DKIM signature hash (Google only)

DMARC fields:

• dmarc=pass / fail — the DMARC verdict
• header.from=domain.com — the visible From address domain, which DMARC checks alignment against
• p=REJECT / QUARANTINE / NONE — the DMARC policy that applies (Google format)
• sp=REJECT — the subdomain policy (Google)
• dis=NONE — the disposition (what was actually done with the message; may differ from policy)
• action=none — Microsoft’s equivalent of disposition

Microsoft-specific: compauth: Microsoft adds a composite authentication field not found in Google or Yahoo:

• compauth=pass reason=100 — Microsoft’s combined verdict across SPF, DKIM, DMARC, and other internal signals
• reason=100 means all explicit checks passed
• reason=000 means the message failed all checks
• reason=001 means no authentication records were found

How SPF, DKIM, and DMARC appear differently across providers

1. SPF

All three provide the SPF verdict (spf=pass in all three examples). Google shows the SPF domain in the “domain of [redacted]@valimail.com” part and the IP that was checked against the SPF record in the “designates 209.85.220.41” phrase. 

Yahoo! only shows the SPF domain in the smtp.mailfrom= tag without showing the client IP. It would have to be located by parsing the Received headers. Microsoft uses the smtp.mailfrom= tag for the SPF domain and shows the IP in the “(sender IP is 209.85.222.48)” phrase.

2. DKIM

The results of the DKIM evaluation will show the domain that was evaluated. To ensure you are looking at the proper result, look for the one that matches the domain in the From address for the email.

All three provide the DKIM verdict (dkim=pass). Google essentially shows the signing domain in the header.i= tag, the DKIM selector in the header.s= tag, and the first few characters of the DKIM hash in the header.b= tag. 

Yahoo does the same, except for the header.b= tag, which it doesn’t include. 

Microsoft shows the signing domain in the header.d= tag, but no selector information.

3. DMARC

The DMARC results are relatively easy to read. The results will show whether or not the email passed DMARC. All three provide the DMARC verdict (dmarc=pass) and the DMARC policy domain (header.from=valimail.com). 

Google additionally provides the prevailing policy statement for the domain (p=REJECT) and any subdomain (sp=REJECT) and the disposition of the message (dis=NONE). 

Yahoo only adds the prevailing policy (p=REJECT), while Microsoft only adds the disposition in this case (action=none).

Field names by provider — quick reference:

Field	Gmail	Yahoo	Microsoft
SPF result	spf=	spf=	spf=
Envelope from domain	smtp.mailfrom=	smtp.mailfrom=	smtp.mailfrom=
Sending IP	designates X.X.X.X	(in Received headers)	(sender IP is X.X.X.X)
DKIM result	dkim=	dkim=	dkim=
DKIM signing domain	header.i=@domain	header.i=@domain	header.d=domain
DKIM selector	header.s=	header.s=	(not shown)
DMARC result	dmarc=	dmarc=	dmarc=
DMARC policy	p=REJECT	p=REJECT	(not shown)
Disposition	dis=NONE	(not shown)	action=none
Composite auth	(not used)	(not used)	compauth=

---

How to decode headers in Microsoft 365, Gmail, and Yahoo

Different inbox providers display headers differently. Here’s how to navigate each.

Gmail

• Go to the email → Click the three dots → “Show Original”
• Look under Authentication-Results
• Gmail shows detailed SPF, DKIM, and DMARC verdicts

Microsoft 365

• Open the email → Click “Message Source”
• Find Authentication-Results, compauth, and dmarc
• Microsoft includes additional info like reason=100

Yahoo

• Open the email → Click “More” → “View Raw Message”
• Find Authentication-Results from the atlas321 domain
• Yahoo may omit certain fields like header.b

Tired of manually digging through email headers?

You don’t need to be a forensic expert to understand email authentication.

Valimail Monitor gives you a real-time view of your domain’s email authentication status—without parsing raw headers line by line. It automatically analyzes SPF, DKIM, and DMARC results across all your sending services, so you can spot issues fast and take action.

See what your headers are telling you, without the guesswork.

Frequently asked questions about email headers