DKIM2 draft 08 revises post quantum signing and verification rules
News
The active IETF DKIM working group published DKIM2 draft 08 on October 28, 2026, revising its proposed post-quantum signing scheme and verification rules. Draft 08 replaces the previous composite signature algorithm with pure ML-DSA-44 and specifies how combinations of signatures and hashes produce verification results.
The IETF's revision event records the new revision at 2026-10-28T00:48:59Z. The draft's text and header are dated October 27. This is a material revision of an already adopted working group document, not its first adoption or a final-standard announcement.
A draft revision with no migration mandate
DKIM2 draft 08 is not final, is not an RFC, and is not current production guidance. It creates no migration mandate, provider rollout, or enforced deadline. Publication does not establish deployment support or a quantum safety guarantee.
The immediate audience is MTA developers, mailbox providers, ESPs, forwarders, mailing-list operators, and email security engineers evaluating DKIM2. I'd prioritize compatibility tests in isolated experiments. Ordinary domain owners should keep their current SPF, DKIM, and DMARC healthy.
Production DNS stays unchanged
Do not change production DKIM records or DMARC policy because draft 08 exists. The proposed rules describe experimental DKIM2 behavior, not a replacement configuration that domain owners must publish today.
Pure ML-DSA-44 replaces the composite scheme
Section 3.4 changes the cryptographic construction. Draft 07 specified MLDSA44-Ed25519-SHA512: it hashed the signing inputs with SHA-512, signed that hash using MLDSA-44 and Ed25519, and concatenated the signatures. Draft 08 replaces that construction with pure ML-DSA-44 under the algorithm identifier mldsa44.
The new construction uses ML-DSA.Sign and ML-DSA.Verify directly on the canonicalized Message-Instance and DKIM2-Signature field inputs defined in section 12.8. It does not use HashML-DSA or an extra application-level prehash. Both signing and verification use exactly five ASCII octets as the context: DKIM2, without a terminator.
Illustrative draft 08 signing inputs, not a library-specific APItext
algorithm = "mldsa44" context = bytes([0x44, 0x4B, 0x49, 0x4D, 0x32]) input = canonicalized_fields_per_section_12_8 signature = ML_DSA_Sign(secret_key, input, context) verified = ML_DSA_Verify(public_key, input, signature, context)
An implementation built for the composite scheme needs more than a renamed algorithm string. Keeping the old prehash, concatenated signature format, or an empty context would change the cryptographic operation. I'd test matching and deliberately mismatched contexts before treating two implementations as compatible.
This does not remove the separate hashes that cover the message's other headers and body. Those remain part of Message-Instance processing. The change concerns what enters the ML-DSA signing operation.
Signature and hash groups get explicit AND/OR rules
Sections 9 and 10 define grouping for hashes and signatures. A comma requires every member of a group to pass. A vertical bar separates alternative groups, with any passing group satisfying the pass condition. Commas bind more tightly: A,B|C means (A AND B) OR C.
The draft 08 text connects this syntax to algorithm transitions and hybrid constructions. Separate signatures can require multiple algorithms without restoring the old composite algorithm. These pass conditions are only part of verification; sections 14.6 and 14.7 also define error handling.
Alternative groups
A | B permits either group to satisfy the pass condition. An experimental transition can provide an alternative for verifiers that do not understand a newly introduced algorithm.
Required combinations
A, B requires both members to pass. A hybrid experiment can require a classical signature and a post-quantum signature, each with its own selector.
For signatures, an unsupported algorithm has a PERMERROR intermediate result. A key retrieval problem produces TEMPERROR or PERMERROR, while a mismatching signature produces FAIL. Within an AND group, all passes give PASS; if every non-passing member is TEMPERROR, the group gives TEMPERROR. Otherwise, any FAIL gives FAIL; the remaining outcome is PERMERROR.
Across alternative signature groups, PASS takes precedence, followed by TEMPERROR, then FAIL, and finally PERMERROR. Hash groups have no corresponding key-fetch TEMPERROR branch: an AND group requires all passes, otherwise a mismatch gives FAIL and the remaining outcome is PERMERROR. Across hash alternatives, PASS takes precedence over FAIL, then PERMERROR.
Implementers should preserve these distinctions rather than convert every non-pass to false. A retryable DNS problem and a definitive signature mismatch need different handling. Consistent parsing also prevents two verifiers from interpreting the same transition or hybrid expression differently.
RSA limits and ignored headers also change
Section 3.2 expands the proposed RSA verification range. Draft 07 required support through 2048 bits; draft 08 extends that range through 4096 bits. Signing retains a 1024-bit minimum, recommends at least 2048 bits, and verification explicitly rejects keys below 1024 bits.
These are DKIM2 draft rules, not newly imposed requirements for deployed DKIM1. The 2048-bit signing recommendation already exists in DKIM1 guidance, which the draft acknowledges. Draft 08 does not make every older DKIM key invalid.
|
|
|
|---|---|---|
Signing | 1024 bits | Minimum |
Signing | 2048+ bits | Recommended |
Verification | 1024-4096 bits | Required support |
Verification | Below 1024 bits | Reject |
Verification | Above 4096 bits | Optional support |
RSA requirements proposed in draft 08
The ignored-header list changes too. Auto-Submitted and VBR-Info appeared in draft 07's exclusions but are absent from draft 08's list. They therefore fall under normal header hashing rather than being silently omitted.
For forwarders and mailing lists, carrying the old exclusion list into an updated implementation risks different hash inputs. Regression tests should cover these fields being present initially and being changed by an intermediary.
Verification and DSN clarifications matter for forwarding
Draft 08 renames "Validly Signed DKIM2 Message" to "Fully Verified DKIM2 Message" and clarifies its distinction from Provisionally Verified. Full verification covers the required chain and reconstructed message checks, alongside consistency with the SMTP envelope. A passing last-hop signature alone is insufficient.
Provisional verification is a limited assessment centered on the highest-numbered signature and Message-Instance fields, with envelope and signing-domain checks. It supports initial acceptance before deeper analysis. Provisional verification and Delivery Status Notifications (DSNs) already existed in draft 07; draft 08 clarifies their conditions.
The revised DSN provisions constrain creation and inbound validation to reduce backscatter. A null reverse path prohibits sending a DSN. Creation ties the DSN signing domain to a recipient of the reported message. Inbound checks connect the DSN to the returned message and verify the embedded headers. Failed validation prohibits further propagation.
I'd test that provisional acceptance does not become an unrestricted permission to generate bounces. Forwarding tests should also check that a returned notification exposes only the permitted delivery information and that temporary DNS failures follow the draft's retry handling.
What implementers should test in isolation
Start with a review of the versioned 07-to-08 diff, then update a controlled test environment. A successful local signing test does not demonstrate interoperability with another implementation or establish mailbox-provider support.
The useful test cases exercise failures as deliberately as successes. Record the expected intermediate and final results so changes to parsing or cryptographic inputs are visible.
- Version diff. Review sections 3.2, 3.4, 4, 9, 10, 13, 14.6, 14.7, and 16 against draft 07.
- Signing inputs. Check pure ML-DSA-44, the mldsa44 identifier, canonicalization, and the exact DKIM2 context. Include wrong-context and old-prehash negative tests.
- Group evaluation. Test mixed comma and vertical-bar expressions, unknown algorithms, mismatches, malformed inputs, and temporary key-fetch errors.
- RSA boundaries. Test keys below 1024 bits and at the 1024-, 2048-, and 4096-bit boundaries. Check the implementation's documented behavior above 4096 bits.
- Forwarding and DSNs. Exercise header changes, provisional and full verification, null reverse paths, invalid embedded messages, and rejected notification propagation.
Keep current domain authentication healthy
For domain owners, the operational work remains current authentication. Check that legitimate senders sign correctly and that their messages pass DMARC for the visible From domain. Suped's DKIM checker helps inspect existing selector records; that is separate from testing draft 08.
Suped is our email authentication platform. Its DMARC monitoring helps teams investigate failing sources and confirm fixes. Suped's Hosted DKIM manages existing selector records. These workflows address production authentication without implying DKIM2 support.
Investigate current failures using message evidence and reporting data. Keep experimental DKIM2 keys and test routes separate from production changes, and require specific implementation documentation before planning any deployment.
The next decision is an interoperability test
For teams already evaluating DKIM2, the next decision is whether their isolated implementations produce the same inputs and results under draft 08. Keep test evidence tied to the exact revision. Any later production decision needs separate evidence of implementation support and interoperability, plus a reviewed deployment plan.
Frequently asked questions
No. It is an adopted working group Internet-Draft revision, not an RFC or final standard. Its publication establishes no migration deadline or provider rollout.
The previous composite MLDSA44-Ed25519-SHA512 construction is replaced by pure ML-DSA-44, identified as mldsa44. It signs canonicalized field inputs directly and uses the exact five ASCII octets DKIM2 as its context.
No. A vertical bar separates alternative groups; a comma requires every member within a group. Verification must also preserve the draft's FAIL, TEMPERROR, and PERMERROR handling, rather than treating every non-pass identically.
No. Draft 08 creates no production DNS or policy change requirement. Keep current SPF, DKIM, and DMARC functioning, and leave DKIM2 experiments in isolated environments.
No. Provisional verification checks a limited set of conditions for the latest hop. Full verification requires the broader chain and message checks. Draft 08 clarifies this distinction and the related DSN constraints.
