Table of Contents

• Introduction
• What is it?
• OK, but really, what is it?
• OK. Why?
• Current Status
• ESPs Take Note
• Next Steps
• Conclusion

Introduction

After years of stagnation in email authentication protocol development we have a new player entering town. The protocol is DKIM2 and it’s in active development over at the IETF. If you want to see the sausage being made, you can visit the IETF datatracker to see the details and sign up for the mailing list.

This is something I’ve been watching for a while, and this week Richard Clayton, one of the authors, gave a presentation at Deliverability Summit.

What is it?

It’s an evolution of authentication based on all the things learned over the past 20 years.

The protocol itself is most similar to DKIM (hence the name): email messages are cryptographically signed. There are a couple expansions that do improve the overall security and reliability of email compared to DKIM and other current authentication protocols. It also addresses some of the problems and breakages introduced by other authentication methods and spam filters.

Ok, but really, what is it.

It’s based on DKIM so the easiest way to talk about it is to start with how DKIM works. The originator of a message takes a hash of the headers and a hash of the body, signs both hashes with a private key and then adds the DKIM signature into the headers. When the message reaches the destination the receiving mailserver takes a hash of the headers listed in the DKIM signature and a hash of the body of the mesage and uses the public key published in DNS to verify the message has not changed between the sender and the receiver. If it verifies, the message has “passed DKIM”.

Much of the time, mail passes through without any changes and DKIM passes without any problem. However, there are normal mail activities that can cause messages to be changed during transit. This activity breaks DKIM and can cause mail to fail, particularly for domains that have chosen to publish p=reject.

Some common cases include:

• security appliances that rewrite links or add subject line tags
• mailing lists or exploders that add subject line tags
• email forwarding systems

These actions change the body of the message and mean that the DKIM signature cannot be verified.

One of the things DKIM2 addresses is these types of harmless modifications. Each mailserver that changes a message during handling records what changes they made and resigns the message when passing it on. Any server handling the message can look at the recipies and undo them, all the way back to the original signature.

OK. Why?

There are a few different issues this is addressing.

Authentication failures

Current authentication processes are more fragile than many of us are comfortable with. Standard and common mail handling and forwarding can break authentication and cause delivery failures. Additionally, traditional discussion and mailing lists have been damaged in the face of restrictive DMARC policy statements.

ARC was the protocol that was intended to address the forwarding problem. Essentially a mailserver would sign a message stating what the authentication status of that message was when it received it. The idea was that ARC could be used to distinguish which forwarders were trustworthy and which ones were not. This didn’t work very well and most receivers tell us they can’t use or trust ARC signatures. In fact, the IETF DMARC working group is currently working on a document deprecating ARC.

DKIM2 takes a different approach to modifications. Instead of just saying “this validated when I received it” DKIM2 specifies what modifications were made to the email. No one needs to trust an intermediary. Any entity changing an email specifies what changes they’ve made to the message. Other mail handlers can undo those changes and verify the message all the way back to the originator. If a change was malicious, like adding a URL or spammy content, then the recipient domain can make decisions about what to do with the message regardless of the original domain reputation.

DKIM replay

One of the current email problems is called DKIM replay attack. Essentially a spammer or malicious actor creates a one off email at a service with a good reputation and sends it to an address they control. They then “replay” or “explode” that message out to thousands or millions of recipients without making any changes to the message. Because the message has not been changed, DKIM verifies. The original DKIM signature belongs to the service with a good reputation, thus the mail gets better delivery than it would if it was signed by the actual originator.

DKIM2 addresses this by recording the envelope recipient and sender in the signature. There is also a flag where the sender can tell receivers not to “explode” the message (ie, do not send it to multiple addresses) and a flag that exploders add to messages when they have exploded them.

Backscatter and delayed bounces

In the SMTP protocol there are two ways a receiver can refuse to accept an email. The first happens during the SMTP transaction itself, when there is a 5xy or 4xy response code. That’s properly called a rejection because the mail was rejected during the transaction, but most of us refer to that as a bounce. Mailservers are also permitted to accept the message and then “bounce” it later. There are a lot of reasons to handle incoming email this way. First, it allows for the external mailserver to not have to know all the active users. Second, and more importantly, it means that a server can accept a message and do a deeper inspection and analysis of the message. Mailservers no longer need to make split second decisions to accept or reject a message, they can make a decision minutes later.

Delayed bounces are not used very often on the modern internet due to spam and other malicious traffic forging addresses. Known as backscatter, delayed rejections can and do result in some innocent recipients being mailbombed when their address is forged in spam. Rejection during the SMTP transaction and delivering mail to the spam folder are ways mailbox providers limit the amount of backscatter they send. The truth, though, is that delayed bounces are actually very useful.

DKIM2 addresses the backscatter problem by returning the message directly to the previous sender. Instead of sending it to a potentially forged address, it’s securely sent to the actual handler that modified the message and cryptographically signed it. This feature is, IMO, going to fundamentally change how we as deliverability folks handle compliance, keep reading for why.

Current Status

A few weeks ago, Simon Harper discussed the coming of DKIM2 in his [All About Email newsletter]((https://newsletter.allabout.email/p/issue-231-all-about-email) and a couple of us said “oh, not so fast, it’s not that ready for primetime”. My sincere apologies to Simon, it’s coming faster than I expected and he was not moving too fast.

At the Deliverabiity Summit in Barcelona this week Richard Clayton one of the authors of DKIM2 spoke about its current status. It’s further along than I thought. There is working code and the expectation that it will be deployed in some mailbox providers in the next few months. Richard also specifically asked Steve to make sure that DKIM2 checking was in aboutmy.email and that’s in progress and will show up in results soon.

For the brand sender the deployment of DKIM2 isn’t going to be that visible. DKIM2 reuses DKIM keys so there my be no need for senders to make any changes.

For ESPs and intermediaries, though, there will need to be changes on outbound and inbound mail.

ESPs will need to update signing code to accommodate the new flags and ensure they can sign all appropriate headers. Most of them will just find the appropriate libraries produced by their MTA vendor. They will need to double sign messages with DKIM and DKIM2, but we’ve been here before, when folks were signing with Domainkeys and DKIM.

The outbound is going to be slightly annoying, but mostly an engineering issue. The infrastructure folks are going to update their code behind the scenes and there will be more signatures in headers but end users may not notice any changes. Those of us who trawl headers may see commercial mail sent through ESPs with 4 headers now: DKIM d=brand, DKIM d=ESP, DKIM2 d=brand, DKIM2 d=ESP. I don’t expect this will cause much of a problem for ESPs, but it is something to be aware of.

All of this I was aware of and was thinking it wasn’t going to have a huge impact. But then Richard made a statement that made me reconsider the bigger impact of DKIM2. In fact, after hearing what he had to say, I think DKIM2 is going to lead to a major shift in how spam is handled at mailbox providers and what data compliance desks have to work with.

What did he say that caused such a shift? Because DKIM2 addresses the backscatter problem he says if a provider determins based on recipient feedback, that a message is spam they can bounce it back to the originator even 24 hours later.

This has some fairly major implications for ESPs.

ESPs take note

Right now, many ESPs don’t deal very well with delayed bounces. They really haven’t had to because so few receivers send them in any volume. But handling increased incoming volume is not the only change, there are other issue ESPs will need to address in a DKIM2 enabled world.

Inbound capacity

Based on discussions I’ve had in the past with ESPs and understanding their engineering optimization, many ESPs don’t have much inbound capacity. They have big outbound pipes, but they handle so little inbound mail they don’t have to think about what to do with it.

This is going to have to change. Right now, if a mailbox provider accepts mail and determines it’s spam after it’s been accepted, then that mail is just delivered to the spam folder. But with DKIM2 the mailbox provider can delay bounce all that mail back to the sender instead of delivering to spam. Additionally, it may be possible for the mail to be delay bounced even after it’s been delivered to spam. This change in handling has the potential to cause a huge increase in the amount of mail ESPs have to handle. Instead of customer mail languishing in the spam folder, all that mail is going to come back to the sender.

If an ESP can’t accept the mail, then I expect their reputation to take a hit and cause delivery problems across their user base.

Address suppression

Once an ESP has accepted the bounced message, then what? Bounce handling is a weird and wacky world as it is and before we get to delayed bounces. What decisions do we make about future mail to those addresses? I can argue that the addresses should be suppressed from future sends as this is a FBL message from the mailbox provider. On the other hand, as the FBL is from the mailbox provider rather than the individual, maybe it’s not a good idea to suppress on behalf of the ESP customer.
I don’t have an good answer for this question. I do think that, as an industry, we need to talk about it and review the data we get to determine what the right answers are.

Compliance

From a compliance perspective, this is a reliable signal about what the mailbox providers think. Right now compliance misses a lot of spammers on the network do to weak and gameable signals. (In fact, one of the other fascinating talks this week was from an ESP who found a network so spammers operating under their compliance radar). Yes, we do have feedback loops, but those are a noisy, unpredictable and sometimes unreliable signal. With delayed bounces telling you exactly what mail hit the spam folder, though, compliance is going to know exactly which of their customers are a problem.

There are going to be some challenges as we move into this new world. The first will be in extracting the data and getting it to the compliance team in a useable format. Teams will also need to look at the data and figure out what the triggers and thresholds are for intervention and interacting with the customer.

Warmup

Another place where this is a great signal. We can watch what’s happening during warmup with more confidence than ever before. Maybe we can warmup faster, maybe we need to go slower. But this has the potential to give us definitive signals about what’s going on during warmup.

Customer reporting

One of the biggest challenges for ESPs is going to be reporting back to customers. They may potentially see that their mail delivered at 99% but then fell down to 95% 24 hours later due to the delayed bounces. How do we explain to customers that the mail that delivered 99% yesterday has had 4% of the messages now bounced because they were determined to be spam by a major mailbox provider? What training do support and deliverability teams need to be able to help our customers understand this?

Again, no good answers, but these are questions we’re going to have to address.

Next Steps

DKIM2 has working code and the major mailbox providers involved seem to be close to ready to deploy it at least in testing mode. As I write this, Steve is working on DKIM2 code for aboutmy.email. Other folks involved in the development effort have written libraries in multiple languages and produced milters for senders to use. DKIM2 is happening and it’s happening quickly.

For brands and companies that use providers for inbound and outbound mail this change should mostly happen behind the scenes. Even those of us who run our own mailservers are going to plug in one of the libraries currently being developed and be up to date.

As with a lot of changes, it’s ESPs, email infrastructure companies and mailbox providers that have a lot of work to do to be ready for it. Some of that work is technical. But for ESPs and mailbox providers some of that work is developing the right policies, processes and messaging for customers who are now getting data they don’t understand. This is not something AI can help with - there is no body of work to base any answer on. We’re going to have to develop this ourselves.

Conclusion

I’ve been saying for a while that deliverability is based around metrics and processes that were developed for mail in the 2000s and in a lot of ways they weren’t keeping up with the modern email landscape. DKIM2 is changing a lot of that.

This is the first change in authentication we’ve seen in the last decade, or longer. It may even eventually replace all our current authentication requirements. I know a lot of receivers currently don’t find SPF to be very useful on its own and there was even discussion about deprecating it in DMARCbis, but the group could not reach any rough consensus. I do expect to see SPF records for forever, but also I don’t see it affecting deliverability as DKIM2 is deployed. It will be interesting to see what happens with DMARC. I’ve seen and heard informed speculation that this might even replace DMARC.

How fast will all this happen? It’s moving a lot faster than I expected. We should have working DKIM2 from the major providers by the end of 2026. There will always be a long tail of adoption, but the Yahoo and Google changes from 2023 have shown us just how fast senders can change when provided with the right incentives.

If you are a video person Al Iverson from Spamresource has put up a short Youtube explainer on DKIM2.