What this RFC defines
RFC 8601 defines the Authentication-Results header field, which records the outcomes of email authentication checks performed by a receiving server. SPF, DKIM, and DMARC results are all written into this header after verification, and it is passed downstream for use by spam filters, BIMI processors, and other systems.
Where you see it in practice
When you view the full headers of an email in Gmail or Outlook and see Authentication-Results: mx.google.com; dkim=pass header.i=@example.com; spf=pass smtp.mailfrom=example.com; dmarc=pass, that block is an Authentication-Results header as defined by RFC 8601. BIMI uses this header to verify DMARC pass before displaying a sender’s logo. Anti-spam systems weight authenticated messages differently based on these recorded results.
How it connects to other RFCs
RFC 8601 obsoletes RFC 7601. It is the output header for SPF checks (RFC 7208), DKIM verification (RFC 6376), DMARC evaluation (RFC 7489), and ARC validation (RFC 8617). These authentication RFCs define how checks are performed; RFC 8601 defines how results are recorded and communicated to downstream systems.
Current status
RFC 8601 is a current standard, published May 2019. The Authentication-Results header it defines is universally added by receiving MTAs at major mailbox providers and is a critical input for BIMI adoption and any downstream spam filtering system that needs to act on authentication outcomes.
The Authentication-Results header
RFC 8601 (updated by RFC 8553) defines the Authentication-Results header field, which lets a receiving MTA record the outcomes of authentication checks it performed (SPF, DKIM, DMARC, ARC, DKIM-Adam-Millard-signature) so that downstream systems and users can see what was verified. The header syntax is Authentication-Results: mx.example.com; dkim=pass header.d=sender.com; spf=pass smtp.mailfrom=sender.com; dmarc=pass header.from=sender.com. Each result includes the mechanism name, the outcome, and identifying context.
Why it matters for debugging
When deliverability problems occur, the Authentication-Results header is usually the first place to look. If SPF fails, DKIM fails, or DMARC is not aligned, this header shows exactly why. Every major mailbox provider stamps inbound mail with Authentication-Results before delivery, and this header is preserved in the raw message source. Gmail, Outlook.com, Yahoo, and enterprise MTAs all follow the RFC 8601 syntax, though the specific mechanism identifiers vary slightly between providers.
Trust boundaries
Authentication-Results is only trustworthy when added by a system inside your organization trust boundary. A message forwarded from outside can carry an Authentication-Results header that lies about the outcomes. Receiving MTAs are expected to strip inbound Authentication-Results headers that claim to have been added by the local system, preventing spoofing. This defense is built into every major MTA (Postfix, Exim, Sendmail) but can be bypassed if a middlebox rewrites headers incorrectly. If Authentication-Results seems to contradict what your DKIM/SPF/DMARC configuration should produce, header injection is worth investigating.
RFC 8601 (May 2019) defines the Authentication-Results header: the standardized way for receiving MTAs to record authentication verdicts (SPF, DKIM, DMARC, and others) into the message headers so downstream systems and end users can see them. Every major receiver (Gmail, Outlook, Yahoo, iCloud) adds this header. Obsoletes RFC 7601. Parsing this header is the primary way to determine why a message was accepted, quarantined, or rejected.
RFC 8601 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Record authentication verdicts (SPF/DKIM/DMARC/ARC/others) in message headers |
| Added by | Receiving MTA (typically the border MTA that performed authentication) |
| Multiple headers | One per authenticating MTA; ordered top-most = most recent |
| Result values | none, pass, fail, policy, neutral, temperror, permerror (per method) |
| Trust boundary | Must be stripped by receivers at edge; only trust internal-to-domain headers |
| Published | May 2019 (obsoletes RFC 7601) |
| Related | RFC 8617 ARC (chains Authentication-Results across intermediaries) |
Authentication-Results header anatomy
Common authentication methods
| Method | What it verifies | Common result values | Key properties |
|---|---|---|---|
spf | MAIL FROM authorized by SPF record | pass, fail, softfail, neutral, none, temperror, permerror | smtp.mailfrom, smtp.helo |
dkim | DKIM signature verification | none, pass, fail, policy, neutral, temperror, permerror | header.d, header.i, header.s, header.b |
dmarc | DMARC policy evaluation | none, pass, fail, temperror, permerror | header.from, p=, sp=, dis= (applied disposition) |
arc | ARC chain validation | none, pass, fail | smtp.remote-ip, header.oldest-pass, arc.chain |
iprev | Reverse DNS (PTR) matches forward (FCrDNS) | pass, fail, temperror, permerror | policy.iprev |
auth | SMTP AUTH per RFC 4954 | pass, fail | smtp.auth |
bimi | BIMI record and evidence document | pass, fail, temperror, declined, skipped | header.d, header.selector |
Result values and their meanings
| Result | Meaning |
|---|---|
none | No record found; no assertion possible |
pass | Verification succeeded |
fail | Verification failed (mismatch, invalid signature, unauthorized IP) |
policy | Policy rules caused the result (independent of cryptographic verification) |
neutral | Explicit no-assertion from the sender’s policy |
temperror | Temporary failure (DNS lookup timeout); should retry |
permerror | Permanent failure (syntax error, exceeded limits); investigate configuration |
Trust boundaries and header stripping
Common Authentication-Results handling mistakes
dis= property in DMARC results. When DMARC evaluates a message, it returns both the verdict (pass/fail) and the applied disposition (none/quarantine/reject). A DMARC fail with dis=none means the receiver observed the fail but did not act on it (perhaps because the sender’s policy is p=none). Reading only the verdict misses this operational detail.Related standards and further reading
- Authentication-Results Header Guide: parsing patterns and examples
- SPF Record Guide: understanding the SPF verdict
- DKIM Record Guide: understanding the DKIM verdict
- DMARC Record Guide: understanding the DMARC verdict and disposition
- Received Headers and Email Trace Chain: correlating Auth-Results with the delivery path
Frequently asked questions
Why do I see multiple Authentication-Results headers?
Each MTA that performs authentication adds its own header with its own authserv-id. A message routed through your provider’s edge, then your enterprise gateway, then your internal MTA will carry three Authentication-Results headers. Only trust headers from your own authenticated infrastructure (matching authserv-id); the others could be forged or represent intermediate verdicts before the message was modified.
Can I trust an Authentication-Results header from an external server?
No. Any sender can include an Authentication-Results header claiming any verdict they want. Only headers added by a trusted authenticator inside your trust boundary have meaning. This is why RFC 8601 mandates stripping pre-existing headers with your authserv-id at the trust boundary. If you accept mail across a trust boundary and want to preserve upstream verdicts, use ARC instead, which chains signatures cryptographically.
What is the difference between DMARC=pass and DMARC=none in the header?
pass means DMARC evaluation ran and the message aligned (SPF or DKIM aligned with From domain, and at least one passed). none means the sender has no DMARC record published, so no evaluation was possible. Treating none as equivalent to pass is a common mistake: a sender with no DMARC is unauthenticated territory and should be treated more skeptically than a sender with published DMARC and a passing verdict.
Where does BIMI show up in Authentication-Results?
BIMI (Brand Indicators for Message Identification) uses the bimi= method. A pass result means the domain has a valid BIMI record, a valid Verified Mark Certificate (VMC), and successfully aligned with a passing DMARC verdict. Result values include pass, fail, none, temperror, declined (when receiver policy skips BIMI evaluation), and skipped. BIMI is not defined in RFC 8601 itself; the specification is in a separate draft that extends the RFC 8601 framework.
What is the dis= property in a DMARC result?
dis (short for “disposition”) reports the action the receiver actually took, distinct from the DMARC verdict. Values: none (no action taken), quarantine (delivered to spam), reject (bounced). A message can have dmarc=fail (p=REJECT dis=quarantine) if the DMARC policy is p=reject but the receiver chose to quarantine instead. This is common at Gmail, which applies quarantine even when senders publish p=reject for many failing messages, to preserve legitimate mail that happens to fail alignment through forwarding or list operations.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
