The Authentication-Results header

Authentication-Results is where the receiving mail server writes down what it found when it checked the message: whether SPF passed, whether DKIM signatures verified, and whether DMARC passed for the From domain. Read it as method=result, followed by the property that was checked, such as smtp.mailfrom= or header.from=. Only the copy added by your own mail provider counts. Any Authentication-Results header further down came from another server, or from the sender, and could say anything.

Authentication-Results: mx.example.org;
       dkim=pass header.d=example.com header.s=s2026 header.b=Ab3dEf9h;
       spf=pass smtp.mailfrom=bounce.example.com;
       dmarc=pass header.from=example.com

The structure

RFC 8601 defines the field. Its value is (RFC 8601 §2.2):

1. The authserv-id (mx.example.org above), which names the system that did the checks.
2. An optional version number. You'll rarely see one.
3. A list of results, separated by semicolons. Each has: - method=result, such as spf=pass; - an optional reason= with free-form text explaining the result; - one or more properties in the form ptype.property=value, saying what was checked.

Text in parentheses is a comment for humans, such as (sender IP is 203.0.113.5).

The header can appear more than once, and one header can carry several results (RFC 8601 §2.1). The order of methods within a header doesn't mean anything (RFC 8601 §4).

The authserv-id

The authserv-id identifies the authentication service that wrote the header (RFC 8601 §2.5). It's usually a domain or host name belonging to the receiving provider: mx.google.com, mx.example.org, a Microsoft host name. This is how you tell your own provider's verdict from anyone else's: find the header whose authserv-id belongs to your provider.

Microsoft 365's header is often written without a separate authserv-id: it typically starts directly with spf=. That's a known quirk. Rely on its position at the top of the header instead.

Methods and results

The common methods and their result words:

Other registered methods include iprev (matching forward and reverse DNS for the connecting IP) and auth (SMTP login). Each result has its own page: for example spf softfail, dkim fail and dmarc fail.

For DMARC, none means the From domain publishes no DMARC policy. fail means it has one, but no passing SPF or DKIM result aligned with it. pass means it has one and at least one aligned identifier passed (RFC 9989 §9.2).

Properties: what was checked

The property tells you which identity a result is about, which matters far more than most people realize.

The ptypes are smtp, header, body and policy (RFC 8601 §2.3). For DKIM, header.* points at the signature's tags, not at header fields (RFC 8601 §2.7.1).

The policy ptype marks a local decision that overrode or adjusted the raw result (RFC 8601 §2.4). A result of dkim=policy means the signature verified but the receiver decided not to accept it, for instance because the signature didn't cover the Subject.

Watch out: spf=pass and dkim=pass don't mean the From address is genuine. They're about smtp.mailfrom and header.d, which can be any domain the sender controls. Only dmarc=pass ties a passing result to the header.from domain. That's what DMARC alignment is about.

Why only your provider's header counts

Anyone can put an Authentication-Results header into a message before sending it. A forger can add dmarc=pass header.from=bank.example and hope a careless reader believes it.

RFC 8601 deals with this in two ways:

• Position. The header is a trace field, so it's added at the top. Receivers are told to put it above the trace fields they add themselves, which makes the trustworthy one easy to find (RFC 8601 §4).
• Removal. A receiving server must delete or neutralize any incoming copy that claims to come from its own authserv-id when it didn't actually add it (RFC 8601 §5). If Gmail's servers receive a message already containing Authentication-Results: mx.google.com; …, they're supposed to remove it.

So the rule for readers: find the topmost Authentication-Results header whose authserv-id is your provider, and use that one. Others lower down come from earlier hops, such as a forwarder, a corporate gateway or a mailing list, or from the sender. They might be honest, but you have no way to verify them.

When there are several

Multiple copies are normal: your provider may add one per check or per internal stage, and gateways, forwarders and even the sender's own provider add theirs lower down. Use the top one or ones from your provider. How each provider layers its own copies varies and is rarely documented.

ARC-Authentication-Results

ARC-Authentication-Results (AAR) looks almost identical but begins with an instance number, i=1;, i=2; and so on (RFC 8617 §4.1.1). It's part of ARC: an intermediary such as a mailing list or forwarder records the results it saw on arrival and seals them with a signature, so that later receivers can see what authentication looked like before the intermediary changed the message. An AAR is evidence from an intermediary, not your provider's verdict; your provider decides whether to trust that intermediary. See ARC explained.

Vendor-specific additions

Providers add their own detail. These parts are not defined by RFC 8601 and can change without notice.

Google

Gmail writes headers like:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s2026 header.b=Ab3dEf9h;
       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.5 as permitted sender) smtp.mailfrom=bounce@example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

The comment after dmarc= is widely read as: p= the domain's published policy, sp= its subdomain policy, dis= the disposition Gmail actually applied (NONE, QUARANTINE or REJECT). We couldn't find this documented on Google's public help pages, so treat that reading as convention rather than specification.

Microsoft

Microsoft 365 adds action= to DMARC and a separate compauth= result, which Microsoft documents in its anti-spam message headers reference:

Authentication-Results: spf=pass (sender IP is 203.0.113.5)
       smtp.mailfrom=example.com; dkim=pass (signature was verified)
       header.d=example.com;dmarc=pass action=none
       header.from=example.com;compauth=pass reason=100

• compauth is Microsoft's composite authentication verdict: it combines SPF, DKIM, DMARC and its own signals about the From domain. Values are pass, fail, softpass and none.
• reason is a three-digit code. Per Microsoft's documentation, 000 means an explicit DMARC failure with a quarantine or reject policy, 001 an implicit failure (the domain had no strong policy), codes in the 1xx range mean pass, and 2xx softpass.
• dmarc=bestguesspass is Microsoft-specific: the domain has no DMARC record, but Microsoft judged it would have passed if it had one.
• action=pct.quarantine and action=pct.reject refer to the old pct= tag, which let a domain apply its policy to only a percentage of failing mail. The current DMARC specification removed pct (RFC 9989 Appendix A.6), so expect these values to fade away.

Even a dmarc=fail doesn't guarantee rejection: receivers may decide not to enforce a published policy (RFC 9989 §5.4), and that's why Microsoft and Google record the action they actually took.

Reading it in practice

Find your provider's header, read dmarc= first, and if DMARC didn't pass, compare smtp.mailfrom and header.d with header.from to see whether a check failed outright or passed for the wrong domain. The analyser does this for you: it explains each Authentication-Results and ARC result and checks whether the SPF and DKIM domains align with the From domain.