Email headers series. This is the tactical guide to the Authentication-Results header, where receivers record SPF, DKIM, DMARC, and ARC verdicts. For the RFC catalog and other header deep-dives, see the headers and MIME hub →
Quick Authentication-Results reference
The Authentication-Results header is where the receiving MTA stamps its verdict on SPF, DKIM, DMARC, and ARC checks for each individual message. It is the per-message source of truth for authentication, more granular and more debuggable than DMARC aggregate reports. Every BIMI check, every DMARC forensic report, every downstream filtering decision consults this header first.
| Spec | RFC 8601 (obsoletes RFC 7601 and RFC 5451) |
| Written by | The receiving MTA that ran the authentication checks |
| Checked by | Downstream filters, BIMI, ARC signers, and every human debugger |
| Common methods | spf, dkim, dmarc, arc, bimi |
| Verdicts | pass, fail, softfail, neutral, none, temperror, permerror |
| Format | Multi-method, semicolon-separated, per-method ptype fields |
Every DMARC aggregate report you receive is a summary. Every Authentication-Results header is a receipt. When a specific message goes to spam and the sender does not know why, the answer is in the Authentication-Results header of that message: which auth mechanism failed, on which identifier, for which domain. This guide covers the exact format, how to parse it, how BIMI and ARC depend on it, and the 10 mistakes that cause misreads in production.
What the Authentication-Results header is
Authentication-Results is a trace header written by the receiving MTA after it has run authentication checks on an incoming message. The header records:
- Which authentication methods were checked (SPF, DKIM, DMARC, ARC, and others).
- The verdict for each method (pass, fail, softfail, and so on).
- The identifier that was checked against (envelope from, header from, DKIM signing domain).
- Optional supporting information (reasons for failures, DKIM header identity, alignment status).
Multiple Authentication-Results headers can appear in the same message, one per authenticating server (specified by the authserv-id field at the start of each). This matters when a message passes through several MTAs that each run their own authentication: each MTA stamps its own Authentication-Results, and downstream systems can pick whichever one they trust.
Unlike Received headers (which are trace records), Authentication-Results is written specifically to communicate authentication outcomes to downstream systems. It is machine-readable, follows a strict grammar, and every serious mail infrastructure parses it.
The exact format (RFC 8601)
The full grammar is complex; the practical structure is:
Authentication-Results: authserv-id;
method1=result1 (comment) ptype1.property1=value1;
method2=result2 ptype2.property2=value2;
method3=result3A concrete example from a real Gmail receipt:
Authentication-Results: mx.google.com;
dkim=pass header.i=@sender.example.com header.s=selector1 header.b=abc123;
spf=pass (google.com: domain of bounce+xyz@sender.example.com designates 203.0.113.42 as permitted sender) smtp.mailfrom=bounce+xyz@sender.example.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sender.example.com;
arc=noneReading it:
mx.google.com: the authserv-id, identifying which MTA ran the checks.dkim=pass: DKIM signature verified.header.i=@sender.example.comis the DKIM identity,header.s=selector1is the DKIM selector,header.b=abc123is the first few bytes of the signature (for correlation).spf=pass: SPF check passed. Thesmtp.mailfrom=ptype records the envelope sender that was checked against SPF. Comment in parentheses gives supporting context.dmarc=pass: DMARC evaluation passed.header.from=sender.example.comshows the From: header domain used for alignment. Parenthetical comment shows policy (p=REJECT), subdomain policy (sp=REJECT), and disposition (dis=NONE, meaning no punitive action).arc=none: no ARC chain present (this message was not forwarded through an ARC-signing intermediary).
The ptype fields, one by one
Each authentication method uses ptype (property type) fields to record what identifier it checked. The four most common:
smtp.mailfrom
The envelope sender (MAIL FROM in the SMTP conversation). Used by SPF checks. This is the address to which bounces are sent, not the visible From: header.
smtp.helo
The HELO/EHLO value from the SMTP session. Used by SPF checks against the HELO identity (a fallback when MAIL FROM is empty, common in bounce messages).
header.from
The domain in the visible From: header. This is what DMARC aligns against. When a receiver reports dmarc=pass header.from=example.com, it means the message’s From: header showed example.com and the DMARC evaluation for that domain passed.
header.d= (DKIM domain) and header.i= (DKIM identity)
DKIM signatures embed a signing domain (d= tag in the DKIM-Signature header) and an optional identity (i= tag). Both appear in Authentication-Results to record which domain signed and (if specified) which identity. For DMARC alignment, the receiver checks whether header.d aligns with header.from.
The seven verdicts
| Verdict | Meaning |
|---|---|
pass | Check succeeded, authentication verified |
fail | Check ran and produced a definitive failure |
softfail | SPF specifically: the sender says “probably not, but do not reject outright” (~all) |
neutral | SPF specifically: the sender says “no opinion” (?all) |
none | No policy or signature present to check |
temperror | Transient error (DNS timeout, network issue); retry may succeed |
permerror | Permanent error (malformed record, too many DNS lookups); retry will fail the same way |
The distinction between fail and softfail matters for SPF: softfail corresponds to ~all in the SPF record, indicating the sender is saying “this source is probably not authorized, but do not reject outright”. A hard fail corresponds to -all. Most receivers treat softfail as a mild negative signal, not a rejection.
The temperror and permerror distinction matters for debugging: temperror suggests transient DNS issues (worth retrying or investigating your DNS resolver), permerror suggests a broken record (worth auditing your SPF or DKIM configuration).
How BIMI and ARC depend on Authentication-Results
BIMI
BIMI (Brand Indicators for Message Identification) only displays a brand logo if the message passed DMARC with a sufficiently strict policy (p=quarantine or p=reject). The BIMI-checking mailbox provider reads the Authentication-Results header to verify dmarc=pass, then looks up the BIMI DNS record for the domain in header.from. Without a positive DMARC verdict in Authentication-Results, BIMI does not display. See our BIMI guide.
ARC
ARC (Authenticated Received Chain) is a mechanism for forwarders to preserve authentication results across hops. When an intermediary forwards a message (a mailing list, a shared inbox, an ESP relay), it typically breaks SPF alignment. ARC solves this by having the intermediary sign the current Authentication-Results into an ARC-Seal, which downstream receivers can consult to see the auth results as of that hop. The arc= field in Authentication-Results records the ARC verdict itself: pass means the ARC chain is intact, fail means it was tampered with, none means no ARC chain is present.
Authentication-Results vs DMARC aggregate reports
DMARC aggregate reports (the daily XML files that receivers send to your rua= address) are summaries: how many messages passed DMARC, from which IPs, with what alignment. They are useful for policy tuning and identifying unauthorized senders.
Authentication-Results is per-message: exactly what verdict this specific message received, with the exact identifiers used. Reasons why one specific message failed DMARC (which most senders care about) come from the Authentication-Results header of that message, not from the DMARC report.
Practical implication: if you are debugging a specific complaint from a specific recipient (“your email went to my spam folder”), ask the recipient to forward you the raw source of the message. The Authentication-Results header tells you what happened. DMARC reports will not.
Multiple Authentication-Results in one message
When a message passes through several MTAs that each run authentication (submission MTA, ESP relay, receiving MTA), each may add its own Authentication-Results header. The rule is straightforward: each authenticating server uses its own authserv-id, and downstream systems consult the header from the server they trust.
For example, a Microsoft 365 receiver might see:
Authentication-Results: outlook.office365.com;
dkim=pass header.i=@sender.com;
spf=pass smtp.mailfrom=sender.com;
dmarc=pass action=none header.from=sender.com
Authentication-Results: mx.forwarder.example.net;
dkim=pass header.i=@sender.com;
spf=fail smtp.mailfrom=sender.com;
dmarc=fail (p=REJECT) header.from=sender.comThe lower header (added by the forwarder) shows the message failed SPF because it was forwarded and the sending IP no longer matched the original SPF record. The upper header (added by Microsoft 365 after ARC processing or based on the forwarder’s own auth) shows a different verdict. Microsoft 365 makes filtering decisions based on its own header, but downstream consumers reading the raw source see both.
ARC exists specifically to help downstream MTAs trust an earlier Authentication-Results across a forwarding hop.
How to inspect the Authentication-Results header
Gmail
Show original on any message. The Authentication-Results header from Gmail’s own MTA is near the top of the header block, easy to spot.
Microsoft 365
View headers (Outlook web: three-dot menu → View message source; desktop: File → Properties). The Authentication-Results header appears with authserv-id starting with outlook.office365.com or mail.protection.outlook.com.
Command line parsing
grep -i "^Authentication-Results:" message.emlProgrammatically
The authres Python library, the @postal-mime/authres Node package, and PHP’s imap extension all parse Authentication-Results into structured data. Most mail parsers include a helper for it.
10 common Authentication-Results mistakes and misreads
- Trusting a forged Authentication-Results header. A sender can add fake Authentication-Results headers to the outgoing message. Receivers must strip any Authentication-Results with their own
authserv-idfrom the incoming message before running their checks, to prevent forgery. - Reading
dkim=passas full authentication success. DKIM pass means the signature verified, not that DMARC aligned. Checkheader.dagainstheader.fromfor alignment; DMARC verdict is what matters. - Confusing
smtp.mailfromwithheader.from. SPF checks against the envelope sender (smtp.mailfrom); DMARC aligns against the visible From (header.from). They are usually different for ESP-sent mail; alignment rules handle the relationship. - Assuming
dmarc=nonemeans DMARC is broken. It means the domain in header.from has no DMARC record. This is the default state for domains that have not deployed DMARC. - Reading
arc=noneas a problem. It just means no ARC chain is present. This is normal for messages that went straight from sender to receiver without a forwarder. - Ignoring the parenthetical comments. The comments in Authentication-Results carry critical debugging information: the specific SPF match, the DMARC policy applied, the reason for a failure. Do not skip them.
- Assuming multiple Authentication-Results headers are all trustworthy. Only the header written by the final receiver’s own MTA (matching your authserv-id) is fully trusted. Earlier headers may have been forged or written by MTAs with weaker checks.
- Treating
spf=softfailas an outright reject signal. Softfail (~all) is the sender saying “probably not authorized, but do not reject outright”. Most receivers treat it as a mild negative signal, not a hard reject. - Misreading
dkim=passfrom multiple signatures. A message can have multiple DKIM signatures (one from the sender, one from an ESP). Each generates its owndkim=line with differentheader.dvalues. DMARC alignment requires at least one to align with the From: header. - Not checking
dis=(disposition) in the DMARC comment. A DMARC verdict offaildoes not automatically mean the message was rejected. Thedis=field records what the receiver actually did:none,quarantine, orreject. A receiver may fail DMARC evaluation but override the policy and deliver anyway (or vice versa).
Authentication-Results FAQ
Why do I need Authentication-Results when I already have DMARC reports?
DMARC aggregate reports summarize outcomes across many messages: how many passed, how many failed, from which IPs. They are useful for policy tuning. The Authentication-Results header is per-message: it tells you exactly why one specific message received one specific verdict. When a recipient tells you their email went to spam, ask for the raw source; the Authentication-Results header answers the question directly.
Can I trust the Authentication-Results header on an incoming message?
Only the one written by your own MTA (matching your authserv-id). RFC 8601 specifies that receivers must strip any Authentication-Results header with their own authserv-id from incoming mail before running their own checks. Any Authentication-Results present with your authserv-id in the raw source was written by your infrastructure. Headers written by other MTAs (with other authserv-ids) may be legitimate, or may be forged; trust them at your own risk.
What is the difference between header.d and header.from?
header.d is the domain in the DKIM signature’s d= tag (the signing domain). header.from is the domain in the visible From: header. DMARC alignment requires these to match (either exactly or in a relaxed way, per the DMARC record’s adkim= tag). When they differ, DMARC alignment fails even if DKIM itself passed. This is the most common cause of DMARC failure for legitimate senders: DKIM signs with the ESP’s domain, but the From: header shows the brand’s domain, and they do not align.
Why does my message have dmarc=pass but still go to spam?
Authentication is necessary but not sufficient. DMARC pass tells the receiver the message is authentic; it does not tell them the message is wanted. Content filters, reputation scores, complaint history, and engagement metrics all play into the final placement decision. A dmarc=pass message from a sender with poor reputation still goes to spam. Authentication clears the first hurdle; deliverability is the rest.
What does arc=pass mean in practice?
ARC pass means the ARC chain is intact and the receiver trusts the authentication results as of an earlier hop. This is useful when a legitimate message is forwarded through an intermediary (mailing list, shared inbox, ESP relay) that would otherwise break SPF alignment. The receiver reads the ARC-Seal, confirms it is valid, and gives weight to the earlier Authentication-Results even though the direct check would fail. For senders, ARC is a fallback that makes forwarded mail survive DMARC when SPF cannot.
Should I set Authentication-Results on outbound mail?
Only if you are the authenticator. Outbound MTAs do not run authentication on their own outgoing mail; the sender is authenticating themselves via SPF, DKIM, and DMARC records in DNS. Adding a fake Authentication-Results header to your outbound mail does nothing useful and can be interpreted as an attempt to spoof. The receiver runs their own authentication and writes their own Authentication-Results; that is the trusted source.
Final words
The Authentication-Results header is where the answer lives for every “why did my email go to spam” question. Every DMARC failure, every SPF alignment break, every DKIM signature that did not verify, every ARC chain that broke on a forwarder: all of it is stamped, per message, in this header. Reading it is a five-minute skill that saves hours of debugging.
The mental model to keep: SPF checks smtp.mailfrom, DKIM verifies signatures against header.d, DMARC aligns header.d or smtp.mailfrom against header.from, ARC preserves earlier verdicts across forwarding hops, BIMI depends on DMARC pass. All of it flows through Authentication-Results.
For the underlying mechanisms, see our guides on SPF, DKIM, DMARC, and BIMI. For related headers, see the Message-ID and Received chain guides.
Perfect authentication is useless if the recipient does not exist.
SMTPing catches disposables, role-based, catch-all, syntax errors, dead mailboxes and traps before your DMARC-aligned message hits a hard bounce. 13 validation types, 25 free daily.
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.
