IETF DKIM working group publishes first DKIM2 best practices draft
News
Published 19 Jun 2026
Updated 24 Oct 2026
9 min read
Summarize with
Updated on 24 Oct 2026: We updated the DKIM2 draft revisions and clarified DNS compatibility and differences between the current drafts.
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 now lists revision 01, published on 9 September 2026, as the active working group draft. Revision 00 is the original June publication, rather than the latest text.
The latest draft remains standards work in progress. It is not an RFC and has IESG state 'I-D Exists'. The draft does not establish a production deployment requirement or migration deadline.
- What changed: The June publication introduced proposed DKIM2 behavior for sending hosts, intermediaries, and receiving hosts. Revision 01 expands that operational guidance.
- 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 active documents are draft-ietf-dkim-dkim2-bcp-01 (9 September 2026), draft-ietf-dkim-dkim2-spec-07 (18 October 2026), and draft-ietf-dkim-dkim2-dns-02 (21 October 2026). Each remains an Internet-Draft with IESG state 'I-D Exists'. The BCP draft's intended status is Best Current Practice, which is not an approved BCP designation.
What changed on 18 June 2026
DKIM2 did not become mandatory on 18 June. The working group published its first best-practices 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. |
Draft roles and related production responsibilities for domain owners.
DKIM (DomainKeys Identified Mail), called DKIM1 in these drafts, 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.
DKIM2 email authentication flow with signing, forwarding, recorded message changes, receiver verification, and delivery 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. Receivers still need reputation and content checks after a DKIM2 pass.
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 01 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. Later specification revisions add SHA-512 variants and MLDSA44-Ed25519-SHA512.
- Key management: Publish new keys under new selectors and retain the old public keys while previously signed messages remain in transit. Protect the private signing material.
Read the draft revisions together
The September best-practices draft still discusses donotmodify and donotexplode request flags. The October main specification removes both. Check companion revisions before testing; not every recommendation in revision 01 describes the latest protocol behavior.
How DKIM2 uses existing DNS key records
The DNS specification retains the existing selector._domainkey.domain namespace and the public-key record version v=DKIM1. Publishing v=DKIM2 would create an invalid key record under the current draft.
For d=example.com and s=mail2026, the lookup name is mail2026._domainkey.example.com. Each selector name has one public-key TXT record; split strings inside that record are concatenated without spaces.
Sharing a DNS namespace does not give DKIM1 receivers DKIM2 support. Dual signing keeps existing DKIM verification available during a gradual transition; no DNS migration is required by this draft.
What not to change today
Do not redesign production mail architecture because a DKIM2 draft 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.
Illustrative DKIM and DMARC DNS recordsdns
selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=BASE64PUBLICKEY" _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Replace example.com and BASE64PUBLICKEY with your actual domain and public key. The DMARC value p=none requests monitoring without asking receivers to quarantine or reject DMARC failures; it is not an enforcement policy.
The best-practices draft still has unresolved DMARC and SPF sections. It also warns that message change records can expose removed content and that envelope recipients need privacy protection. Those issues need review before production assumptions are made.
Practical next steps for senders
Current authentication should remain predictable and observable during any DKIM2 evaluation. 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. A DNS lookup confirms key publication; inspect received message headers to confirm that signatures verify.
- 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: Publish a new selector before switching signing and keep the old public key available for mail in transit. Use double signing when overlapping signatures are needed 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 track DKIM2 alongside production authentication
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 an Internet-Draft as a provider deployment 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 track DKIM2
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.
Frequently asked questions
No. Revision 00 is the original June Internet-Draft. Revision 01, published on 9 September 2026, is the active revision and has IESG state 'I-D Exists'. Neither revision is an RFC.
No. Keep DKIM1 signing in production, maintain SPF and DMARC, and monitor authentication results. The draft establishes no deployment deadline.
The DNS draft retains the existing selector._domainkey namespace and v=DKIM1 key-record version. It does not require a DNS migration or a v=DKIM2 record. DKIM2 still needs compatible signing and verification software.
DKIM2 targets forwarding breakage, documented message changes, replayed signatures, recipient binding, and safer delivery status notifications.
No. DMARC remains the deployed reporting and policy mechanism for From-domain authentication. The best-practices draft still has open text about DKIM2 interoperability with DMARC.
The active working group documents are best practices revision 01 (9 September 2026), main specification revision 07 (18 October 2026), and DNS specification revision 02 (21 October 2026). All remain Internet-Drafts.
