Summary

  • The initial DKIM2 Authentication-Results draft proposes one machine-readable verdict for the message's whole signature chain, plus an origin domain and—when applicable—the sequence number where verification failed.
  • That verdict is not covered by DKIM2. It is meaningful only inside the Administrative Management Domain that generated it and must not be copied to a downstream system as proof.
  • On a non-pass result, header.d can still appear for diagnosis without being an authenticated identity; per-hop comments are advisory, attacker-influenced text and not a machine policy interface.

Imagine a message arriving at a gateway with two impressive-looking facts. Its DKIM2 signature chain verifies, and the gateway writes dkim2=pass into Authentication-Results. The message is then forwarded to another organization. If the second organization trusts the copied result, it has accepted a sentence written by the first gateway without checking either the chain or the authorship of that sentence.

That is the distinction exposed by the initial reporting draft, announced on 5 September 2026. DKIM2 proposes cryptographic evidence about how a message moved and changed. Authentication-Results is a report produced after verification for local consumers. The proof and the report do not share the same protection or the same jurisdiction.

The proposal is an individual Internet-Draft, not an endorsed IETF standard. Its Datatracker record shows an active work item with no formal standards standing, while the structured XML and the I-D announcement establish what revision 00 actually says and when it appeared. That status matters because the document requests registrations and can still change.

Its first design choice is economical. Ordinary DKIM can yield one result for each independent signature. The proposed DKIM2 method yields one resinfo for the message as a whole: the Chain of Custody holds or it does not. The machine-readable outcomes are pass, fail, permerror and temperror, inherited from the current DKIM2 WG draft, plus none when no DKIM2 signature was present and no verification was attempted. The WG document's Datatracker metadata is a separate record; adoption of the underlying mechanism does not confer status on this reporting draft.

Two properties compress the chain into operationally useful coordinates. header.d names the signing domain in the i=1 origin signature. header.i names the sequence number of the signature to which a failure is attributed. That second meaning is easy to misread: in DKIM1, header.i carries an Agent or User Identifier, while under the proposed DKIM2 registration it is an integer failure index. The method name must therefore travel with the property in every parser, event schema and dashboard.

The compression also has a deliberate information-loss boundary. DKIM2 verification proceeds from the most recently applied signature down the chain and may stop when it finds a failure. Lower-numbered signatures can then be listed as skipped. A skipped origin signature has not been authenticated merely because its domain remains legible. The draft consequently permits header.d on any result for diagnostic value but prohibits its use for reputation or disposition unless the overall result is pass.

This is stronger than a generic warning about email safety. It is a typed-data rule. The same field can be an authenticated identity in one result state and an unauthenticated observation in another. A data warehouse that extracts header.d while dropping the associated method and result silently upgrades a diagnostic string into identity evidence.

The deeper boundary lies around the whole Authentication-Results field. RFC 8601 designed it as communication between validation and assessment components inside one Administrative Management Domain, or ADMD. The producer and consumer need a trusted path. On ingress, the domain must remove instances that pretend to have been generated by its own authentication service but arrived from somewhere untrusted.

DKIM2 does not repair that boundary. It intentionally excludes Authentication-Results from its signed header set because the field is added after verification and commonly stripped when a message crosses domains. The new draft says the consequence plainly: a dkim2 result has no cryptographic protection. Any handler can add, alter or delete it without DKIM2 noticing. If an inbound gateway fails to remove a forged local-looking result, an attacker can supply the verdict that a downstream filter consumes.

The authserv-id identifies the service that says it performed the check; it does not authenticate itself. Its authority comes from local configuration, message path and ingress hygiene. This is why a globally unique-looking hostname is useful for administration but cannot turn a foreign header into a portable certificate.

The SMTP transaction boundary makes copied results wrong even when nobody forged them. DKIM2 binds the highest-numbered signature to the MAIL FROM and RCPT TO observed on the receiving transaction. A pass therefore records verification as far as one verifier in one transfer. The next forwarder creates a new transfer context. It must not copy the old dkim2 result for the next system's benefit. If it wants its handling to be verifiable, it adds its own DKIM2 signature; the next receiver evaluates the resulting chain and writes its own local report.

That rule preserves the difference between transferable evidence and a local assessment. A signature chain can be rechecked. A borrowed green label cannot show who checked it, against which envelope, with which keys, or before which later modification.

Per-hop detail moves into a comment. The recommended form can list each i= value, domain and outcome, followed by a diagnostic. The resemblance across implementations is for people troubleshooting delivery, not for parsers. A conforming parser may discard the comment. Automation must use the defined result and properties, never depend on the comment's presence or internal shape.

The comment also carries input influenced by senders and intermediaries: selectors, domains, MAIL FROM and RCPT TO values. Under RFC 5322, parentheses and backslashes have syntactic meaning. The draft requires them to be escaped and recommends length limits. Without that discipline, attacker-chosen text can terminate a comment and be parsed as another authentication result inside a trusted field. Rendering the diagnostic as markup would create another interpretation surface.

Privacy runs in the opposite direction. A faithful diagnostic can reveal every signing domain, a forwarding relationship or a recipient address. The information already exists in DKIM2 headers, but copying the summary beyond the local boundary widens exposure and gives operators another reason to remove it in both directions.

The proposal follows a precedent in ARC: keep the actionable status and a small number of properties machine-readable, while leaving richer instance detail in a comment. DKIM1 supplies the older property semantics, and the broader Internet Mail Architecture explains why an ADMD is an operating boundary rather than a universal authority.

The live IANA Email Authentication Parameters registry did not contain dkim2 when this article was prepared. Revision 00 asks IANA to add the method, header.d, header.i and five results. A request in a draft is coordination intent, not a completed registry act.

Heng Lu's Minimum Initial Specification supplies the right institutional reading. A common vocabulary can make implementations interoperable without making one verifier's local future decision binding elsewhere. Reality Layers keeps a reported status separate from the evidence, policy action and external outcome. Running-Code Primacy asks what the gateway actually removed, verified, emitted and consumed.

The draft is valuable precisely because it refuses to let cryptographic prestige leak into the reporting layer. The chain may pass. The sentence reporting that pass remains a locally authored, locally trusted and locally disposable record.