# The Authentication-Results Header

> RFC 8601 reference — syntax of the header receivers use to record SPF/DKIM/DMARC/iprev results, ptypes and properties, method result codes, and how to read one.

Source: emailmarketing.net — https://emailmarketing.net/learn/authentication/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](https://emailmarketing.net/learn/authentication/spf), [DKIM](https://emailmarketing.net/learn/authentication/dkim), [DMARC](https://emailmarketing.net/learn/authentication/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)

| ptype | Values drawn from |
|---|---|
| `smtp` | SMTP protocol commands (for example, `smtp.mailfrom`, `smtp.helo`, `smtp.auth`) |
| `header` | Message header fields or parts of them (for example, `header.d`, `header.i`, `header.b`, `header.from`) |
| `body` | Message body content (no properties are registered at present) |
| `policy` | Local policy information that adds to or overrides the raw results (for example, `policy.iprev`) |

## Common methods and their result codes

| Method | Result codes | Key properties |
|---|---|---|
| `spf` | pass, fail, softfail, neutral, none, policy, temperror, permerror | `smtp.mailfrom` (the 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` (the first bytes of the signature, to tell several signatures apart) |
| `dmarc` (registered by RFC 7489) | pass, fail, none, temperror, permerror | `header.from` (the RFC5322.From domain evaluated), often with `policy.dmarc` comments giving the disposition applied |
| `iprev` | pass, fail, temperror, permerror | `policy.iprev` (the client IP address whose reverse DNS was validated) |
| `auth` (SMTP AUTH) | pass, fail, none, temperror, permerror | `smtp.auth` (the authenticated identity), `smtp.mailfrom` |
| `arc` (registered by RFC 8617) | none, pass, fail | See [ARC](https://emailmarketing.net/learn/authentication/arc) |

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](https://emailmarketing.net/learn/authentication/arc)).

## Related articles

- [SPF](https://emailmarketing.net/learn/authentication/spf)
- [DKIM](https://emailmarketing.net/learn/authentication/dkim)
- [DMARC](https://emailmarketing.net/learn/authentication/dmarc)
- [DMARC aggregate reports](https://emailmarketing.net/learn/authentication/dmarc-aggregate-reports), the same results collected across all receivers