Establish exactly what is current
DKIM2 is worth tracking because it tries to connect message integrity with the route and changes a message experiences. That makes it relevant to forwarding, mailing lists and replay, but it also makes a vague claim of “DKIM2 readiness” difficult to evaluate. A responsible review starts with document identity, not a feature slogan. Record the draft revision, its date, the relevant implementation and the particular behavior being assessed before comparing capabilities.
On 8 November 2026, the IETF Datatracker identifies draft-ietf-dkim-dkim2-spec-09, dated 1 November, as an active working-group Internet-Draft. Its text intends Standards Track publication and expires on 5 May 2027. Neither intended status nor working-group adoption makes it a published RFC. The companion DNS document is revision 03 dated 2 November; the Best Practices document is revision 01 dated 9 September. They are different documents on different revision schedules.
Divide claims into four evidence classes
Use four labels in an evaluation register. “Published baseline” means an existing specification such as RFC 6376. “Proposed” means a behavior described by a named draft revision. “Reported implementation” identifies an attributed claim about running code, including its scope and limitations. “Unresolved” identifies a question for which the available record does not justify a conclusion. These labels prevent a paragraph from quietly changing from protocol design to product endorsement.
For example, the core -09 draft proposes Message-Instance fields, a signed chain of custody, reversible modification recipes and checks involving SMTP envelope information. These are design statements. An assertion that a particular provider verifies every -09 case would require current provider evidence and actual scoped results. No such receiver-wide assertion follows from an author's employer or an example posted to a standards discussion.
Understand the problem without promising its solution
Classic DKIM lets a domain take responsibility for selected signed material; a valid signature is not a universal statement about content safety or every later delivery. RFC 6376 section 8.6 discusses replay and spam. DKIM2's proposed route information attempts to expose responsibility for onward handling, while its modification history attempts to make earlier message states verifiable. Those mechanisms address related but distinct questions.
The draft's verification state does not judge whether a declared modification was benign. A chain can identify who made a change without making that change desirable. Similarly, repeated-message observations can support replay assessment without proving every duplicate malicious. Evaluators should ask which uncertainty each proposed mechanism reduces and what local policy still must decide. Avoid presenting cryptographic verification as a substitute for reputation, content analysis or abuse controls.
Read the change history as engineering evidence
The revision chronology shows -07 on 18 October, -08 on 27 October and -09 on 1 November. The -09 change log adds the Domain Policy Record and revises domain matching for Authentic From checks. It also changes the no-DKIM2-fields result to NONE and clarifies key-record multiplicity. A test written for an earlier version may therefore have a different expected result without either author having intended the same protocol.
An author's -08 explanation describes changes to ML-DSA-44 use, signature and hash combination logic, and verification terminology. These details make “supports post-quantum DKIM2” too broad a procurement question. Ask which revision, which algorithms and which combination cases were implemented. A dated issue discussion is valuable context, but it is not a permanent statement that every concern was resolved in all later software.
Keep related proposals in their own lanes
The September BCP draft discusses mixed deployments and explicitly leaves DMARC integration open. Current published RFC 9989 identifies its authentication mechanisms; this article does not add DKIM2 to that standard by inference. Likewise, draft feedback flags are not evidence that an existing aggregate-report service understands a new DKIM2 schema.
A separate CanModify proposal, dated 2 November, explores originator requests about permitted changes. It is an individual draft, not an adopted extension that every DKIM2 implementation must already honor. Its presence illustrates an unsettled trust question: recording a modification and assessing whether it was acceptable are different operations. Keep document lineage visible when discussing that distinction.
Attribute implementation reports accurately
The individual Milter deployment profile reports DarkChain and DarkChains as beta implementations of its own profile. Its implementation-status section expressly says contributor-supplied information was not verified and does not imply IETF endorsement. The profile also distinguishes its core and extended functions. That report is useful evidence of claimed experimentation, but it is not proof of full core -09 compatibility or adoption by every system whose traffic passed through the deployment.
A useful next review would identify the exact software commit, compare its declared profile with the pinned WG draft, and choose controlled cases for the differences. Do not install software, publish keys or send test mail merely to fill an empty checklist cell. Those actions require an approved experiment with an owner, boundaries and cleanup requirements.
Leave the remaining claim boundary explicit
The exact commission is: Read the current draft and issue history, then label implemented, proposed and unresolved claims. This draft reviews current primary documents, the core change log and selected author discussions. It does not certify an exhaustive issue-history audit or independently verify an implementation. The accompanying register therefore labels reported code separately and leaves actual compatibility unresolved.
Before publication, the standards reviewer must confirm that the version pins remain current, approve the interpretation and decide whether the selected issue sample is sufficient. Actual implementation acceptance, visual and production-route review, and owner release also remain open. The immediate value is a precise account of work in progress that readers can investigate without mistaking it for a production migration requirement.