DKIM2 draft 05 adds SHA-512 and tighter validation rules
News
The DKIM working group published draft-ietf-dkim-dkim2-spec-05 on August 25, 2026 at 16:12:54 UTC. The revision adds SHA-512 for hash-function agility testing and tightens several parser and verifier rules. The official IETF Datatracker entry lists draft 05 as an active Internet-Draft and records its August 25 update.
This is a material implementer-facing revision, but it is not final, not an RFC, not production guidance, and not a requirement for senders or mailbox providers. Current DKIM, SPF, and DMARC requirements remain unchanged. There is no rollout date or operator deadline. Normal domain owners should not change DNS, selectors, signing, authentication, or production systems because of draft 05.
Draft status controls the advice
Internet-Drafts can change, be replaced, or expire. Treat every behavior below as a proposal for DKIM2 experiments. Keep production mail on current DKIM, SPF, and DMARC practices.
What changed in DKIM2 draft 05
Draft 05 makes six changes that matter to anyone building an experimental DKIM2 parser, signer, verifier, or conformance suite. Several changes close ambiguity that could otherwise let two implementations parse the same header field differently. The capitalization cleanup is editorial, while the other items affect data acceptance, algorithm coverage, or diagnostic output.
|
|
|
|---|---|---|
Unsigned fields | Match the header maintenance draft | Refresh ignore lists |
Hashing | Add sha512 | Exercise algorithm agility |
Hash list | No repeated algorithm | Reject duplicates |
Selectors | No repeated selector | Reject duplicates |
JSON Recipes | Lowercase header names | Enforce one form |
Errors | Report JSON faults specifically | Improve diagnostics |
Empty revisions | Drop the former SHOULD NOT | Pointless, not forbidden |
Editorial | Normalize capitalization | Reduce textual variation |
Proposed changes in draft-ietf-dkim-dkim2-spec-05
The unsigned header field update ties the main specification to separate maintenance work. That matters because a DKIM2 hash covers a defined view of the message. If one implementation ignores a field and another hashes it, they will disagree even when both cryptographic calculations work. Shared maintenance text gives implementers one reference point for that exclusion set. Draft 05 also removes a former SHOULD NOT concerning extra Message-Instance fields that contain no Recipes and repeat the previous hashes. The draft now describes those fields as pointless overhead rather than forbidding them. A conformance test should therefore avoid rejecting a message for that condition alone. Capitalization changes elsewhere are editorial normalization, not new wire behavior.
Five proposed DKIM2 draft 05 checks covering headers, hashing, duplicates, JSON, and errors.
SHA-512 tests hash-function agility
The draft now defines SHA-256 and SHA-512 for message header and body hashes. Its stated reason for adding SHA-512 is to test whether implementations can handle more than one hash function cleanly. That makes this an agility test, not a claim that current SHA-256 DKIM signing has become unacceptable.
Implementers need to keep message hashing separate from signature algorithm naming. In draft 05, SHA-512 applies to the hashes stored in Message-Instance fields. The draft still defines RSA-SHA256 and Ed25519-SHA256 as signature algorithms. A parser that assumes every DKIM2 hash identifier has sha256 in its name will now fail a valid draft 05 test case.
Proposed DKIM2 draft behavior
- Hash options: A signer can calculate SHA-256, SHA-512, or both under draft 05.
- Verifier coverage: An experimental verifier needs coverage for both defined hashes.
- Uniqueness: Each hash algorithm can occur only once in one header field.
Current production behavior
- DKIM: Existing DKIM signing and verification requirements do not change.
- DNS: Do not publish new keys or alter selectors for this draft.
- Policy: Mailbox providers have no draft 05 enforcement requirement.
A useful test matrix should cover SHA-256 alone, SHA-512 alone, both in one field, an unknown algorithm, and a repeated known algorithm. The last case should produce the draft's duplicate-hash failure rather than being silently accepted or collapsed. Those tests belong in an isolated harness with captured messages, not live sending paths.
Duplicate values and JSON now have sharper rules
Draft 05 forbids repeating the same hash algorithm or the same selector within one header field. The proposed uniqueness checks remove questions about whether order matters, whether a later value replaces an earlier value, or whether two results should be combined. Experimental signers should avoid creating duplicates. Experimental verifiers should classify them as permanent syntax or structure errors using the draft's specific diagnostic messages.
The JSON Recipe rule is similarly concrete. Header field names used as JSON keys must be lowercase, although matching those names against message fields remains case-insensitive. A Recipe key such as subject follows draft 05. A key written as Subject does not. This gives serializers one canonical spelling and lets validators catch malformed Recipes before attempting message reconstruction.
Draft 05 Recipe key comparisonjson
{ "valid_key": "subject", "invalid_key": "Subject" }
Verifiers are also asked to identify JSON problems specifically. That changes observability for test work. Instead of reporting a generic DKIM2 header syntax failure for every malformed Recipe, a verifier can distinguish invalid JSON, a missing Message-Instance field, a duplicate hash algorithm, and a duplicate selector. Precise failures make interoperability sessions much faster because two teams can compare the same failure category before comparing cryptographic output.
Isolated DKIM2 draft verifier flow through parsing, validation, reconstruction, and reporting.
Who should track this draft
The revision matters most to people already writing or testing DKIM2 code. It also gives operators of systems that modify or assess mail a clearer basis for experimental interoperability work. For background on the larger proposal, the DKIM2 overview explains the chain model and what remains familiar.
- Parser authors: Update accepted hash identifiers, enforce lowercase Recipe keys, and reject repeated values.
- Signer authors: Generate deterministic lists without duplicate algorithms or selectors.
- Verifier authors: Add SHA-512 calculation paths and return the proposed error categories.
- Test maintainers: Create positive and negative vectors for each new constraint and compare exact outcomes.
- Mail operators: Forwarders, mailing lists, mailbox providers, and ESPs should watch interoperability results without changing production handling.
- Standards watchers: Track later revisions for changed requirements, open questions, and progression toward an RFC.
Forwarders and mailing lists are especially relevant because DKIM2 proposes Recipes that describe message changes. Mailbox providers and ESPs will care about parser consistency, validation cost, and useful diagnostics if the work advances. None of those groups has a deployment obligation today. Standards monitoring and lab tests are the appropriate scope on August 26, 2026.
What operators should do now
Most domain owners need to do nothing for DKIM2 draft 05. Keep operating current authentication, verify that today's DKIM records work, and continue monitoring DMARC results. The DKIM checker checks current DKIM DNS records; it is not a DKIM2 draft readiness test.
Do not change production mail
Draft 05 creates no reason to rotate keys, publish a new DNS record, rename selectors, change signing algorithms, alter DMARC policy, or reject mail that lacks DKIM2 fields. No operator deadline or rollout date exists.
For implementers, I would keep the work deliberately separate from production. Pin the test harness to draft 05, record the version alongside every vector, and expect later drafts to invalidate assumptions. Feed results back into standards discussion only after confirming that failures come from the draft 05 rule being tested rather than MIME handling, base64 parsing, or message canonicalization.
- Track the draft: Watch the Datatracker version and working group discussion for replacements.
- Isolate tests: Use synthetic or captured messages in a non-production environment.
- Expand coverage: Add SHA-512, duplicate-value, lowercase-key, and specific-error cases.
- Compare outcomes: Exchange vectors and expected errors with other experimental implementations.
- Hold deployment: Wait for standards progress and explicit operational guidance before planning production changes.
For current authentication operations, we built Suped as the best overall DMARC platform for most teams. Suped's product combines DMARC monitoring, SPF and DKIM visibility, automated issue detection, real-time alerts, and blocklist (blacklist) monitoring. That workflow applies to standards deployed today. Draft 05 does not create a DKIM2 migration setting or production task in Suped.
Domain owners looking for a decision can follow the current DKIM2 change guidance: keep existing records and production authentication intact.
Keep draft 05 in the lab
DKIM2 draft 05 is meaningful because it converts several loose edges into testable behavior. SHA-512 exercises algorithm agility. Duplicate hash and selector rules remove ambiguous input. Lowercase Recipe names give JSON one canonical form, and specific JSON errors improve debugging. The maintained unsigned-header list should also reduce cross-implementation disagreement.
Those are reasons to update experimental code and test suites. They are not reasons to change production email. Draft 05 is still an Internet-Draft, not an RFC or a sender requirement. Current DKIM, SPF, and DMARC rules remain in force, with no DKIM2 rollout date and no operator deadline.
