Changes are coming! A proposed update to DomainKeys Identified Mail (DKIM) is starting to take shape within the Internet Engineering Task Force (IETF), an Internet standards body.
While this new version, DKIM2, is still in development, it’s worth watching, as it will impact how different parts of the email ecosystem handle authentication, delivery, and security.
A quick refresher on DKIM
DKIM is a cryptographic authentication protocol that allows a domain to attach a digital signature to an email message. That signature, stored in a hidden email header, enables receiving systems (mailbox providers, secure email gateways, and similar) to verify that the message was authorized by the sending domain and has not been altered in transit.
It’s one of the foundational protocols of modern email authentication, widely deployed for just over two decades. Predating DMARC, DKIM itself evolved from Yahoo’s earlier “DomainKeys” specification and quickly became an industry-wide standard through collaboration among major mailbox providers and email technology and security vendors.
DKIM has held up well. But like most long-lived protocols, there can be limits to what it can do.
DKIM2: What it can fix
The smart folks involved in the IETF DKIM working group are aiming to address three specific challenges with DKIM2:
- DKIM replay
- Backscatter
- Message modification breaking authentication
These aren’t necessarily brand new problems. But they’ve become more visible and more impactful as email filtering and abuse tactics have evolved.
Problem 1: DKIM replay
DKIM replay is a well-known abuse scenario. A legitimate, DKIM-signed message is captured and resent to a large number of new recipients.
Because the original signature remains valid, the message can pass authentication checks and benefit from the originating domain’s reputation. That can lead to bad actors getting underserved inbox placement, followed by spam complaints that ultimately damage the reputation of the domain being replayed.
DKIM2 aims to mitigate this by binding messages more tightly to their intended recipients. The details are still being worked out, but the goal is straightforward: if a message shows up somewhere it was not meant to go, the receiving system can detect that and reject it.
While you might be used to see your email address in the TO: header of most email messages you receive – and lack of this might be a personal indicator to you that a message could be spam – there’s really nothing in SMTP or email authentication protocols today that require that the email address for a message’s recipient be specified in any sort of reliable way that would allow a mailbox provider to have any idea who the original, intended recipient was. This fixes that.
There are various means by which some mailbox providers look for and attempt to mitigate DKIM replay today, but ultimately, unless the specification can be updated to help fully prevent it, gaps will remain.
Problem 2: Backscatter
Backscatter is what happens when bounce messages are sent to the wrong party. Most people have seen this in the form of a non-delivery report (NDR or bounce) for a message they never sent. Backscatter is a very old problem; the original term for a blast of backscatter bounces in spam-fighting circles was “joe job,” referring to a famous spam incident all the way back in 1997.
While Sender Policy Framework (SPF) can authenticate the bounce (or “return path”) address domain, it’s not commonly used to prevent backscatter, and it has its own limitations.
DKIM2 proposes allowing the bounce address to be cryptographically signed and aligned with the sending domain. That creates a more reliable way to ensure that bounces go to the correct destination.
There’s an important secondary effect here as well. Today, delayed bounces are generally discouraged because they can contribute to backscatter. DKIM2 could make delayed rejection safer, giving mailbox providers more time to analyze messages before deciding whether to accept or reject them. That matters because, as modern email threats evolve, filtering and security checks continue to get more computationally expensive.
Problem 3: Message changes breaking authentication
A long-standing challenge with DKIM is that it is sensitive to changes in message content. Change the body, and you’ll break the DKIM signature, lose the benefits of authentication, and make a message falsely appear to be spoofed.
This happens a lot. Common examples include secure email gateways rewriting links or message bodies, mailing lists adding footers to the body or extra message headers, and email forwarding. These changes often break DKIM signatures, forcing mailbox providers and filtering systems to rely on often imperfect workarounds.
DKIM2 proposes a more structured approach. Intermediaries that modify a message would be able to add their own signatures and document what was changed. Receiving systems could then validate the chain of custody, stepping backward through each modification to confirm both the changes and the authentication status of the original sender.
An earlier attempt to address this issue, ARC (Authenticated Received Chain), saw some adoption. The rough consensus of the participants in the working group is that DKIM2 offers a more complete solution to this problem.
What this means for email senders and mailbox providers
For most big email senders, especially those using cloud-based email platforms, the impact is likely to be limited.
If you operate your own mail infrastructure, you’ll eventually need to evaluate and adopt DKIM2 support as it becomes available in MTA software.
If you rely on providers like Amazon SES, SendGrid, or Postmark, those platforms will handle most of the implementation. There may be some DNS updates required, depending on how key management evolves, but the expectation is that existing DKIM keys are likely to remain compatible.
Day-to-day email sending workflows are unlikely to change significantly.
Mailbox providers and filtering systems will see the bulk of the complexity. They will need to validate recipient binding to prevent replay, handle signed bounce addresses properly, and process and unwind chains of message modifications. Most of the heavy lifting happens on the receiving side.
Still early, still evolving
It’s important to note that DKIM2 is still under active development within the IETF. The specification is not final, and details may change. If you’re involved in email infrastructure, authentication, or security, now is a good time to pay attention. Participation is easy (and free): the IETF process is open. Anyone with an interest can review drafts, join discussions, and contribute feedback. More information is available via the IETF DKIM working group.
What about DMARC?
One obvious question is how DKIM2 will interact with DMARC. At this stage, there’s not much concrete to report. The expectation is that DMARC will continue to play a critical role in the ecosystem. It’s widely deployed and delivers clear value in domain protection and policy enforcement. As DKIM2 evolves, its relationship with DMARC will be an important area to watch.
The bottom line about DKIM2
DomainKeys Identified Mail needs to evolve to be able to best authenticate and protect the email ecosystem. The proposed DKIM2 version helps to modernize an important part of email authentication infrastructure. The problems it aims to solve are real, and in some cases long-standing. For senders, the changes are likely to be incremental.
For mailbox providers and security systems, less so. Either way, this is one to keep on your radar.
