Track the DNS proposal without creating a migration mandate
An administrator assessing DKIM2 needs a precise record inventory, not a new TXT value copied from a headline. DNS mistakes can affect existing signing even when the intended change is only experimental. Begin by separating selector public keys, the proposed Domain Policy Record and existing DMARC policy. They occupy different names and answer different questions; “the DKIM2 record” is too imprecise for a change request.
The current source is draft-ietf-dkim-dkim2-dns-03, dated 2 November 2026. It is an active WG Internet-Draft intended for Standards Track publication. Its proposed update to RFC 6376 is conditional on approval, not an already completed replacement of deployed DKIM rules. Pair it with core spec-09 dated 1 November, and retain both revisions when reviewing an implementation.
Identify selector-key names before policy names
DNS-03 section 3 keeps selector keys beneath _domainkey. In a fictional isolated domain lab.cedar.example, selector s01 therefore identifies s01._domainkey.lab.cedar.example. The key is held in a TXT resource record. Multiple character strings inside that one record are concatenated without added whitespace; that is different from publishing multiple competing key records at the same owner name.
The draft filters records beginning with another v value and treats more than one remaining record as an error. Administrators should preserve the complete record set, not just the first TXT string their management interface displays. A selector can support rotation or delegated signing, so identify any existing consumers before choosing an experimental name. The illustration here contains no generated key and authorizes no publication.
Key type and encoding deserve their own review. DNS-03 describes rsa, ed25519 and mldsa44 for their specified uses, with the latter tied to the proposed DKIM2 mechanism rather than defined classic-DKIM use. The draft also clarifies RSA public-key encodings and proposes deprecating several older tags. A draft's requested registry changes are not evidence that every verifier accepts those changes today.
Read the Domain Policy Record narrowly
The proposed Domain Policy Record is at _domainkey.lab.cedar.example itself, not at a selector and not at _dmarc.lab.cedar.example. DNS-03 section 5 requires its first tag to be v=DKIM1. Despite the proposal's name, inventing v=DKIM2 would not match that pinned syntax. A documentary illustration is v=DKIM1;f=strict, but it is not a paste-ready instruction or an approved production value.
The strict flag concerns whether subdomains can make a From field using the record's domain Authentic under the draft's matching rules. It is not the same as DMARC p=reject, and it is not DMARC's strict-alignment tag. When the flag or record is absent, the proposal permits the described subdomain authorization. The policy applies only at its own domain; it does not inherit upward or downward through the DNS tree.
Core -09 section 3.8 distinguishes temporary retrieval failure from an absent policy and identifies a multiple-record error. A lab should preserve those states separately. Treating a timeout as “no restriction published” would erase information the proposed evaluator needs. Do not substitute DMARC tree-walking behavior for this different policy lookup.
Review the revision, not an old discussion snippet
Earlier sender-policy discussion considers auth= signaling and mixed deployments. That is useful history, not the syntax of the DNS-03 Domain Policy Record. An administrator should keep a change matrix showing the source document, revision, owner name, tag and expected consumer. This prevents examples from separate proposals being combined into a record no implementation actually expects.
There is also an explicit source-quality issue to resolve: DNS-03 section 4.6's service-type prose uses an underscore where its ABNF lists an asterisk wildcard. Do not silently normalize that discrepancy or present copied syntax as settled. Retain the exact conflict for specialist review and implementation comparison. Standards work in progress can contain such inconsistencies; a careful guide should expose them before a change reaches an authoritative zone.
Scope an experiment and its removal together
The NIST SP 800-81 Revision 3 publication record identifies March 2026 DNS deployment guidance and notes potential updates. It supports treating DNS as security-sensitive infrastructure, but it is not a DKIM2 endorsement or evidence that this particular experiment is compliant. The detailed guide and its errata were not reviewed for clause-level claims here.
An approved experiment should use a designated isolated namespace, separate keys and an explicit owner. Record the exact proposed values, TTLs, affected consumers, implementation version and rollback prerequisites before execution. Protect private keys outside the article and evidence bundle. Baseline records and delegation arrangements should remain identifiable so that a cleanup step cannot accidentally remove an existing service's key.
Define removal evidence before creating anything: which experimental records and signing configuration will be retired, who verifies authoritative state, which caches may retain earlier data, and how residual messages are handled. Deletion at an authoritative server is not proof that every cached answer disappears immediately. No keys, records, delegation or accounts were changed during preparation of this article.
Preserve the compatible-build gate
The exact commission is: Pin draft syntax and a compatible test implementation; isolate the experiment and document removal. The syntax is pinned, but a compatible tested build has not been established. The individual deployment-profile draft reports beta code for its own profile and warns that contributor information is unverified. That is not sufficient to certify compatibility with core -09 and DNS-03.
The commissioning gate remains open for implementation pinning, authorized execution and verified removal. Technical acceptance, existing-consumer impact, production-route checks, visual review and owner publication approval also remain pending. The useful deliverable is a bounded review and experiment plan, with current draft syntax clearly separated from any claim that administrators must deploy it.