Authentication-Results lets a mail system communicate authentication evaluations to downstream components. It is useful precisely because a filter or user interface may not repeat every original check. That usefulness also creates a security dependency: the consumer must know which evaluator's report it is reading and whether an attacker could have supplied that report.
Read the result together with its identity
The field includes an authentication service identifier, commonly called authserv-id, followed by method results and properties. A result such as spf=pass needs its associated evaluated identity; dkim=pass concerns a particular signing domain; dmarc=pass concerns the applicable author-domain alignment evaluation. Do not collect the word “pass” from anywhere in the header and display a universal authenticated badge. RFC 8601 sections 2.2 and 2.7.
The authentication service identifier names the reporting service in the relevant administrative context. It is not a signature over the field. A sender can type the same identifier into a message unless boundary handling prevents that untrusted field from being mistaken for a locally generated one.
Define the consumer’s trusted sources
Establish the actual receiving path, including approved upstream gateways and internal relays. Document which service identifiers are expected, which components generate results and how external fields are removed or preserved as untrusted. RFC 8601's security guidance addresses this trust-boundary problem. Do not infer a safe configuration solely from a plausible hostname or the field appearing near the top of a copied message. RFC 8601 section 7.
A configuration change to an upstream gateway can change which results are useful downstream. Review the dependency rather than simply adding every new identifier to a trusted list. A stale trust decision can make an otherwise well-parsed result misleading.
Read a hypothetical method-specific report
Suppose the established receiving evaluator reports spf=pass for smtp.mailfrom=vendor.example, dkim=pass for header.d=brand.example and dmarc=pass for header.from=brand.example. SPF pass does not align merely because it says pass; the exact DKIM signing domain in this example matches the author domain. The reported DMARC outcome is therefore compatible with that aligned signature, assuming an applicable policy and no unresolved evaluation error.
Now suppose another field reports spf=temperror. Do not overwrite the first SPF result without identifying its evaluator, hop and evaluated identity. The two reports may describe different evaluations. If that context is missing, report the conflict and uncertainty. These are hypothetical report values, not independently computed SPF, DKIM or DMARC results.
A useful consumer output names the trusted evaluator and displays each method, domain and result separately. It must not promote an untrusted same-name report merely because its hostname resembles the configured service.
Preserve nuance in the verdict
Keep method results separate, including none, fail and error states as applicable. An absent result is not a failure that you observed, and a temporary evaluation problem is not proof that the domain's permanent configuration is wrong. Correlate the selected report with message and connection evidence before remediation. End with the reporting service, its established trust basis, the method and identity, and the limit of the conclusion. Authentication can support routing or filtering decisions without certifying the sender's intent.
Record what each result actually means
- Evaluator: name the service and the evidence that establishes its origin.
- Method: preserve SPF, DKIM and DMARC as separate results.
- Identity: attach the evaluated domain or property to its own result.
- Uncertainty: keep missing, none, fail and error states distinct.
- Consumer: confirm gateway changes have not invalidated the trust configuration.