Treat modification history as evidence, not permission
A mailing list may add a footer or revise a Subject field for a legitimate reason. A hostile intermediary can also change a message. The important question is not simply whether something changed, but whether the receiver can reconstruct the relevant history, verify the responsible domains and decide what that history means. DKIM2 proposes machinery for the first two tasks; it does not automatically answer the third.
This explanation is pinned to draft-ietf-dkim-dkim2-spec-09, dated 1 November 2026 and currently an active Internet-Draft. Its proposed verification states concern undeclared modifications and consistency of the delivery path. Section 14.1 explicitly separates those checks from the value of a message or the benignity of declared changes. A verified chain is not a blanket trust recommendation.
Build an original but clearly fictional path
Consider three invented systems: author.larch.example, list.fir.example and inbox.birch.example. The first creates a message whose body consists of two lines, “Agenda” and “Friday at noon.” The list appends a third line, “List footer,” without otherwise changing the body. Assume the domains, envelope addresses, clocks and keys would satisfy the relevant checks. These are stipulated teaching inputs, not a captured message or evidence that any signature verifies.
At origination, the proposed representation includes Message-Instance m=1 with the original header and body hashes and DKIM2-Signature i=1 referring to that instance. After the list's change, a second instance records the current hashes and the information needed to reconstruct the earlier form. The list adds its own signature with the appropriate sequence and instance reference. Hash values and signature bytes are intentionally not invented in this example.
Explain why recipes run backward
Sections 5 and 12.1 describe recipes for recreating earlier message content. In the fictional body case, reconstructing the original means retaining the first two current lines and excluding the appended footer. The recipe explains how to recover the old state from the new one; it is not merely an instruction saying “add a footer.” A real fixture would need byte-accurate content and the draft's precise encoding rules.
A header-change variant needs its own reconstruction evidence. If a list prefixes the Subject, the original value must be recoverable for the earlier header-hash check. Record the original field, modified field and recipe together so that a reviewer can determine whether the change was represented faithfully. Do not rely on a rendered mail-client screenshot, which can hide folding, encoding and duplicate-field details relevant to a verifier.
Verify more than the newest signature
Under section 13, full verification checks the earlier message instances reconstructed by applying later recipes in descending order, as well as the signature chain. Checking only the final displayed body and most recent signature is a different, narrower operation. The draft separately defines provisional verification for limited initial assessment; the two results should not share an unqualified green badge.
The receiver also needs delivery context. Section 14.4 compares the latest signed envelope information with the actual SMTP transaction, while earlier hops must satisfy the chain rules. Section 14.8 checks the relevant current and historical From fields against the appropriate signing identities. A content-only archive cannot establish all those conditions if it has lost the original envelope and acceptance-time evidence.
For the fictional path, the expected review sequence is therefore: inspect syntax and ordering, retain SMTP context, check timestamps, validate the chain and keys, verify signatures, reconstruct each relevant instance, compare hashes, and assess From authenticity. This is a proposed reasoning trace. It is not a claim that a particular software package executed those steps or returned PASS.
Keep null recipes and redaction visible
The draft permits a null body recipe to indicate that an earlier body cannot be reconstructed. It does not permit null recipes for header changes. That distinction matters for a gateway that removes confidential material: a reversible recipe could retain the very content the gateway meant to remove. A privacy review should examine the recipe payload, not just the final body visible to the recipient.
Core -09 section 13 says earlier body hashes below a null recipe cannot be checked and the message is not Fully Verified. Local policy may nevertheless accept it, for example under a suitable relationship. That is not equivalent to cryptographically restoring the missing evidence. The lab should report the unavailable historical-body check and the separate local acceptance decision rather than renaming the result full verification.
Do not confuse requests with enforceable trust
The separate CanModify -00 draft explores originator requests about modifications. It was published on 2 November as an individual Internet-Draft. Its treatment is local policy, and some benignity discussion remains explicitly unfinished. It should not be merged into core -09 as a universal deployed permission system.
This creates a practical distinction for operators. A recipe can support attribution, an originator request can express a preference, and a receiver can decide whether to accept the resulting message. None alone proves the modified message is safe. Reviewer notes should identify which of those questions an observed result actually answers, particularly when a product report uses the word “trusted” without defining it.
Retain the exact missing verification evidence
The exact commission is: Trace one original, modified and verified message through the version-pinned draft model. The original fictional trace supplies expected structure and checks, but no signed message, computed hash, compatible verifier output or actual verified result exists in this package. The commissioning evidence gate remains open rather than being closed by an illustration.
A future authorized experiment should preserve both message forms, reconstruction data, envelope metadata, key snapshots, software versions and complete verifier diagnostics. Include an undeclared-change control and a null-recipe variant. Technical and privacy specialists must review the interpretation and exposure before any real use. Production applicability, visual review and owner publication approval are also outstanding; no migration or universal trust claim is made here.