DKIM2 is a proposed successor to DKIM — the digital signature that proves your email wasn’t tampered with — and it rethinks email authentication for a world of forwarders, mailing lists, and industrial-scale replay attacks. It is an active IETF Internet-Draft, not a finished standard, so nothing changes in your DNS today. But it is being written by engineers at Yahoo, Google, and Fastmail, and the problems it targets are ones every sender already feels: forwarded mail that silently fails, bounces that vanish, and signed messages weaponized against you at scale.
Here is what DKIM2 actually is, the specific gaps it closes, and what — if anything — you should do about it now.
Why DKIM Needs a Successor
Today’s authentication stack is a patchwork of four standards bolted together over two decades: SPF checks the sending IP, DKIM signs the message, DMARC ties them to your visible From domain, and ARC tries to preserve authentication across intermediaries. If you need a refresher on how the core three fit together, our SPF, DKIM, and DMARC explainer covers the trinity in plain English.
The problem is that DKIM — the cryptographic core of that stack — was designed in 2007 to answer one narrow question: was this message modified since it was signed? It answers nothing about who the message was for, which path it took, or what legitimately changed along the way. Those blind spots have hardened into three expensive failure modes, and they are the reason a v2 is being drafted at all.
DKIM2 at a Glance
The Three Problems DKIM2 Solves
DKIM2’s entire design collapses into one idea: make every hop accountable. That single change is what closes all three of the gaps below.
Replay attacks
A valid DKIM signature proves the message content is intact — but it says nothing about the intended recipient. Attackers exploit this. They receive one legitimately-signed message from a reputable domain, then re-send that exact message, untouched, to millions of other addresses. The DKIM signature still verifies perfectly, so the spam inherits the sender’s good reputation. This “DKIM replay” attack is one of the hardest problems in deliverability today, and it is impossible to fully stop with single-signature DKIM.
DKIM2 records the SMTP envelope — the actual MAIL FROM and RCPT TO — inside each signature. A message signed for one recipient can no longer be silently re-mailed to a different list without breaking the chain.
Un-routable bounces (DSNs)
When mail can’t be delivered, the receiving server generates a Delivery Status Notification (a bounce). Today, that bounce is sent back to the Return-Path address — which can name a domain that never actually handled the message. That gap lets attackers forge bounces, misdirect abuse reports, and flood innocent domains with backscatter. DKIM2 routes notifications back along the same verified chain the message travelled, so a bounce can only flow to a server that genuinely touched the mail.
Broken forwarding and mailing-list signatures
This is the one senders feel most often. The moment a forwarder or mailing list edits a message — appends a footer, rewrites the subject with a [list] tag, adds an unsubscribe link — the original DKIM signature breaks. DKIM has no way to distinguish a harmless footer from malicious tampering; both just read as “signature failed,” and legitimate mail lands in spam. ARC was created as a bolt-on to patch this, but it is complex and only partially adopted. DKIM2 handles modification natively: intermediaries record what they changed and re-sign, so a verifier can see exactly who altered what and judge each hop on its own merits. If DMARC failures and the spam folder are a familiar pain, our 2M-email study on DMARC failure and spam placement shows just how costly these breaks are.
How DKIM2 Actually Works
DKIM2 replaces “one signature over the original message” with a signed chain of custody. Two new header field types carry it:
- A Message-Instance header captures the state of the message at each hop — essentially a hash snapshot (a SHA-256 fingerprint of the body and headers) recording what the message looked like when a given server saw it.
- Chained DKIM2-Signature headers are added by each server in the path. Crucially, each signature covers not just the current snapshot but all prior signatures too. Every hop signs over the accumulated history.
Because each link is bound to the ones before it, the result is tamper-evident: you cannot remove, reorder, or forge a hop without invalidating everything downstream. A verifier can walk the chain from origin to inbox, confirm that each RCPT TO matches the next hop’s MAIL FROM, and — when an intermediary legitimately modified the message — replay the recorded changes to re-verify the earlier state. That is the mechanism that makes replay detection, bounce routing, and forwarding-tolerance all fall out of the same design.
The cryptography itself is familiar: SHA-256 hashing with RSA and Ed25519 signatures, and public keys published in DNS under the same selector._domainkey.domain structure DKIM already uses. If you have ever inspected a raw message to see these headers, our anatomy of an ecommerce email header is a good companion read.
DKIM vs DKIM2
| Capability | DKIM (RFC 6376) | DKIM2 (draft) |
|---|---|---|
| Signature model | One signature at origin | Chained signature at every hop |
| Recipient binding | None — signature ignores who it was for | Envelope (MAIL FROM / RCPT TO) bound into each signature |
| Replay resistance | Weak — replays verify perfectly | Strong — recipient mismatch breaks the chain |
| Forwarding / list edits | Signature breaks, no context | Changes recorded and re-signed per hop |
| Bounce (DSN) routing | Can be forged / misdirected | Routed along the verified chain |
| Role of ARC | Needs ARC bolted on for intermediaries | Absorbs much of ARC’s job natively |
| Status | Ratified, universally enforced | Active Internet-Draft, not final |
Does DKIM2 Replace SPF, DMARC, and ARC?
Not overnight, and not all of them equally. The clearest target is ARC — DKIM2’s native handling of intermediaries is meant to make the ARC bolt-on largely unnecessary. DKIM itself is what DKIM2 succeeds by name. SPF and DMARC address related-but-different concerns (authorized IPs and From-domain policy), and DKIM2 does not erase the need to think about domain alignment — a topic that keeps evolving, as our guide to domain alignment and inbox placement explains.
For the foreseeable future the honest answer is: nothing is replaced yet. SPF, DKIM, and DMARC remain the enforced baseline that Gmail, Yahoo, and Microsoft check on every message. DKIM2 is additive and provider-driven. You can see how deep today’s requirements already run in our state of SPF/DKIM adoption in ecommerce and the plain-English what is DMARC guide.
When Is DKIM2 Coming?
DKIM2 is real but early. The current Internet-Draft is revision 04, carrying an expiry of January 2027, and four interoperable reference implementations already run in Python, Perl, Go, and C — alongside live demonstration servers signing real mailing-list traffic. Industry observers forecast the first production deployments at large mailbox providers around the end of 2026.
But “a draft with working code and a 2026 demo” is a long way from “an enforced standard.” Details will change, adoption will be gradual, and single-signature DKIM will remain the norm for years. Treat DKIM2 as a direction of travel, not a deadline.
What Senders Should Do Now
Because DKIM2 is server-side and unfinished, preparation is not about deploying anything new — it is about being in excellent standing on the authentication you already control:
- Get SPF, DKIM, and DMARC fully aligned. DKIM2 builds on this foundation; clean senders inherit the smoothest path. Aim for DMARC at
p=quarantineor stronger. - Monitor authentication results continuously. Anything failing under today’s rules will fail harder under a stricter chain-of-custody model. Fix broken sending sources now.
- Map your forwarding and mailing-list paths. These are the exact scenarios DKIM2 targets, and knowing your real delivery paths makes authentication failures far easier to diagnose.
- Watch the draft, don’t rush. No new records are required. Track
draft-ietf-dkim-dkim2-specand your ESP’s roadmap, and enable DKIM2 signing when your provider offers it.
For the broader set of security standards worth having in place before DKIM2 lands, MTA-STS and TLS-RPT are the ones most brands still miss.
The Bottom Line
- DKIM2 is a draft, not a deployment. It is an active IETF Internet-Draft from Yahoo, Google, and Fastmail — promising, but not yet a standard you configure.
- It fixes three real problems: replay attacks, un-routable bounces, and broken forwarding/mailing-list signatures — by making every hop sign a tamper-evident chain of custody.
- It binds recipient and path into the signature, which single-signature DKIM never did — that one change is what unlocks all three fixes.
- It targets ARC and DKIM first; SPF and DMARC remain the enforced baseline for years to come.
- Your best preparation is boring and effective: keep SPF/DKIM/DMARC aligned and your authentication results monitored, so you are ready the day DKIM2 arrives.
Want a definitive source? The specification lives at the IETF datatracker, and the working group maintains an overview at dkim2.com.
Get ahead of DKIM2
DKIM2 rewards senders whose authentication is already clean. InboxEagle shows you exactly where yours stands.
Track SPF, DKIM, and DMARC pass rates by provider and by campaign, catch failing sending sources before they hurt placement, and see where your emails actually land — inbox, Promotions, or spam.
