RFC 8601 — Authentication-Results Header Field

Proposed Standard Email Authentication Obsoletes RFC 7601 Authentication

ELI5: When a letter arrives at a company mailroom, the security guard checks the ID of the delivery driver, verifies the return address, and inspects the tamper seal. Then they attach a sticky note to the letter summarizing their findings: “Driver ID verified, return address confirmed, seal intact.” The Authentication-Results header is that sticky note — it’s a standardized way for the receiving mail server to record the results of all authentication checks so that downstream filters, spam engines, and mail clients can use the information without re-running the checks.

Why This RFC Exists

Email authentication involves multiple independent mechanisms: SPF, DKIM, DMARC, ARC, and others. Each produces its own result. Without a standard way to record these results, every component in the mail delivery pipeline — content filters, spam classifiers, user-facing clients — would need to independently re-evaluate every authentication mechanism.

RFC 8601 defines the Authentication-Results header field, a structured way for the border MTA (the first server in your infrastructure that receives the message from the internet) to record the outcome of all authentication checks in a single header. This result can then be consumed by all downstream components.

RFC 8601 obsoleted RFC 7601, which itself obsoleted RFC 5451. The updates refined syntax, registered additional method keywords, and clarified trust boundary handling.

How It Works

Header Structure

The Authentication-Results header has a defined grammar:

Authentication-Results: <authserv-id>; <method>=<result> [reason=<text>] [<property>.<type>=<value>] [; ...]

Real-World Example

Authentication-Results: mx.receiver.com;
dkim=pass header.d=example.com header.s=mtg20240101 header.b=LjIEJLN;
spf=pass (sender IP is 198.51.100.25) smtp.mailfrom=example.com;
dmarc=pass (p=reject dis=none) header.from=example.com;
arc=pass (i=1 spf=pass dkim=pass dmarc=pass)

How It's Generated

The border MTA receives a message from the internet via SMTP.
It runs SPF checks against the envelope sender and connecting IP.
It validates any DKIM signatures by querying DNS for public keys.
It evaluates DMARC policy and alignment.
It validates any ARC chain present on the message.
It prepends an Authentication-Results header summarizing all results, identified by its own hostname (the authserv-id).
Downstream content filters, spam engines, and delivery logic read this header instead of re-running the checks.

Key Technical Details

The authserv-id

The first token after Authentication-Results: is the authserv-id, typically the hostname of the server that performed the checks. This is critical for trust: a receiving system should only trust Authentication-Results headers whose authserv-id matches a server within its own administrative domain. Headers from external servers should be stripped or ignored.

Method Keywords

IANA maintains a registry of authentication method keywords. The most commonly used are:

Method	What It Checks	Defined In
`spf`	SPF evaluation of the envelope sender	RFC 7208
`dkim`	DKIM signature verification	RFC 6376
`dmarc`	DMARC alignment and policy evaluation	RFC 7489
`arc`	ARC chain validation	RFC 8617
`auth`	SMTP AUTH (RFC 4954) credentials	RFC 4954
`iprev`	Reverse DNS validation of connecting IP	RFC 8601

Result Values

Each method produces one of these result values:

Result	Meaning
`pass`	Authentication succeeded.
`fail`	Authentication failed definitively.
`softfail`	Authentication failed, but the sender policy suggests treating it as suspicious rather than rejecting (SPF-specific).
`neutral`	The sender makes no assertion (SPF `?all`).
`none`	No authentication record found (no SPF record, no DKIM signature, no DMARC policy).
`temperror`	Temporary failure (DNS timeout, etc.). Try again later.
`permerror`	Permanent error (malformed record, too many DNS lookups, etc.).
`policy`	Message passed authentication but failed a local policy check.

Property Types

Each result can include property/value pairs providing detail:

Property	Description
`header.d`	The DKIM signing domain (`d=` tag)
`header.s`	The DKIM selector (`s=` tag)
`header.b`	Truncated DKIM signature hash (first 8 chars)
`header.from`	The domain in the message `From:` header
`smtp.mailfrom`	The envelope sender domain (MAIL FROM)
`smtp.helo`	The EHLO/HELO hostname used by the sender

Multiple Results

A single Authentication-Results header can contain results from multiple methods, separated by semicolons. Alternatively, multiple Authentication-Results headers can be present (e.g., one per method). Both approaches are valid.

Trust Boundaries

The most critical security consideration: never trust Authentication-Results headers from external sources. An attacker can include a forged Authentication-Results header claiming dkim=pass and dmarc=pass. The border MTA must either strip all existing Authentication-Results headers that match its own authserv-id, or only trust headers it can verify were added within its own administrative domain.

Common Mistakes

Trusting external A-R headers: The single most dangerous mistake. If your mail system doesn't strip or ignore Authentication-Results headers from outside your trust boundary, an attacker can inject fake results. Always strip inbound A-R headers that use your authserv-id.
Not recording results at the border: If authentication checks happen at the border MTA but results aren't recorded in a header, internal filtering systems have no authentication data to work with and must re-run all checks (which may produce different results due to changed network position).
Ambiguous authserv-id: Using a generic hostname (like "localhost") as the authserv-id makes it impossible to distinguish between A-R headers from your system and those from other systems. Use your full MX hostname.
Misreading DKIM results: A dkim=pass result alone doesn't mean the message is safe. Check the header.d value to see which domain signed it. A pass for d=attacker.com is meaningless for messages claiming to be from example.com. This is why DMARC alignment matters.
Ignoring none results: A result of none means no record was found. For SPF or DMARC, this means the domain hasn't published authentication policy. This absence should be treated differently from an explicit fail.

Deliverability Impact

Diagnostic goldmine: When troubleshooting deliverability issues, the Authentication-Results header is the first place to look. It tells you exactly what the receiving server saw: which checks passed, which failed, and why.
Drives filtering decisions: Major email providers (Gmail, Microsoft, Yahoo) use authentication results as primary inputs to their spam filtering. A message with spf=pass, dkim=pass, and dmarc=pass has a significantly better chance of reaching the inbox.
ARC integration: The ARC-Authentication-Results header in ARC follows the same format as the standard Authentication-Results header, ensuring consistent reporting across forwarding hops.
Transparency: By exposing authentication results in message headers, RFC 8601 makes email authentication observable and debuggable. Senders can request recipients to forward raw headers to diagnose authentication failures.
Machine-readable: The structured format makes it straightforward for automated systems to parse and act on authentication results, enabling programmatic deliverability monitoring.