Definition
The Authentication-Results header is a message header, defined in RFC 8601, in which a receiving server records the outcomes of the authentication checks it performed, including SPF, DKIM, and DMARC. It provides a single, standardised place to see how a message fared at each participating server, making it the primary reference for authentication troubleshooting.
How It Works
When a server receives and authenticates a message, it appends a header that lists each protocol and its result. A typical header contains multiple clauses:
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.i=@example.com;
dmarc=pass header.from=example.com
Each clause reports the result, such as pass, fail, neutral, or none, and identifies the domain or identity that was evaluated. The header can appear multiple times in a message if it passes through several servers, each recording its own view.
Why It Matters
The Authentication-Results header is the definitive record of how a message was authenticated. When mail is filtered or rejected, this header explains which protocol failed and why, allowing a sender to fix the specific problem rather than guessing.
It is more comprehensive than older headers such as Received-SPF, which covered only SPF. The Authentication-Results header aggregates all three protocols, which is important because DMARC depends on how SPF and DKIM interact.
Senders and deliverability teams use the header to:
- Confirm that SPF, DKIM, and DMARC all passed as expected.
- Identify alignment failures, where a protocol passed but the domain did not match.
- Diagnose forwarding problems, where results change between hops.
- Verify that third-party senders are authenticating under the correct domain.
Because the header is written by the receiving server, it reflects the actual result rather than what the sender believes was configured.
Example
A marketer troubleshooting a DMARC failure reads the Authentication-Results header and sees dkim=pass but spf=softfail and dmarc=fail. The domain mismatch in the return path is the cause. After correcting the return-path domain, the next message shows dmarc=pass.
Was this useful?
Related Glossary Terms
Email Authentication Protocols
Email authentication protocols are technical standards that verify the identity of an email sender, helping mailbox providers distinguish legitimate mail from spam and phishing.
BIMI
BIMI (Brand Indicators for Message Identification) is an email standard that allows brands to display their logo next to their emails in supported email clients. It requires DMARC enforcement at quarantine or reject policy.
DKIM Alignment
DKIM alignment is the DMARC requirement that the domain in the From header matches the domain in the DKIM signature, confirming the visible sender domain is authenticated.
DKIM (DomainKeys Identified Mail)
DKIM (DomainKeys Identified Mail) is an email authentication method that uses digital signatures to verify that an email was not tampered with during transit and comes from a authorised domain.
DMARC Aggregate Report
A DMARC aggregate report is a machine-readable XML summary that receiving mail servers send to domain owners daily to show authentication results for their email traffic.
DMARC Alignment
DMARC identifier alignment determines whether the domain in the From header matches the domains used in SPF and DKIM authentication. Strict or relaxed.
Frequently Asked Questions
Authentication-Results aggregates SPF, DKIM, and DMARC results in one standard header, while Received-SPF records only the SPF outcome at a single hop. Authentication-Results is the more complete and current standard.
Yes. Each server that authenticates a message may add its own header, so a forwarded message can show several, each reflecting a different hop. Read the topmost, most recent header for the final recipient's view.
A `none` result means the server could not perform the check, usually because no record existed — for example, no SPF record for the domain. It is distinct from `fail`, which means the check ran and the message did not pass.
The Authentication-Results header reflects what the receiving server actually observed, so it is the authoritative source for diagnosis. ESP reports reflect the sending side and can disagree with the receiving server's view.