Summary

  • Revision 01 of the individual draft-chuang-dkim2-sender-policy became available on 12 September 2026 and adds evidence conditions around the proposed DKIM2 unaligned flag.
  • The proposal says that, on the relevant boundary signature, unaligned means no DMARC alignment check is expected and the alignment result will indicate pass.
  • Revision 01 narrows use of that flag: the message entering DKIM2 must already have an aligned, passing DKIM signature and remain verifiable to another DKIM2 receiver. It also adds recipient-binding checks as recommended evidence.
  • A single pass value would therefore cover both alignment that was tested and alignment that was waived. A useful operational record must retain which state occurred, which identity and signature were evaluated, and who accepted the exception under local policy.

A green cell can conceal two different decisions

Imagine two rows in a mail-security console. Both say pass. In the first, the receiver compared the relevant author domain with an authenticated DKIM identifier and found relaxed alignment. In the second, the receiver did not require that comparison because a DKIM2 signer set unaligned. The color is identical; the evidence is not.

That is the narrow governance problem exposed by revision 01 of DKIM2 Sender Policy. The draft tries to adapt DMARC to a relay chain in which intermediaries can modify a message while DKIM2 records those transitions. In such a chain, the visible From field at the final receiver may differ from the one associated with the originator’s first signature.

The proposal offers a choice. When possible, the receiver should recover the From associated with signature i=1 and use that author domain. If the entire chain validates, this preserves the originator’s policy context. Under local policy, the receiver may instead use the apparent From at the most recent signature. Those are not merely two parsing routes. They place policy lookup and accountable identity at different points in the chain.

The unaligned flag is a third move. A signer can indicate that it declines to take “ownership” of a message introduced from elsewhere. On the boundary signature carrying the flag, the draft says no alignment validation is expected and the result will indicate pass. That word no longer answers only “did the identifiers align?” It may answer “was the alignment requirement waived under this proposal?”

Revision 01 adds a prerequisite, not a new flag

The flag itself is not new in revision 01; it was already present in revision 00. The important change is the evidence path around it. The official comparison adds a condition for unaligned on the first DKIM2 signature: the incoming original must have been DMARC-aligned with a passing DKIM signature, and another DKIM2 receiver must be able to verify that original authenticated message.

Revision 01 also adds recommended checks for a relay bringing DKIM traffic into DKIM2. One signed To or Cc address can be compared with an SMTP RCPT TO address, and a signed recipient domain can be compared with the first DKIM2 signer’s d= domain. The alternative is to rewrite From so it aligns with the relay. The draft is unusually candid about the cost: the relay then takes ownership, and later DKIM2 receivers ignore the earlier authentication.

These additions are material because they turn a bare exception into a conditional exception. But the conditions do not disappear merely because the output is still called pass. An investigator needs to know whether alignment was measured, which message state supplied From, which signature carried unaligned, which earlier DKIM result satisfied the prerequisite, and whether recipient evidence was checked.

Without that record, later users can reverse the logic. They may read pass as evidence that alignment occurred, use the result in an aggregate report, or compare rates between receivers that made different local choices. The problem is not that either choice must be forbidden. The problem is that two local decisions become indistinguishable at the reporting surface.

Sender policy and receiver authority remain separate

The proposal describes DKIM2 signature flags as sender constraints. A receiver should respect them. If its local policy declines a constraint, the draft says it must not relay the message beyond its own Administrative Management Domain. If a constraint check fails, the receiver should apply the domain’s enforcement policy, again subject to local policy.

This preserves an important boundary from DMARC. A domain publishes policy, but a receiver owns its handling decision. The DNS record is evidence of what the domain asks for; it is not a remote control over another operator’s infrastructure. A signature flag likewise comes from a signer inside a changing custody chain. It cannot by itself decide the receiver’s trust configuration, reporting duty or final disposition.

Internet Mail Architecture supplies the roles that the draft is trying to join: originator, relays and final receiver. Authentication-Results supplies another caution. A result header is generated inside a receiver’s trust boundary; naming a cryptographic method inside it does not turn the field into portable signed proof. A future dkim2=pass consumer would still need to know who computed the result and, for this particular proposal, why it was permitted to be pass.

The institutional status also matters. Datatracker places the document in the active Individual Submissions group. Its document API shows no stream, responsible Area Director or intended standards level, while the text header says Independent Stream and Experimental. It is not an RFC, a DKIM Working Group decision or evidence of deployment. The related DKIM2 base specification and DKIM2 practices draft are separate works in progress.

Record the reason before the verdict travels

A minimum alignment-decision record can preserve the distinction without centralizing receiver policy. It should carry the result and a separate alignment_state: verified or waived. For a verified result, record the evaluated From source, the authenticated identifier, the signature index and the alignment mode. For a waiver, record the unaligned signer and index, the earlier passing DKIM evidence, the identity recovered from the original message and any recipient-binding evidence used.

Both paths need the DMARC policy domain and observed policy version, a digest for the message state or validated chain, the deciding ADMD, the local-policy rule or override, decision time and final disposition. The record need not expose recipient addresses publicly. It can retain hashed or access-controlled evidence while keeping the decision class explicit.

This field set is my proposal, not a requirement in the draft or any RFC. Its purpose is smaller: prevent a word chosen for compatibility from erasing the difference between proof and permission. Heng Lu’s Policy Mirror is useful here because the real control surface is not the label but the operator’s current policy, copies and enforcement path. A minimum initial specification can standardize the smallest shared reason code while leaving each receiver free to accept, reject or quarantine under local authority. And BTW Media’s evidence discipline requires the proposal to stay separate from proof that anyone has implemented it.

No incident follows from the text. No measured receiver currently reports this ambiguity. Revision 01 provides a better prerequisite for the exception; it does not yet make the meaning of the shared verdict self-evident. A green result is useful only when the system can say what turned it green.

Sources