Our team was at a Deliverability Summit where Richard Clayton, one of the authors of the DKIM2 specification, gave a talk on where the spec is at, what it changes, and what we should all expect over the next couple of years. We came back with a much clearer picture than we had before, and since I haven’t seen many practical write-ups yet, I figured I’d share what we learned.<\/p>\n\n\n\n
This is going to be technical, but I’ll try to keep it readable. If you’ve been wondering whether DKIM2 is something you need to start preparing for, the short answer is “yes, but not in a panic kind of way.” Here’s the longer version.<\/p>\n\n\n\n
DKIM1 has been around since 2007. It works. But it has three specific problems that have gotten worse as email infrastructure has gotten more complex.<\/p>\n\n\n\n
This is probably the biggest motivator. The way DKIM1 works, the signature covers the message body and selected headers, but it does not<\/em> cover who the message is actually being sent to. So if a spammer can get a single legitimately-signed message out of a high-reputation sender (say, a free email account they registered themselves), they can re-send that exact signed message to millions of other recipients. The DKIM signature<\/a> stays valid. The receiving server sees a perfectly good signature from a trusted domain and tends to give it a pass. This is one of the larger sources of spam today, and DKIM1 has no answer for it.<\/p>\n\n\n\n Every email person has seen this scenario. A domain publishes p=reject in their DMARC record. A user on that domain sends mail to a mailing list. The mailing list does what mailing lists do, adding a footer or rewriting the subject, and sends it out to all the subscribers. Those modifications break the DKIM signature. SPF doesn’t align because the mailing list is the one sending now. DMARC fails. p=reject says “throw it away.” Suddenly legitimate list traffic is getting bounced and list operators have to do ugly workarounds like ARC or From-rewriting.<\/p>\n\n\n\n When mail bounces, the bounce goes back to the envelope sender (the RFC5321 MAIL FROM). That envelope can be forged. So when spammers forge your domain in the envelope and blast out garbage, every bounce comes back to you. Your inbox fills up with delivery failures for messages you never sent. DKIM1 doesn’t sign the envelope, so there’s no way for receivers to know it’s been spoofed.<\/p>\n\n\n\n DKIM2 is designed to address all three of these.<\/p>\n\n\n\n The mechanics are pretty elegant once you see them. Two new header fields do most of the work.<\/p>\n\n\n\n The <\/strong>Message-Instance<\/strong> header<\/strong> holds hashes of the message body and headers, plus what Richard called “recipes,” which are a record of any modifications that have been made to the message in transit. So if a mailing list adds a footer, that modification is recorded in the recipe. A downstream verifier can replay the recipe against the original hash and confirm that the chain of changes is legitimate and accounted for.<\/p>\n\n\n\n The <\/strong>DKIM2-Signature<\/strong> header<\/strong> is the actual cryptographic signature. The big change here is that it signs the RFC5321 envelope values<\/strong>: the MAIL FROM and the RCPT TO. This is the part that kills replay attacks. If a spammer captures a signed message and tries to resend it to new recipients, the RCPT TO won’t match what was signed, and verification fails. The free ride is over.<\/p>\n\n\n\n The other big shift in DKIM2 is that every hop in the delivery chain signs<\/strong>. You don’t get a single signature at the start that has to survive every modification along the way. You get a chain. Each handler signs what they’re sending, records any modifications they made, and passes it on. By the time the message reaches the final inbox, there’s a verifiable record of exactly what touched it and what they did.<\/p>\n\n\n\n This is what fixes the mailing list problem. The mailing list can legitimately modify the message, sign their version, and the receiving server can see the whole chain: the original sender’s signature is valid on the original content, the mailing list signed their modification, here’s what they changed, everyone is who they say they are. No more pretending that p=reject and active mailing lists can coexist through duct tape.<\/p>\n\n\n\n It also fixes backscatter, because the chain is signed end to end. Bounces follow the signed path back to the actual previous hop, not whatever forged address happens to be in the envelope.<\/p>\n\n\n\n This is the part I want to highlight because I think it’s going to confuse people. DKIM2 reuses your existing DKIM1 keys<\/strong>. You don’t need to publish new selectors. You don’t need to rotate anything. The same key material that signs your DKIM1 signatures today will sign your DKIM2 signatures tomorrow.<\/p>\n\n\n\n What changes is the signing software on the sending side and the verification software on the receiving side. From the perspective of a domain owner, meaning the people whose domains we manage at EasyDMARC, there’s nothing to do in DNS. Your ESP, your transactional mail provider, your own MTA. Those are the places where the work happens.<\/p>\n\n\n\n That’s a smart design choice. Standards that require every domain on the planet to update DNS records take a decade to roll out. DKIM2 sidesteps that entirely.<\/p>\n\n\n\n Two real changes here.<\/p>\n\n\n\n Backscatter goes away.<\/strong> Today, if a spammer puts your address in the envelope MAIL FROM and blasts mail to invalid addresses, the bounces from those invalid addresses can come straight to your inbox. Receivers have no way to verify whether the envelope is legitimate. DKIM2 closes this by requiring the return path to align with the signing domain and signing it, so a receiver can verify the return path before generating any bounce. Forged envelopes don’t produce bounces. Forwarders are accommodated cleanly by rewriting and re-signing their own return path at each hop, so each hop owns its return path cryptographically and bounces follow the actual chain.<\/p>\n\n\n\n Async bounce volumes will likely rise.<\/strong> Mailbox providers have minimized asynchronous bounces (the kind that arrive minutes or hours after delivery, as a separate email) because untrusted return paths made them risky to use. Trustworthy return paths remove that risk. If you run sending infrastructure, it’s worth checking with your platform team that your async bounce handling is ready for higher volumes. For domain owners, this mostly affects how delivery and bounce reporting looks in your dashboards.<\/p>\n\n\n\n One note on VERP since people sometimes conflate it with this change: VERP (Variable Envelope Return Path) doesn’t get replaced by DKIM2. VERP solves the problem of identifying which original message a bounce corresponds to. DKIM2 solves the problem of trusting that the return path is real. Different problems, and both stay useful.<\/p>\n\n\n\n For at least the next couple of years, every message that wants to be DKIM2-signed is also going to be DKIM1-signed. This is “dual signing” and it’s expected to be the default during the entire transition period. DKIM1 verifiers ignore the new headers they don’t understand. DKIM2 verifiers use the new signature when they see it and fall back to DKIM1 when they don’t. Nobody breaks.<\/p>\n\n\n\n This is a sensible path. It also means there’s no flag day, no specific morning where DKIM1 suddenly stops working. It’ll be a gradual shift over years.<\/p>\n\n\n\n Here’s roughly where things are heading, based on what Richard laid out at the summit:<\/p>\n\n\n\n Q4 2026: <\/strong>Major mailbox providers (Google, Yahoo, the usual suspects) start running DKIM2 in experimental mode. They’ll be verifying signatures and surfacing the results somewhere visible to senders, most likely through DMARC aggregate reports<\/a> and the existing Authentication-Results header.<\/p>\n\n\n\n Q1 2027:<\/strong> production rollouts.<\/p>\n\n\n\n These dates may slip. But this is the shape of the thing, and the direction isn’t going to change.<\/p>\n\n\n\n If you’re operating mail infrastructure on the receiving side, you need to start thinking about DKIM2 verification capability now. The new header fields, envelope binding, and chain validation all need to be implemented. The good news is the spec leans heavily on existing DKIM1 mechanics, so it’s an extension of code that already exists in most MTAs and filtering systems rather than a from-scratch rewrite.<\/p>\n\n\n\n The harder part is going to be policy. What do you do when DKIM1 passes but DKIM2 fails? What about the inverse? How do you weight a chain with three intermediate hops versus one with seven? When does a broken chain become suspicious enough to act on? These are the questions every receiving operator is going to be working through over the next 18 months, and there isn’t going to be one right answer.<\/p>\n\n\n\n Honestly, not much. DKIM2 isn’t deployed yet, and the spec is still being finalized. There’s no product or configuration change you can make on your domain today that gets you DKIM2 ahead of the rollout.<\/p>\n\n\n\n What you can<\/em> do is prepare the things that will matter when DKIM2 lands.<\/p>\n\n\n\n Activate DMARC reporting and actually use it. If you don’t have a rua address in your DMARC record, or you have one but the reports go to an inbox nobody reads, that’s the first thing to fix. DMARC reports are how you see what’s actually happening with your mail today: which of your senders are aligning, which are failing, and which IPs are sending in your name without your knowledge. Once DKIM2 verification rolls out, those same reports will start carrying DKIM2 results too, and the value of that new signal depends entirely on whether you have the pipeline to read it. DKIM2 doesn’t replace DMARC. It feeds into it.<\/p>\n\n\n\n Know your sending stack. List out every vendor that sends mail on your behalf: ESPs, CRM, transactional providers, support tools, marketing automation, internal apps. When DKIM2 starts factoring into deliverability, the implementation work happens at each of these vendors, not on your domain. The sooner you have that map, the easier the conversations get.<\/p>\n\n\n\n Pay attention to what your ESPs and mail providers say about their DKIM2 roadmaps over the next year. The ones that take this seriously will be ready when the major mailbox providers start rewarding it. The ones that don’t, you’ll want to know about before they become your problem.<\/p>\n\n\n\n That’s it. There isn’t a checklist with twenty items. Anyone telling you there is, isn’t being straight with you.<\/p>\n\n\n\n It’s been a while since email authentication<\/a> has seen a real change. DKIM1 is from 2007. SPF<\/a> in its current form has been around even longer. DMARC came along in 2015 and has stayed essentially the same since. For most of the last decade, the work in this space has been about getting people to actually deploy what already existed, not about new protocols.<\/p>\n\n\n\nMailing lists and p=reject<\/strong><\/h3>\n\n\n\n
Backscatter<\/strong><\/h3>\n\n\n\n
What DKIM2 actually changes<\/strong><\/h2>\n\n\n\n
You don’t need to change your DNS<\/strong><\/h2>\n\n\n\n
Bounce handling gets better<\/strong><\/h2>\n\n\n\n
The Transition: Dual Signing<\/strong><\/h2>\n\n\n\n
Timeline<\/strong><\/h2>\n\n\n\n
What receivers <\/strong>need to do<\/strong><\/h2>\n\n\n\n
What senders should do now<\/strong><\/h2>\n\n\n\n
My take<\/strong><\/h2>\n\n\n\n