IETF DKIM working group publishes first DKIM2 best practices draft
News
Published 19 Jun 2026
Updated 20 Aug 2026
9 min read
Summarize with
Updated on 20 Aug 2026: We updated this guide with the current DKIM2 draft set and clarified what revision 00 recommends without turning draft text into production advice.
On 18 June 2026, the IETF DKIM working group published draft-ietf-dkim-dkim2-bcp-00, its first working group draft for DKIM2 best practices. The IETF Datatracker page lists revision 00 as an active Internet-Draft and a DKIM working group document. Its latest revision remains dated 18 June, while the Datatracker record was last updated on 2 July.
Revision 00 remains standards work in progress. It is not an RFC, has not reached working group last call or IESG submission, and has not created a deployed mailbox provider requirement. It is a signal about possible DKIM2 operating guidance, not a migration deadline.
- What changed: The DKIM working group now has its first draft of recommended DKIM2 behavior for sending hosts, intermediaries, and receiving hosts.
- What did not change: Production mail still depends on healthy DKIM, SPF, DMARC, and sender controls. DKIM2 is not a compliance checkbox.
- Why it matters: DKIM2 targets forwarding breakage, message modification, DKIM replay, and delivery status notifications sent to uninvolved parties.
- Who should track it: Mailbox providers, ESPs, forwarders, mailing list operators, security teams, and deliverability teams should follow the work.
- What to do now: Keep current DKIM healthy, monitor DMARC reports, maintain a sender inventory, and track later DKIM2 revisions.
Draft status
The best-practices document remains revision 00. The working group's active set also includes draft-ietf-dkim-dkim2-spec-04, dated 5 July 2026, and draft-ietf-dkim-dkim2-dns-00, dated 20 July 2026. All three are Internet-Drafts with IESG state 'I-D Exists', not RFCs.
What changed on 18 June 2026
DKIM2 did not become mandatory on 18 June. The working group adopted a first draft that turns protocol ideas into proposed operating behavior for the organizations that handle email. The draft still contains placeholders and unresolved questions, so its recommendations need to be read as proposals.
The draft separates mail handling into sending hosts, intermediary hosts, and receiving hosts. That framing matters because DKIM2 covers what happens after a message leaves the sender's domain, including a forwarder or mailing list changing content or sending the message through another administrative domain.
|
|
|
|---|---|---|
Sending hosts | Sign outgoing mail | Sign at domain exit and maintain keys. |
Intermediaries | Verify and document handling | Record forwarding or revision behavior. |
Receivers | Validate the chain | Assess signatures, message instances, and paths. |
Domain owners | Maintain current authentication | Keep production DKIM and DMARC observable. |
Scope of the first DKIM2 best practices working group draft.
DKIM1 verifies that a domain signed selected message content and that the signed content still matches. In the current DKIM2 specification, each handling domain can add a DKIM2-Signature, while Message-Instance fields can describe message states and reversible changes. A receiver can then validate a chain instead of relying only on the origin signature.
Flowchart showing a DKIM2 path through sender, forwarder, change recording, receiver validation, and reporting.
Why DKIM2 matters for DKIM and DMARC
Current authentication has failure modes that appear in legitimate mail. SPF often fails after forwarding because the final receiver sees an intermediary's IP address. DKIM fails when a mailing list or gateway changes signed content. DMARC can then fail when neither SPF nor DKIM produces an aligned pass.
DKIM2 proposes a signed chain of custody. The current specification binds signatures to hop information, including envelope sender and recipient data in relevant signatures, and uses Message-Instance records for documented changes. Those mechanisms target DKIM replay, forwarded-message breakage, and unsafe delivery status notifications.
Current pain
- Forwarding: SPF often fails because the final receiver sees the forwarder's IP, not the original sender's IP.
- Mailing lists: Subject tags, footers, or rewritten headers can invalidate DKIM signatures.
- Replay: A valid DKIM signature can be reused in abusive deliveries that the signer did not intend.
- Bounces: A delivery notification can go to a spoofed envelope address rather than a party in the delivery path.
DKIM2 direction
- Custody: Each handling domain can add a signed record to the message path.
- Revision: Intermediaries can document changes so a verifier can reconstruct an earlier message instance.
- Recipient binding: Envelope data gives receivers context for detecting unexpected reuse.
- Safer DSNs: Delivery status notifications can follow parties documented in the custody chain.
For DMARC, the immediate issue is continuity. DMARC monitoring shows how current mail authenticates. DKIM2 does not remove the need to identify sending sources, fix broken signatures, review alignment, and change DMARC policy carefully.
What the draft recommends if DKIM2 is deployed
Revision 00 describes behavior for a future DKIM2 deployment. These statements are draft recommendations, not instructions for current production systems. The distinction matters because the companion specification has already changed across several revisions.
- Dual signing: The draft recommends DKIM1 and DKIM2 signatures during a gradual transition, so receivers without DKIM2 support retain DKIM1.
- Sign on exit: A sending administrative domain applies its DKIM2 signature at the final hop before the message leaves its infrastructure.
- Intermediary handling: Forwarders attempt verification and add a signature even when they relay a message without changing it.
- Algorithm support: The draft discusses RSA-SHA256 and Ed25519-SHA256, with multiple signatures proposed for interoperability.
- Key management: Keys still need rotation, selector control, and protection of the private signing material.
No new DNS migration today
The current best-practices draft says DKIM2 keys use the existing selector._domainkey naming space and are stored in the same locations as DKIM1 keys. That draft detail does not require domain owners to publish a new DKIM2 record now.
What not to change today
Do not redesign production mail architecture because revision 00 exists. It has not created a new requirement for senders, receivers, forwarders, or domain owners.
No immediate migration
- Production mail: Keep DKIM1 signing in place and use signing domains you control.
- DMARC policy: Do not change policy because of DKIM2 alone. Base enforcement on authenticated source data.
- Forwarders: Do not assume receivers validate DKIM2-Signature or Message-Instance fields in production.
- Compliance: Do not treat DKIM2 as a current pass or fail requirement in vendor reviews.
The production baseline remains valid SPF, reliable DKIM signing, DMARC aggregate reporting, investigation of unauthenticated sources, and enforcement only after legitimate traffic is accounted for.
Current production DNS baselinedns
selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=BASE64PUBLICKEY" _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
The best-practices draft still contains discussion notes and unresolved material, including privacy questions around change records and open treatment of DMARC or SPF. Those gaps are evidence that production assumptions would be premature.
Practical next steps for senders
Current authentication should be predictable and observable before DKIM2 testing becomes relevant. The same problems named by the draft already appear in reports today, including broken signatures, forwarding failures, unauthorized sources, and domain misalignment.
- Controlled domains: Sign production mail with domains you own or operate, rather than opaque shared domains that hide accountability.
- Record validation: Check selectors, public keys, and syntax with the DKIM checker before treating a sender as healthy.
- Report review: Review aggregate reports to identify sources that pass or fail authentication and DMARC alignment.
- Key rotation: Rotate DKIM keys on a documented schedule and use an appropriate DKIM key length for your mail stack.
- Selector planning: Understand double signing before overlapping selectors during a staged key change.
- Standards watch: Track the best-practices, specification, and DNS drafts, but tie production changes to stable documents and deployed support.
Before planning a protocol pilot, run the domain through the domain health checker and fix current DKIM, SPF, DMARC, or DNS errors. DKIM2 cannot compensate for malformed records or unauthenticated production sources.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Build a source inventory that includes corporate mail, billing systems, support tools, product notifications, marketing sends, and infrastructure alerts. Record the owner, signing domain, selector, and expected alignment for each source.
How to watch DKIM2 without overreacting
Separate current mail hygiene from DKIM2 standards tracking. One workstream fixes deployed authentication. The other watches draft revisions, receiver support, and implementation experience.
DKIM2 action priority
A practical way to separate current work from future standards tracking.
Do now
Production
Fix current DKIM, SPF, and DMARC failures.
Track now
Standards
Watch DKIM2 drafts and working group progress.
Test later
Pilot
Evaluate implementations after stable support exists.
Do not do
Premature
Treat DKIM2 as a current provider requirement.
Suped is our DMARC and email authentication product. It supports the operational workstream by turning aggregate reports into a sender inventory, showing DKIM and SPF alignment by source, and helping teams investigate current authentication failures while DKIM2 remains draft work.
During a standards transition, the useful operational questions remain concrete: which sources send mail, which domain signs it, whether alignment passes, and who owns the fix when it fails.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
A dashboard like this separates current defects from draft protocol questions. Fix selectors or signing configuration when DKIM fails today. Document forwarded paths when alignment breaks. If DKIM2 gains stable support later, the same inventory will identify suitable pilot traffic.
Who should pay attention
The draft is most relevant to organizations that operate mail infrastructure or handle forwarded and modified messages at scale. A typical domain owner does not need to implement DKIM2 today, but infrastructure operators should track the proposed signing and verification behavior.
|
|
|
|---|---|---|
Mailbox providers | Receiver validation | Track verifier design. |
ESPs | Sender signing | Keep DKIM reliable. |
Forwarders | Path and envelope changes | Review handling rules. |
Mailing lists | Content revisions | Document common modifications. |
Security teams | Replay risk | Watch abuse patterns. |
Deliverability teams | Authentication failures | Use report data. |
Teams affected by the DKIM2 best practices draft.
For smaller sending teams, keep a clean source inventory and treat current DKIM failures as production defects. A vendor sending for your domain should use a signing domain that supports the intended DMARC alignment plan.
What to do now
Put DKIM2 on the standards watch list and keep current DKIM health on the operational work list. Revision 00 does not justify emergency DNS, procurement, or production changes.
- Today: Audit current DKIM records and confirm that important sources sign correctly.
- Next review: Use DMARC aggregate reports to separate forwarding failures from unauthorized sources.
- Ongoing: Document selector ownership and key rotation practices.
- Later: Reassess DKIM2 when the best-practices draft matures and deployed support exists.
