The Authentication-Results header is the receiving server's official record of whether your message passed SPF, DKIM and DMARC. Every mailbox provider that runs these checks writes the outcome into this one header, so reading it correctly tells you exactly why a message landed in spam, got quarantined, or sailed into the inbox. Once you know where each verdict lives and what the qualifier words mean, a 200-character string of jargon becomes a precise diagnosis.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
Where to find the header and how it is built
In Gmail, open the message, click the three-dot menu and choose Show original. In Outlook or Microsoft 365, open the message, go to File then Properties, and read the Internet headers box. In Yahoo, open the message, click More and then View raw message. You are looking for lines that begin with Authentication-Results:.
The header is defined by RFC 8601 and always starts with the hostname of the server that did the checking (the authserv-id), followed by one or more method=result pairs separated by semicolons. A single method result looks like this:
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=news.example.com; dkim=pass header.i=@example.com; dmarc=pass (p=REJECT) header.from=example.com
Read it left to right. The authserv-id is mx.google.com. Then come three verdicts: SPF passed for the envelope domain, DKIM passed for a signature owned by example.com, and DMARC passed with the domain's published policy shown as p=REJECT. Trust only the header written by the final receiving server you control or use. Any Authentication-Results header added by an upstream hop can be forged, which is why providers strip and re-stamp their own.
Reading a real Gmail header field by field
Gmail is the most common header you will inspect. A full authenticated message often carries this:
Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=selector1 header.b=Ax3kf9; spf=pass (google.com: domain of bounce@news.example.com designates 198.51.100.7 as permitted sender) smtp.mailfrom=bounce@news.example.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
Here is what each token means:
dkim=pass- the cryptographic signature verified against the public key in DNS.header.i=@example.com- the identity claimed by the DKIM signature, taken from the i= tag inside the DKIM-Signature. This is the domain that DKIM authenticated.header.s=selector1- the selector, which tells you which DNS TXT record held the public key (selector1._domainkey.example.com).header.b=Ax3kf9- the first bytes of the signature itself, useful only for telling two signatures apart.spf=pass- the sending IP is authorised by the SPF record of the envelope domain.smtp.mailfrom=bounce@news.example.com- the envelope sender, also called the Return-Path or MAIL FROM. SPF always checks this domain, not the visible From address.dmarc=pass- DMARC succeeded because at least one of SPF or DKIM passed and aligned with the visible From domain.header.from=example.com- the domain in the From header a human sees. DMARC alignment compares this against smtp.mailfrom and header.i.(p=REJECT sp=REJECT dis=NONE)- the domain's published policy (p), subdomain policy (sp), and the disposition actually applied (dis).dis=NONEmeans no punitive action was taken because the message passed.
The gap between smtp.mailfrom and header.from is the single most important idea here. A message can have spf=pass for news.example.com yet still fail DMARC if the visible From is example.com and the two do not align. Understanding that split is the core of SPF, DKIM and DMARC explained.
Outlook and Yahoo variations
Microsoft 365 stamps a slightly different format and adds its own compauth verdict:
Authentication-Results: spf=pass (sender IP is 198.51.100.7) smtp.mailfrom=news.example.com; dkim=pass (signature was verified) header.d=example.com; dmarc=pass action=none header.from=example.com; compauth=pass reason=100
Two things differ from Gmail. Microsoft reports the DKIM domain as header.d= (the d= tag) rather than header.i=; in practice both point to the signing domain. It also adds compauth, a composite authentication result Microsoft uses to catch spoofing that slips past individual checks. compauth=pass reason=100 is healthy. A compauth=fail reason=000 or reason=001 usually means neither DKIM nor SPF aligned, and Microsoft treated the message as implicit spoof.
Yahoo follows the RFC 8601 layout closely:
Authentication-Results: atlas.yahoo.com; dkim=pass header.i=@example.com header.s=s2048; spf=pass smtp.mailfrom=example.com; dmarc=pass(p=REJECT) header.from=example.com
The tokens carry the same meaning across all three providers. Once you can read Gmail's version, you can read any of them.
Every result value and what it means
The qualifier after each method is the verdict. This table covers every value defined in the SPF and DMARC RFCs.
| Result | Meaning | Typical cause |
|---|---|---|
| pass | The check succeeded and the identity is authorised | Correct SPF record or valid DKIM signature |
| fail | The check ran and the sender is not authorised | Sending IP missing from SPF, or -all hard fail |
| softfail | SPF suspects the sender but does not hard-reject | The record ends in ~all and the IP is not listed |
| neutral | SPF explicitly takes no position | The record uses ?all |
| none | No policy exists to check against | No SPF record, no DKIM signature, or no DMARC record |
| policy | The check ran but local policy overrode the result | Provider-specific handling |
| temperror | A temporary failure, retry may succeed | DNS timeout or transient lookup error |
| permerror | A permanent error in the record itself | Broken SPF syntax or more than 10 DNS lookups |
Two of these deserve special attention. softfail means your SPF record ends in ~all rather than -all, so unauthorised mail is accepted but flagged. permerror on SPF very often means you exceeded the 10 DNS lookup limit in RFC 7208, which is a record problem, not a sender problem, and is worth fixing directly. The difference between temperror and permerror decides whether you wait or edit your DNS.
The if-X-failed-fix-Y decision tree
Work through the verdicts in this order. DMARC is the outcome that decides inbox placement, so start by asking why it did not pass.
If dmarc=pass
Nothing to fix. At least one of SPF or DKIM passed and aligned with your From domain. You are done.
If dmarc=fail but spf=pass and dkim=pass
This is an alignment failure, not an authentication failure. SPF passed for the envelope domain and DKIM verified, but neither matched the visible From domain. Check that smtp.mailfrom and header.i share the organisational domain of header.from. Fix the misaligned one. DKIM alignment is usually the easier lever, covered in fix DKIM alignment.
If spf=fail or spf=softfail
The sending IP is not in your SPF record. Add the IP or the provider's include mechanism, and confirm the record ends in -all. If SPF passes at your own server but fails after the message is forwarded, that is expected behaviour because forwarding changes the sending IP; see why email forwarding breaks SPF. In that case, rely on DKIM to carry authentication through the hop.
If dkim=fail
The signature did not verify. The usual causes are a mail gateway that modified the body after signing, a rotated key that no longer matches the DNS record, or the wrong selector. Read header.s= to find the selector, then confirm selector._domainkey.yourdomain.com returns the current public key.
If spf=permerror or dkim=permerror
The record itself is broken. For SPF this almost always means too many DNS lookups or invalid syntax. For DKIM it usually means a malformed public key record. This is a DNS edit, not a sender change.
If dmarc=none
You have no DMARC record, so receivers cannot enforce anything. Publish at least a monitoring policy such as v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com and move toward enforcement once your legitimate sources authenticate cleanly. The path from monitoring to enforcement is laid out in DMARC policy: none vs quarantine vs reject.
For long-term insight, the Authentication-Results header shows one message at a time, while reading DMARC aggregate reports shows the same verdicts across every source sending as your domain.
Frequently asked questions
What is the difference between smtp.mailfrom and header.from?
smtp.mailfrom is the envelope sender used during the SMTP transaction, also called the Return-Path, and it is what SPF checks. header.from is the address a human sees in the From line, and it is what DMARC alignment is measured against. They are often different domains, which is why a message can pass SPF but still fail DMARC.
What does header.i mean in a DKIM result?
header.i is the signing identity taken from the i= tag inside the DKIM-Signature header, for example @example.com. It tells you which domain owns the signature that verified. Some providers report the same information as header.d, the signing domain tag. For DMARC alignment, the domain in header.i or header.d must match your From domain.
Does spf=softfail mean my email will be rejected?
No. Softfail means your SPF record ends in ~all, so receivers accept the message but treat it as suspicious. It is a warning, not a rejection. If DMARC is set to reject and the message also fails DKIM alignment, then it can still be blocked, so do not rely on softfail as a safety net.
Can I trust an Authentication-Results header added by another server?
Only trust the header stamped by the final receiving server you control or use, identified by its authserv-id at the start of the line. Any Authentication-Results header inserted by an earlier hop can be forged by an attacker, which is why mailbox providers remove untrusted copies and add their own before delivery.