The Authentication-Results Header

RFC 8601 defines the Authentication-Results: header, which a receiving system prepends to record the outcome of the authentication checks it performed (SPF, DKIM, DMARC, iprev, SMTP AUTH, …) so downstream filters and MUAs — and troubleshooting humans — can consume them without re-running the checks. Reading this header in a delivered message is the fastest way to see exactly how a given receiver judged your authentication.

Syntax

Authentication-Results: <authserv-id> [version];
    <method>=<result> [reason="..."] [<ptype>.<property>=<value>] ... ;
    <method>=<result> ... ;

• authserv-id — identifies the system that performed the checks, typically a DNS domain (e.g., mx.google.com). This tells you whose verdict you're reading.
• Each semicolon-separated resinfo clause reports one method's result, optionally with a free-text reason and one or more ptype.property=value pairs identifying what was evaluated.
• Authentication-Results: example.com; none means the receiver performed no checks.
• Multiple methods can appear in one header, or the receiver can add several headers (one per method / per hop).

Property types (ptypes)

ptype	Values drawn from
smtp	SMTP protocol commands (e.g., smtp.mailfrom, smtp.helo, smtp.auth)
header	Message header fields or parts of them (e.g., header.d, header.i, header.b, header.from)
body	Message body content (no properties currently registered)
policy	Local policy information augmenting/overriding raw results (e.g., policy.iprev)

Common methods and their result codes

Method	Result codes	Key properties
spf	pass, fail, softfail, neutral, none, policy, temperror, permerror	smtp.mailfrom (domain or full MAIL FROM address checked), smtp.helo
dkim	pass, fail, none, neutral, policy, temperror, permerror	header.d (signing domain), header.i (AUID), header.s (selector), header.b (first bytes of signature, to disambiguate multiple signatures)
dmarc (registered by RFC 7489)	pass, fail, none, temperror, permerror	header.from (RFC5322.From domain evaluated); often policy.dmarc comments with the applied disposition
iprev	pass, fail, temperror, permerror	policy.iprev (the client IP whose reverse DNS was validated)
auth (SMTP AUTH)	pass, fail, none, temperror, permerror	smtp.auth (authenticated identity), smtp.mailfrom
arc (registered by RFC 8617)	none, pass, fail	see ARC

policy as a result means the check completed but local policy suppressed or overrode the normal result.

Reading one — worked example

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

Interpretation: Google's MX checked the message. A DKIM signature by example.com (selector s2048) verified; SPF passed for the bounce domain bounce.example.com at IP 203.0.113.5; DMARC passed for the From: domain example.com (its published policy is reject; disposition applied was none, i.e., delivered). DKIM is aligned (d= equals From: domain); SPF passes and bounce.example.com is relaxed-aligned with example.com — both DMARC legs succeeded.

Trust and the removal rule

The header is trivially forgeable by a sender, so its security model is trust-boundary hygiene:

• An MTA conforming to RFC 8601 MUST delete any instance of the header that claims (via its authserv-id) to have been added within the receiver's own trust boundary but did not actually come from a trusted internal MTA. Border MTAs strip or rename incoming instances bearing their own authserv-id before adding their genuine one.
• Consumers (filters, MUAs) should only honor headers whose authserv-id belongs to their own ADMD; anything else is untrusted foreign data.
• Consequently, when diagnosing deliverability, read the topmost Authentication-Results header whose authserv-id matches the final receiving provider — lower ones may be stale (earlier hops) or spoofed.

Relationship to other headers

• Received-SPF: is SPF's own older per-hop result header (RFC 7208); Authentication-Results supersedes it in practice as the unified reporting mechanism.
• ARC-Authentication-Results: reuses this exact payload format to snapshot results at each forwarding hop — see ARC.

Related

• SPF, DKIM, DMARC — the methods reported here
• DMARC aggregate reports — the batch view of the same results across all receivers