In March 2026, during an internal routing test, a deliverability team of a European ESP discovers that their emails to Mailman mailing lists consistently fail DKIM checks, despite correctly configured keys. The message is legitimate, the domain is clean, the list is opt-in. But Mailman rewrote the From header, causing the DKIM1 signature to break at that moment. DKIM2 aims to fix this type of breakage. The IETF dkim working group adopted the initial drafts of the protocol in March 2026: not yet an RFC, zero production deployment, but an architecture that distributes verification throughout the delivery path.
Why DKIM1 Reaches its Limits in 2026
DKIM1, formalized in RFC 6376 in 2011, covers a specific scope: it proves that the signing domain indeed sent the original message. The specification does not survive intermediaries. Any server altering the message can invalidate the signature: a mailing list adding a footer, a security gateway rewriting URLs, a forwarder modifying the SMTP envelope. With DKIM adoption nearing 90% for direct emails in 2026, one might think the problem is solved. However, this rate measures success on emails that go directly, not those transiting through mailing lists or forwarders.
The IETF draft draft-ietf-dkim-dkim2-motivation documents three structural weaknesses that DKIM1 cannot fix. First: a validly signed email can be received without any proof that the recipient was the intended recipient. Second: the bounce address can reference domains that played no role in the message’s transit. Third: there is no mechanism to document legitimate modifications by forwarders or mailing lists. These gaps stem from the original protocol design, not configuration errors.
Since 2024, Google and Yahoo have mandated SPF, DKIM, and DMARC for bulk mailings. This pressure has accelerated adoption without resolving architectural problems. The work has been delegated to the IETF dkim WG, operating on several complementary drafts: main specification, motivation document, deployment profile via Milter interface, and a best practices guide.
The Chain of Signatures: Surviving Intermediaries
The central mechanism of DKIM2 is called the chain of signatures. Instead of asking each server to validate a single origin signature, the protocol requires each intermediary to document the changes it has made and sign this documentation. The final recipient thus reconstructs the entire sequence of transformations and verifies the legitimacy of each one.
Richard Clayton, co-author of the DKIM2 specification, describes this approach as a “modification algebra”: intermediaries specify the exact nature of their modifications instead of simply stamping an acceptance. A mailing list adding a footer declares it in its signature. A security gateway rewriting URLs does the same. The recipient then assesses whether each transformation was expected and authorized.
In practice, false positives related to mailing lists, currently a frequent source of DKIM1 invalidation, fall outside the sender’s responsibility. Clayton indicated in April 2026 that functional code already exists and tests with mailbox providers are expected in the coming months. The main technical specification (draft-ietf-dkim-dkim2-spec-01) is dated April 20, 2026.
Asynchronous DSNs and VERP: Ending Backscatter
The second technical angle of DKIM2 tackles a less visible but costly issue for sender reputation: backscatter. When a spammer forges the return address with an innocent third party’s domain, bounces generated by legitimate servers fall into that innocent’s mailbox. Clean IPs and domains end up on blacklists because of traffic they never emitted.
Steve Atkins from Word to the Wise, who has been monitoring the issue for several weeks, notes that DKIM2 resolves this problem through two combined mechanisms. Asynchronous Delivery Status Notifications (DSNs) allow a server to accept a message over SMTP and then notify the failure later, after a full analysis. VERP (Variable Envelope Return Path) encodes necessary metadata directly in the return address, thus avoiding parsing the bounce body. The combination of both, according to Word to the Wise on April 27, 2026, allows for recording the bounce immediately and ignoring the asynchronous DSN without any additional processing or storage.
For deliverability managers, bounces in DKIM2 travel a cryptographically signed path, returning to the previous server in the chain rather than to a forged address. Backscatter loses its main attack surface. Atkins warns that the volumes of asynchronous bounces could increase by several orders of magnitude during the initial deployment. An increase in inbound capacity will be necessary on the ESP side.
Anti-replay: Timestamps and Recipient Binding
DKIM1 presents a known but underestimated vulnerability: the replay attack. A valid DKIM signature can be reused to send the same message to unintended recipients. The attacker retrieves a legitimate email, retains its intact signature, and redistributes it on a massive scale. Anti-spam filters see a valid signature and let it through.
DKIM2 closes this window through two complementary mechanisms. Signatures now include data from the SMTP envelope: sender and recipient. A message signed for alice@example.com cannot be sent again to bob@example.com without invalidating the signature. Flags also control the authorized distribution of the message. This recipient binding mechanism, as noted by Al Iverson of SpamResource (who follows the IETF DKIM WG’s work), could alter the attack surface of the most sophisticated spam campaigns.
Timestamps complete the setup. A DKIM2 signature has explicit temporal validity, preventing the reuse of an old legitimate message in a malicious campaign. Iverson notes that the DKIM keys themselves do not necessarily change with DKIM2. Senders might not have to make any significant changes on the DNS side. The verification infrastructure and the chain of signatures evolve, not the senders’ configuration.
What DKIM2 Does Not Replace: List Quality
DKIM2 secures the delivery path without altering the quality of recipients. A signature that survives intermediaries, bounces cryptographically routed, and replay protection assumes that destination addresses are valid and engaged. On a list with 20% invalid or inactive addresses, DKIM2 does not improve the inbox rate. It better authenticates emails that filters will continue to reject for other reasons.
Public deliverability benchmarks published by major routers converge on this point: inbox rates vary more based on list engagement quality than on authentication parameters alone. DKIM2 enhances the authentication layer without compensating for a poorly maintained list. Address verification before sending remains the prerequisite of any deliverability pipeline. The protocol secures the path once recipients are validated, never upstream.
DKIM1 vs DKIM2: Key Criteria Comparison
| Criteria | DKIM1 (RFC 6376) | DKIM2 (draft IETF 2026) |
|---|---|---|
| Resistance to Intermediaries | None: any modification invalidates the signature | Chain of signatures: each intermediary documents its changes |
| Anti-replay Protection | Absent: a valid signature is reusable | Recipient binding + timestamps: signature tied to recipient and a time window |
| Handling of Bounces | Non-cryptographic asynchronous bounces, backscatter possible | Async DSN + signed VERP: returns to the previous server in the chain |
| Mailing Lists and Forwarders | Systematic signature breakage | Documented modifications via modification algebra, signature maintained |
| Visibility for RSSI | Limited: no traceability of transit modifications | Complete audit of documented transit chain |
| Status | Published RFC, deployed since 2011 | Draft adopted by IETF WG in March 2026, not yet RFC |
What to Watch Before Deployment
Four documents have been adopted by the IETF dkim WG: the main specification, a motivation document (draft-ietf-dkim-dkim2-motivation), a deployment profile via Milter interface, and a best practices guide. All are prefixed draft-ietf-dkim, indicating that they are officially in the working group’s pipeline, not individual proposals.
- Tracking the Main Specification: the draft-ietf-dkim-dkim2-spec expires in October 2026. Its renewal or advancement to Proposed Standard status will be the first concrete signal of its trajectory towards RFC.
- Mailbox Provider Testing: Richard Clayton mentioned deployments with mailbox providers in the coming months. Gmail, Yahoo, or Outlook announcing DKIM2 support would immediately change priorities for ESPs.
- Inbound Infrastructure for ESPs: the expected increase in asynchronous bounce volumes during deployment requires enhanced inbound capacity. ESPs preparing their infrastructure in advance will face less operational pressure.
- Address Suppression Policy: DKIM2 asynchronous bounces can arrive 24 hours or more after the initial send. Automatic suppression rules need revision to accommodate this delay without generating false positives in unsubscribe lists.
Al Iverson reminds in April 2026 that the specification is not yet finalized, and details might change. The IETF WG has organized interim sessions in 2026 to accelerate the work. The agenda for the interim meeting on April 29, 2026, documents the drafts under review.
To follow real-time progress: subscribe to the ietf-dkim@ietf.org mailing list and check the status of drafts at datatracker.ietf.org/group/dkim, the platform where the actual timetable for DKIM2 is decided.
