DKIM has guarded the From address for fifteen years, but its design has two well-known holes. It signs a message once, as the message leaves your infrastructure, and that single signature has no idea who the message was addressed to. So a message that is legitimately forwarded - through a mailing list that appends a footer, say - often arrives with a broken signature and gets caught by DMARC. And a message whose signature is still valid can be scooped up and “replayed” to thousands of new victims, borrowing the original signer’s good reputation. A working group at the IETF is now rebuilding DKIM from the ground up to close both holes. It is called DKIM2.
What DKIM2 is
DKIM2 - “DomainKeys Identified Mail Signatures v2” - is an Internet-Draft, draft-ietf-dkim-dkim2-spec, adopted by the revived IETF dkim working group and now at revision -04 (5 July 2026). It is written by a notable three-provider coalition: Richard Clayton (Yahoo), Wei Chuang (Google) and Bron Gondwana (Fastmail). Where DKIM1 (RFC 6376, 2011) signs once and hopes the signature survives the journey, DKIM2 signs at every hop and builds a verifiable chain of custody that a receiver can walk in reverse.
The four things it fixes
- Replay. DKIM1 binds a signature to the body and some headers, but not to the envelope. DKIM2 records the SMTP
MAIL FROMandRCPT TOinside the signature (themf=andrt=tags) and stamps it with a timestamp (t=). A receiver checks that the recipients it actually delivered to match thert=on the newest signature - so a captured message replayed to different recipients no longer verifies. Signatures also age out: implementations may reject anything more than 14 days old. - Forwarding. Instead of one fragile origin signature, every mailserver that touches the message signs it, numbered in sequence with an
i=tag (i=1for the originator,i=2for the first hop, and so on). An intermediary that modifies the message - a list footer, a subject tag - records exactly what it changed as reversible “recipes,” so a verifier can undo the change and re-check the earlier signature. Forwarding stops breaking DMARC. - Bounces and backscatter. DKIM1 bounces go to the envelope sender, which can be forged - the classic backscatter problem. DKIM2 sends the delivery notification back up the signed chain, to the
mf=of the newest signature, and the bounce itself is DKIM2-signed and carries the original message, so it can be proven genuine. A nullmf=<>says “do not bounce this at all.” - Header coverage. DKIM2 standardises which headers are signed rather than leaving it to a hand-picked
h=list.
| DKIM (RFC 6376) | DKIM2 (draft) | |
|---|---|---|
| Signs | Once, at origin | Every hop |
| Bound to recipient | No | Yes (mf= / rt=) |
| Replay protection | None | Envelope binding + 14-day expiry |
| Survives forwarding | Breaks on modification | Reversible “recipes” per hop |
| Bounces | To the (forgeable) envelope sender | Signed, routed up the chain |
| Intermediary trust | n/a | Cryptographic chain (replaces ARC) |
It also puts ARC out to pasture
ARC (RFC 8617, 2019) was the previous attempt to fix forwarding: intermediaries attached signed “assertions” about how they had handled a message, which a receiver could choose to trust. The problem was the trust - after roughly a decade, no internet-scale system emerged to decide which of thousands of forwarders deserved it. A companion draft, draft-ietf-dmarc-arc-to-historic, now proposes to formally retire ARC (RFC 8617) to Historic status and fold its useful ideas into DKIM2. The difference is the whole point: a DKIM2 verifier ends with cryptographic confirmation of every hop, where an ARC verifier ended with a transcript of assertions you had to take on faith.
The transition: dual signing
Nobody flips a switch. The DKIM2 best-practices draft (draft-ietf-dkim-dkim2-bcp) says senders should sign with both DKIM1 and DKIM2 keys through the entire transition, exactly as the industry once ran DomainKeys and DKIM side by side. Helpfully, DKIM2 reuses your existing DKIM DNS keys and selectors - there is no new record for a domain owner to invent. Most of the real work lands on ESPs and forwarders, whose signing software has to learn the new chain.
Where it stands, and the honest caveats
This is early. Working code exists - Stalwart shipped the first mail-server support and SocketLabs demonstrated the first end-to-end DKIM2 exchange between independent systems - and the authors expect experimental DKIM2 running at major providers by the end of 2026, with a finished RFC likely 12 to 18 months out and broad production adoption not before the late 2020s. But an IETF hackathon in late 2025 found the spec still too incomplete to implement cleanly, and several design questions - how bounces are suppressed and reported, per-recipient binding, header ordering - are still being argued on the mailing list.
The deliverability veteran Laura Atkins, initially unconvinced, came away from a recent presentation saying it is “coming faster than I expected” - while flagging a genuine unsolved problem: nobody yet knows how ESPs will absorb the flood of asynchronous bounces DKIM2 enables, or what the suppression and reporting policy around them should be. As she put it, there is no body of prior work to lean on, so the industry will have to develop those answers itself.
The consensus among implementers is unambiguous: do not deploy DKIM2 in production yet. No operator signs live DKIM2 mail today. (One disambiguation while we are here: this has nothing to do with Microsoft’s selector2 “second DKIM key,” which some consoles label “DKIM2.” Same nickname, unrelated thing.)
What to do now
DKIM2’s whole premise is that your DKIM1 has to be healthy first, so the useful preparation is the same hygiene that already helps you today:
- Make sure every legitimate source signs with aligned DKIM that passes, and retire weak or abandoned selectors. Keep RSA keys at 2048 bits and plan an Ed25519 path.
- Get DMARC to an enforcing policy with reporting switched on - DKIM2 results will surface in the same aggregate reports you already read.
- Inventory every vendor sending as you, and ask each one where DKIM2 sits on its roadmap - especially how it will cope with more inbound bounce traffic.
- Do not hand-craft a DKIM2 DNS record from a draft example. The spec is still moving; a homemade record helps nobody.
The nutshell: DKIM2 is the most significant rework of email signing in fifteen years, and it is real enough to watch closely - but for now it is a standard to prepare for, not one to run.