The Authentication-Results Header

To see exactly how a receiver judged your authentication, open a message it delivered and read its Authentication-Results: header. This is the fastest way to find out.

RFC 8601 defines the header. A receiving system adds it at the top of the message to record the outcome of the authentication checks it performed (SPF, DKIM, DMARC, iprev, SMTP AUTH and others). Filters and mail clients (MUAs) later in the path, and people troubleshooting, can then use those results without running the checks again.

Syntax

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

• authserv-id identifies the system that performed the checks, typically by a DNS domain (for example, mx.google.com). It tells you whose verdict you are reading.
• Each resinfo clause, separated from the others by semicolons, reports the result of one method. It can include a free-text reason and one or more ptype.property=value pairs that identify what was evaluated.
• Authentication-Results: example.com; none means the receiver performed no checks.
• Several methods can appear in one header, or the receiver can add several headers (one for each method or each hop).

Property types (ptypes)

Common methods and their result codes

When policy appears as a result, the check completed but local policy suppressed or overrode the normal result.

Reading one: a 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

Google's MX server 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, and the disposition applied was none, which means the message was delivered.

DKIM is aligned, because d= is the same as the From: domain. SPF passes, and bounce.example.com is aligned with example.com under relaxed alignment. Both paths to a DMARC pass succeeded.

Trust and the removal rule

A sender can forge this header easily, so its security depends on careful handling at the trust boundary:

• An MTA that conforms to RFC 8601 MUST delete any instance of the header that claims (through its authserv-id) to have been added inside the receiver's own trust boundary but did not actually come from a trusted internal MTA. Border MTAs remove or rename incoming instances that carry their own authserv-id before they add their genuine one.
• Filters and MUAs should only trust headers whose authserv-id belongs to their own ADMD. Anything else is untrusted data from outside.
• So when you diagnose deliverability, read the topmost Authentication-Results header whose authserv-id matches the final receiving provider. Lower ones may be out of date (from earlier hops) or forged.

Relationship to other headers

• Received-SPF: is SPF's own, older header for recording the result at each hop (RFC 7208). In practice, Authentication-Results has replaced it as the single way to report results.
• ARC-Authentication-Results: reuses exactly this format to record a snapshot of the results at each forwarding hop (see ARC).

Related articles

• SPF
• DKIM
• DMARC
• DMARC aggregate reports, the same results collected across all receivers