The Authentication-Results header (RFC 8601) records the outcome of SPF, DKIM, DMARC, ARC and other authentication checks that a receiving mail server performed. It is the primary diagnostic tool for anyone troubleshooting email authentication. This article explains the header format, every method you will encounter, how to read it, and how UK businesses use it to validate their email security setup.
The Authentication-Results header is a record of what a receiving mail server saw when it evaluated an incoming message's authentication. It is added by the receiver, never the sender. Each authentication check performed (SPF, DKIM, DMARC, etc.) produces an entry in the header.
For UK businesses investigating why a message was delivered, filtered, or rejected, this header is the single most informative data source. It tells you exactly which authentication passed, which failed, and why.
The general format from RFC 8601:
Authentication-Results: receiver-id;
method=result reason="..." identifier=value;
method=result reason="..." identifier=value;
...Each method's entry separated by semicolons. The receiver-id identifies the mail server performing the checks — typically its hostname.
A real example:
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=2026q2 header.b=abc123;
spf=pass (google.com: domain of [email protected] designates 203.0.113.25 as permitted sender) [email protected];
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=firm.co.uk| Method | What it checks |
|---|---|
spf | Sender Policy Framework |
dkim | DomainKeys Identified Mail |
dmarc | Domain-based Message Authentication, Reporting and Conformance |
arc | Authenticated Received Chain |
auth | SMTP AUTH (for submission) |
iprev | Reverse DNS / FCrDNS |
smime | S/MIME signature |
pgp | OpenPGP signature |
bimi | BIMI evaluation |
For typical UK business mail, you will see spf, dkim, dmarc and possibly arc. Others appear in specific contexts.
Permitted values per RFC 7208:
pass — sender IP authorised.fail — sender IP explicitly not authorised (hard fail).softfail — probably not authorised.neutral — no assertion.none — no SPF record published.temperror — transient DNS issue.permerror — permanent error (malformed SPF, 10-lookup limit).Associated fields in the header:
smtp.mailfrom= — envelope sender address checked.smtp.helo= — HELO hostname if applicable.Per RFC 6376:
pass — valid signature verified.fail — signature verification failed.neutral — signature present but malformed in a way that doesn't clearly fail.none — no signature.permerror — permanent error (malformed key, etc.).temperror — transient error.Associated fields:
header.i= — identity (usually matches d=).header.d= — signing domain.header.s= — selector.header.b= — first few characters of the signature, for identification.Per RFC 7489:
pass — SPF or DKIM aligned and passed.fail — neither aligned and passed.bestguesspass — DMARC not published but would pass if it were.temperror — transient issue evaluating DMARC.Fields:
p= — policy published (REJECT, QUARANTINE, NONE).sp= — subdomain policy.dis= — disposition applied (NONE, QUARANTINE, REJECT).header.from= — From header domain.Per RFC 8617:
arc=pass — ARC chain valid.arc=fail — chain broken.arc=none — no ARC headers.ARC entries may include chain-validation details — how many hops, which domains signed, at what stages.
iprevReverse DNS consistency check. iprev=pass means FCrDNS succeeded. Some receivers use this as an initial sanity check before deeper SPF/DKIM evaluation.
authFor submission scenarios where the client authenticated via SMTP AUTH. Typically applies at the submission server, not at downstream MX hops.
smime / pgpEnd-to-end signature verification. pass means the cryptographic signature is valid; fail means it is not.
bimiSome receivers include BIMI evaluation results in Authentication-Results. Shows whether the logo was displayed based on DMARC pass and (if required) VMC validity.
When diagnosing a specific message:
smtp.mailfrom domain align with DKIM's header.d? Does either align with DMARC's header.from?dis= field shows what the receiver actually did.p=reject but disposition shows NONE, something overrode the policy (commonly ARC or local override).Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=2026q2 header.b=abcdef;
spf=pass [email protected];
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=firm.co.ukEverything passes; delivered normally.
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=2026q2;
spf=fail [email protected];
dmarc=fail (p=REJECT) header.from=firm.co.uk;
arc=pass (i=1)SPF failed (forwarder's IP not in firm.co.uk's SPF). DMARC technically failed on alignment, but ARC chain validates the original good authentication. Receiver accepts based on ARC.
Authentication-Results: mx.google.com;
dkim=none;
spf=fail [email protected];
dmarc=fail (p=REJECT dis=REJECT) header.from=firm.co.ukAttacker tried to spoof From: firm.co.uk from their own domain. SPF failed, no DKIM signature, DMARC failed. Disposition applied: REJECT.
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=k1;
spf=pass [email protected];
dmarc=fail (p=QUARANTINE) header.from=firm.co.ukMailchimp sends via its own infrastructure with its own DKIM/SPF. Both pass, but neither aligns with firm.co.uk's From. DMARC fails; recipient receives message in spam (quarantine). Fix: configure Mailchimp to sign with firm.co.uk via CNAME delegation.
spf=pass, dkim=pass, dmarc=pass with correct alignment on your domain. Inbound mail received through the platform also generates Authentication-Results for your visibility in webmail or IMAP clients.A typical UK troubleshooting workflow when a specific mail delivery goes wrong:
Authentication-Results shows all pass but disposition reflects spam. Cause: content-based filtering (not authentication). Check message content, reputation, or user-specific filters.
Different receivers report different Authentication-Results. Likely different SPF/DKIM caching or different DNS views. Investigate per-recipient differences.
New SaaS tool sending on your behalf shows dkim=none or spf=fail-with-unexpected-IP. Missed during DMARC rollout. Add to SPF or configure custom DKIM delegation.
spf=fail, dkim=fail, dmarc=fail, but ARC is absent or broken. Forwarder does not support ARC. Contact forwarder operator or work around by routing critical mail differently.
Q: Is Authentication-Results trusted?
A: Only from the receiver itself. A third party can add a fake Authentication-Results header, but receivers identify their own (via the receiver-id field) and ignore others. Google's mx.google.com trusting only its own header is standard.
Q: Can I add Authentication-Results on my own mail server?
A: Yes — for inbound mail your server receives, add Authentication-Results reflecting your own SPF/DKIM/DMARC evaluation. Becomes part of the delivered message visible in clients.
Q: How do I see Authentication-Results in my mail client?
A: Gmail: Show original. Outlook: Message options → View source. Most mail apps have some "view headers" option. The header is not visible by default; you must opt into raw header display.
Q: Can Authentication-Results be spoofed by an attacker?
A: Headers in the message body can be forged. But receivers add their own header at receipt time and only trust their own. Attacker-added Authentication-Results headers from earlier hops are identifiable and can be disregarded.
Q: What does the reason string in parentheses tell me?
A: Free-form explanation from the receiver. Examples: "google.com: domain of ... designates ... as permitted sender" for SPF pass, or "(p=REJECT sp=REJECT dis=NONE)" for DMARC with policy details. Read for context.
Q: Why does DMARC sometimes pass with SPF or DKIM fail?
A: DMARC passes if either SPF or DKIM aligned and passed. One-of-two redundancy. Header shows each independently so you can see which pathway succeeded.
Q: Can I see multiple Authentication-Results headers in one message?
A: Yes. If mail traversed multiple receivers (gateway plus internal server), each may have added its own. Distinguishable by receiver-id.
Q: Does Authentication-Results help with troubleshooting deliverability?
A: Essential. When mail lands in spam or is rejected, the header tells you why. Missing DKIM, SPF misalignment, DMARC policy applied — all visible.
Q: Are there automated tools to parse Authentication-Results?
A: Yes. Some UK DMARC monitoring services parse inbound Authentication-Results for trend analysis. Commercial mail security gateways often surface it.
Q: How does Authentication-Results interact with ARC?
A: ARC preserves Authentication-Results from each hop in ARC-Authentication-Results headers. Current-hop Authentication-Results shows current state; ARC headers show prior hops' states.
Q: Can I filter mail based on Authentication-Results?
A: Yes — mail clients and server-side rules can match against the header. For example, Gmail filter: "from: firm.co.uk AND Authentication-Results contains spf=fail" captures unauthenticated mail claiming to be from firm.co.uk.
Q: What happens if different receivers report different Authentication-Results for the same message?
A: Normal — different receivers evaluate independently. Their own SPF/DKIM/DMARC logic may produce different results based on caching, configuration, or receiver-specific policies.
Q: Should my mail server strip incoming Authentication-Results before delivery?
A: Yes — strip externally-added headers that could confuse local evaluation. Add your own after evaluating. RFC 8601 section 5 specifies this handling.
Q: Does Authentication-Results reveal private information?
A: Only infrastructure data (IPs, domains, selectors). No recipient personal data. No privacy concern.
Q: Can Authentication-Results tell me whether TLS was used?
A: No — TLS is transport-layer. Separate headers may record TLS (Received header "with ESMTPS" etc.). Authentication-Results records message-level authentication only.
Q: Is there a UK-specific convention for Authentication-Results?
A: No — globally standardised per RFC 8601. Implementations may have minor quirks but format is universal.
Q: Does the header size affect delivery?
A: Headers add small bytes to the message. Rarely a concern; individual messages routinely have multiple headers totalling KB of metadata without issue.
Q: What does none vs empty authentication mean?
A: method=none explicitly means "no record published / no authentication attempted". Missing entry means "this method was not evaluated". Different semantically.
Q: How do I verify Authentication-Results is being added by my own server?
A: Send a test message from an external address to yourself. Look at the received message's raw headers. Should contain Authentication-Results with your server's hostname.
Q: Can Authentication-Results reveal whether BIMI displayed?
A: Yes, in receivers that include BIMI evaluation. bimi=pass or bimi=fail entries appear alongside other methods. Not all receivers include this.
Q: How do I interpret Authentication-Results in a bounce message?
A: Usually not present — bounces are reports from the receiver about rejection. The reason for rejection may be in the bounce's body but rarely as Authentication-Results. Check the original message's response code.
Q: What UK troubleshooting patterns rely on Authentication-Results?
A: "Mail to recipient X is going to spam — let me check the headers they received." Then read their Authentication-Results to identify which check failed. Standard first step.
Q: Is Authentication-Results a required header?
A: No — receivers add it as a convenience and diagnostic aid. Messages without it are perfectly valid. Most modern UK receivers add it consistently.
Q: How long has Authentication-Results existed?
A: Originally RFC 5451 (2009), updated by RFC 7001 (2013), then RFC 8601 (2019). The header has been stable with incremental refinements.
Q: Does every mail server support Authentication-Results?
A: Most modern servers do. Postfix (via OpenDKIM), Exim, Microsoft Exchange, Google Gmail, Axigen — all add Authentication-Results when configured for authentication checks. Very old servers may not.
Q: Can I opt out of receivers adding Authentication-Results to my inbound mail?
A: No — the receiver controls their own header insertion. You control only outbound.
Q: Does Authentication-Results interact with end-to-end encryption?
A: The header is part of the message envelope/metadata. S/MIME or PGP encryption does not hide it — it remains visible alongside other headers. Users seeing an encrypted message can still inspect Authentication-Results.
Q: How does Authentication-Results relate to DMARC aggregate reports?
A: Complementary. Authentication-Results is per-message; DMARC aggregate reports are per-day summaries across many messages. Use Authentication-Results for single-message diagnosis; use DMARC reports for trend analysis.
Q: Are there UK-specific services that analyse Authentication-Results across my mail flow?
A: Not purely for Authentication-Results. Commercial UK email security services (Mail Hardener, Red Sift) include Authentication-Results analysis alongside broader DMARC and transport monitoring.
Q: Does Authentication-Results work identically across UK mail providers?
A: Format is standard; specific wording of reason strings varies slightly by provider. Meaning is consistent.
Q: Can a UK receiver configure Authentication-Results to include custom methods?
A: Yes. RFC 8601 allows vendor-specific extensions. Uncommon in practice; standard methods cover most needs.
Q: What happens to Authentication-Results when a message is re-sent (e.g. "forwarded as attachment")?
A: Original headers, including Authentication-Results, travel with the message. A new Authentication-Results is added at the next hop reflecting the re-send. Multiple headers in total.
Q: Can Authentication-Results reveal that I am using a specific mail provider?
A: Yes — the receiver-id field typically names the mail provider's infrastructure (e.g. mx.google.com). Not sensitive but visible.
Q: Does my UK-specific deployment of DMARC affect Authentication-Results format?
A: No — format is receiver-controlled. Your DMARC policy influences the disposition field (dis=REJECT etc.) but not the overall format.
Q: How can I quickly test whether my mail produces correct Authentication-Results?
A: Send to [email protected]. You receive back a detailed report including what the verifier saw as Authentication-Results. Free and fast.
Q: Is there any scenario where I should add fake Authentication-Results to my outbound mail?
A: No. Adding faked Authentication-Results for receivers to trust is both ineffective (receivers identify their own) and bad practice. Never forge the header.
Q: How common is it for Authentication-Results to reveal misconfigurations I was not aware of?
A: Very. In initial DMARC rollouts, examining Authentication-Results typically reveals 1-3 misconfigured senders, third-party signing issues, or forwarder problems per UK business. Invaluable diagnostic.
Q: Should I retain copies of Authentication-Results for audit purposes?
A: If you archive mail, the header is preserved naturally. For specific compliance, retention aligned to your mail retention policy covers it.
Q: How does Authentication-Results from managed inbound filters (Mimecast, Proofpoint) differ?
A: They add their own Authentication-Results reflecting their gateway-level evaluation. Downstream mail servers may add their own on top. Multiple layers of the same evaluation from different perspectives.
Q: Can Authentication-Results include BIMI display details?
A: Receivers that support BIMI sometimes include bimi=pass or bimi=fail entries. Not all do — Google and Fastmail include it; Microsoft currently does not.
Q: What does a healthy UK business mail Authentication-Results look like?
A: Typically three clean passes: dkim=pass with your domain, spf=pass with your domain, dmarc=pass with REJECT policy. If forwarded, add arc=pass. Anything else warrants investigation.
Q: Is reading Authentication-Results a skill worth developing for UK IT teams?
A: Yes. It is the single most useful diagnostic for email delivery and authentication issues. Every UK IT team handling their own email benefits from being able to read these headers.
Q: Can mail clients alert me when Authentication-Results shows failures?
A: Some clients (Fastmail, Proton) visibly flag authentication failures. Gmail and Outlook typically do not expose this to users. Administrators can configure server-side rules based on Authentication-Results for finer control.
Q: Is there a way to automatically collect Authentication-Results data for all outbound mail I send?
A: Not directly — Authentication-Results is added by receivers, not visible to senders unless recipients forward back. DMARC aggregate reports fill this gap by reporting SPF/DKIM results from receivers.
Q: Does Authentication-Results change format between different versions of RFC?
A: Minor clarifications but core format is stable. RFC 8601 is current; earlier RFCs 5451 and 7001 are consistent. Parsers written for one generally work for others.
Q: How large can Authentication-Results headers grow?
A: Typically under 1 KB. Multi-method entries (SPF + DKIM + DMARC + ARC) with reason strings may reach 2 KB. Rarely an issue.
Q: Can Authentication-Results be signed to prevent tampering?
A: Not typically. Headers added by a receiver are trusted because they are added by the receiver at receipt time. Subsequent modifications would be detected by the receiver's own logs. Signing is not part of the Authentication-Results workflow.