Summary

  • RFC 8601 gives filters and mail clients a common field for authentication assessments. The field normally authenticates neither itself nor its producer. Its usable authority comes from a local relationship among the producing engine, accepted authserv-id, message path, boundary stripping and consuming rule.
  • A reproducible decision preserves the raw incoming field, the field removed at ingress, the locally generated replacement, producer and consumer versions, exact method properties, ARC custody where relevant, and the final action. The word pass without that chain is portable text, not portable trust.

Two equal strings, two different authorities

Consider a controlled test, not a reported incident. An external sender inserts a syntactically valid field claiming the receiving domain's own identifier and a successful DKIM result. At the border, the receiver records the incoming bytes, removes the impersonating field, performs its own checks and adds a new field with the same visible result. The two strings can be identical. Their evidentiary status is opposite.

The first is untrusted input. The second is an assertion by a known engine on a governed path. If the boundary MTA does not remove the first, a mail client or later filter can make a false conclusion from a perfectly formed header. RFC 8601 names this exact class of risk: a malicious party can forge the receiver's authserv-id and claim successful authentication.

The important object is therefore not merely a header. It is an assertion channel. That channel begins where a trusted producer evaluates a particular message state and ends where a configured consumer uses the result. Every hop, identifier and mutation between those points is part of the authority claim.

The field reports a test; it does not perform one

Authentication-Results exists so an upstream authentication engine can convey machine-readable output to downstream software. Its payload starts with an authentication service identifier, can include a version, and then contains method=result statements with optional reason and property data. Several methods can share one field, and a message can carry several fields.

The specification deliberately separates representation from disposition. It does not tell a receiver that dkim=pass must allow delivery, that spf=fail must reject, or that dmarc=pass makes content safe. Filters and Mail User Agents apply local policy. A result can change the depth of content inspection, add a display cue, contribute to a score or trigger investigation. Those are separate decisions.

This separation is a minimum common layer. RFC syntax and IANA registries allow independent software to parse method names, result names and properties consistently. They do not appoint a universal producer, select a trusted path or grant a result permission to bypass local controls. Interoperable vocabulary is not universal authority.

Trust is a relationship, not a token

RFC 8601 locates normal use inside an Administrative Management Domain, or ADMD. A producer performs authentication; one or more consumers use its output. The transfer between them must occur in a context in which the consumer can treat the producer's assertions as reliable. How that trust is established is explicitly local.

Physical location does not settle the question. A validation engine can run at a contracted service and still be inside the receiver's administrative boundary. A server in the same data centre can be outside it. The material questions are who controls the component, which input path it receives, which rules it executes, how its output reaches consumers and who can change each link.

That makes the trust-domain map an operational asset. It should name every ingress, producer, relay, mailbox store, MUA integration and filtering consumer. A diagram that says “secure email gateway” is insufficient if a disaster-recovery MX, regional relay or direct submission route follows different stripping rules.

The border must erase an impersonation before adding trust

Because the field often carries no integrity protection of its own, RFC 8601 requires a participating domain to remove incoming occurrences that claim association with that domain. The local engine can then add its own assessment. The removal rule is not housekeeping. It creates the provenance boundary.

A useful test sends forged fields for the current local identifier, every identifier retired within the maximum delivery window, different case and folding forms, multiple fields, fields mixed with Received lines, and fields inside an encapsulated message. Every public ingress path should produce the expected removal and replacement behavior. A single bypass route turns an allowlist into an attacker-controlled namespace.

Operations also need two records that serve different purposes. A restricted evidence store can preserve the raw incoming bytes and the fact that a field was removed. The message released to trusted consumers should contain only fields that satisfy local provenance rules. Destroying all trace of the forgery weakens incident analysis; leaving the forgery in the trusted message weakens enforcement.

authserv-id identifies a service only inside an inventory

Every field has an authserv-id, but the identifier does not authenticate itself. RFC 8601 permits it to refer to a whole ADMD or one validation engine, and leaves the naming scheme to local operation. A consumer must know which identifiers it accepts and what each one was authorized to report.

Renaming creates an interval, not an instant. Delayed delivery and later reassessment mean consumers may need both a current and a previous identifier for a bounded period. That overlap needs an owner, start and end time, producer mapping and negative tests. Keeping every historical identifier forever makes retirement meaningless; dropping the previous value immediately can make legitimate delayed mail appear external.

An identifier inventory should also carry method scope. A gateway permitted to report SPF and DKIM is not automatically the authority for an ARC result produced later, a DMARC policy decision made elsewhere or an SMTP AUTH assessment from a submission system. The string names a producer; the inventory supplies its bounded role.

Header position is evidence, not a signature

RFC 8601 treats Authentication-Results as a trace field and expects authentication agents to prepend it as work is performed. RFC 5322 gives trace blocks stronger order-preservation rules than ordinary headers. Position can therefore help reconstruct which assessment was added nearest to which transfer step.

But position is not self-authentication. A sender can place a field near the top of the message it submits. An intermediary can reorder ordinary fields. A gateway can prepend a correct result above an unremoved false one. A consumer that simply selects the first or last occurrence without a boundary model is substituting an ordering guess for provenance.

The safer parser first identifies the trusted trace block and accepted producer, then interprets the field's method and property values. Duplicate local identifiers, a local identifier below an external boundary, an unknown version or an unexpected method should become observable exceptions, not silent tie-breaks.

Each pass has its own subject

The IANA registry provides a common grammar for authentication methods. That common grammar can conceal different subjects:

  • SPF evaluates whether a domain authorized the connecting SMTP client for a scoped SMTP identity. It does not authenticate the message body or every visible address.
  • DKIM verifies a signature and reports properties such as the signing domain. It does not by itself prove that the visible human author is the signer or that unsigned content is safe.
  • DMARC, now specified by RFC 9989, evaluates alignment between the Author Domain and authenticated identifiers. A pass is an alignment result under the receiver's evaluation, not a general permission for a payment, reset request or executable attachment.
  • none, temperror, permerror, neutral and other registered outcomes describe method-specific states. They are not interchangeable risk scores.

A consumer must therefore bind action to method, result, evaluated property, producer, time and message state. Flattening them into one Boolean named authenticated creates authority that no underlying method supplied.

Free-form reason data deserves separate treatment. It can aid diagnosis, but it is not a remote command language. It can contain sensitive detail or hostile display characters and should not be promoted into executable policy.

Forwarding changes the boundary question

An assessment can be sound when created and untrustworthy after the message leaves its ADMD. RFC 8601 warns about messages that leave and re-enter a boundary and about encapsulated messages. A consumer cannot infer that surviving text still travels on the original trusted channel.

Recomputing authentication at the next boundary answers what that receiver can observe now. It may not reproduce what an earlier handler saw before a mailing list altered the body, changed envelope information or redirected the message. The old result can remain useful as historical testimony, but only if the next domain has a reason to trust its producer and transport.

ARC addresses this discontinuity by signing ordered sets of custody assertions, including an ARC-Authentication-Results field. Its strength is narrower than “the old pass becomes true everywhere.” RFC 8617 calls an assessment testimony by a verifiable party rather than independently reproducible hard evidence. The accuracy or syntax of the enclosed assessment is not required for the ARC chain itself to validate. A valid chain attributes assertions to sealing domains and preserves sequence; the receiver still decides whether those sealers are trustworthy and whether the testimony changes disposition.

This is a valuable distinction. Cryptographic custody can prove who carried a claim without proving that the claim was correctly measured. A sealer can be compromised, mistaken or outside the receiver's policy. ARC authenticates actors; it does not certify their judgment or the safety of content.

Running systems decide whether the boundary exists

Postfix exposes SMTP events, headers and bodies to Milter applications that can perform DKIM or DMARC work. SpamAssassin includes a plugin that consumes authentication-result fields. These are concrete producer and consumer surfaces, not proof that a particular deployment connects them safely.

The running test must traverse every real ingress. Submit a message carrying forged current and retired local identifiers. Confirm the boundary filter records and removes them. Confirm the intended engine runs, adds a field at the expected position and uses the expected registry semantics. Confirm every downstream consumer accepts the new local field, rejects the injected one and records the rule version behind its action. Repeat after gateway replacement, regional failover, vendor migration and emergency routing.

Configuration review remains necessary, but packets and resulting messages close the proof. A declared allowlist cannot show that an unlisted ingress bypasses it. A plugin load message cannot show which duplicate field a later rule consumed. A successful DKIM log cannot show that the assessed body is the one delivered after an intermediary mutation.

The narrow operating rule is simple: preserve the minimum interoperable syntax, localize producer trust and result use, and make adoption visible in the actual message path. A header may describe work. Only running evidence can show who did it, over which bytes, under whose authority and with what effect.

Sources