Build a watchlist rather than a migration promise
Post-quantum DKIM discussions combine several questions that deserve separate answers. Is the cryptographic primitive standardized? Is its use in a particular mail protocol specified in an approved document? Does the deployed verifier understand that format? Has the relevant route been tested? A positive answer to the first question does not settle the remaining three. A useful standards watchlist records each independently and leaves unsupported answers explicitly unknown.
This guide reviewed public primary sources on 8 November 2026. The DKIM2 specification record showed revision 09, updated 1 November, as an active working-group Internet-Draft. The Post-Quantum Cryptography in DKIM record showed revision 00, updated 2 November, as an active individual Internet-Draft. The latter record expressly distinguishes individual submission from IETF endorsement. Neither record establishes an approved production migration.
Separate established DKIM guidance from proposed formats
RFC 8301 prohibits rsa-sha1 for signing and verification. Its RSA guidance requires at least 1024-bit signing keys and recommends at least 2048 bits; shorter-than-1024-bit RSA signatures must not be considered valid. RFC 8463 adds Ed25519-SHA256 and specifies verifier support. These published requirements are distinct from an observation that a particular installed product actually complies with them.
The PQ-DKIM1 draft discusses quantum-resistant signature options for the existing DKIM version. DKIM2 is a separate protocol-development effort with its own proposed signed material and syntax. In revision 09, its cryptographic section includes ML-DSA-44 and specifies pure ML-DSA for that use. Do not interchange a DKIM1 proposal's algorithm labels or examples with the DKIM2 draft merely because both discuss a similar mathematical family. Copying a proposed key into DNS would not resolve those differences.
Check the primitive without claiming a mail deployment
NIST FIPS 204 was published on 13 August 2024 and specifies ML-DSA. The publication page also carries a 31 July 2026 potential-updates notice. That establishes a cryptographic standard and a maintenance consideration; it does not establish that a given DKIM binding, implementation or hosted email service has been approved or tested. This guide does not review implementation correctness or the contents of that errata spreadsheet.
The threat discussion concerns signature forgery, not turning DKIM into encryption. DKIM's published model associates a signing domain with a signature over selected message material. A new signature algorithm would not itself conceal the message, authorize a business request, or establish the identity of a human correspondent. Keep confidentiality, authentication, domain alignment and content safety separate when explaining why a future algorithm might matter.
Make size and transport questions measurable
A larger key raises more than one operational question. Distinguish the public-key bytes, encoded TXT content, complete DNS response, signature bytes and resulting message-header size. A TXT character-string limit is not the maximum size of an entire record or DNS message. Conversely, support for multiple strings does not prove every DNS path, provisioning interface or mail parser will handle the intended response. DNS's record format is only part of that investigation.
Propose measurements rather than importing benchmark conclusions into the organisation's environment. Record the resolver and authoritative software, transport behavior, message-size constraints, signing workload and verification workload. Include malformed and unsupported inputs, not only a convenient valid example. Any throughput or latency statement needs a reproducible test setup and actual results. No numerical performance result, key publication, message generation or verifier execution is claimed here.
Define what demonstrated support would mean
For a fictional laboratory matrix, assign a row to each signer/verifier version pair and each intermediary transformation. The row should name the precise draft revision, algorithm representation, expected behavior and evidence still needed. Planned cases might include an intact signature, modified signed content, an unknown algorithm and an unavailable key. Label every result unexecuted until an authorized test produces an inspectable record. Do not fill unknown cells from a vendor's general statement about post-quantum readiness.
Compatibility also needs a policy question. If multiple signatures are present, what combination does the proposed protocol require, and what will an older receiver actually evaluate? A valid conventional signature does not demonstrate that a PQ signature was checked. An ignored new header is not successful new-protocol verification. Future transition plans should preserve an approved authentication path while explicitly testing downgrade and mixed-support behavior, rather than assuming that dual publication is automatically safe.
Keep commissioning and change approval open
The catalogue requires: “Compare current algorithm guidance, draft status and demonstrated verifier support.” This article compares the first two from retained documentary sources. Demonstrated verifier support remains absent, so the full commissioning requirement stays open. A review checklist is not a working implementation, and a draft example is not evidence that EmailAuth or another product implements the proposal. No secret keys, user messages, customer domains or credentials were used.
Assign one owner to standards changes and another to product and laboratory evidence. Recheck the draft revision, publication state, registry relationships and relevant provider documentation before recommending action. Record any source correction or incompatible revision as a reason to revisit assumptions. Production DNS changes, credential operations, message tests and external disclosure require their own explicit authorization. Until that evidence exists, the defensible output is a dated watchlist with named uncertainties, not a promised upgrade date.