The DKIM replay attack, and how to mitigate – Halon

The DKIM replay attack is a way that spammers try to bypass spam filters by impersonating reputable organizations, exploiting the way that some mailbox providers use DomainKeys Identified Mail (DKIM) to build domain reputation. This can severely affect the reputation and deliverability of those organizations being impersonated. In this post we will look at DKIM replay; what it is, why it’s on the agenda, how it can be mitigated on both the sending and receiving side, and what’s happening next.

DKIM replay is nothing new. It is discussed in one section of the DKIM RFC 6376, and Word to the Wise provided recommendations back in 2014. But it looks to me as if the problem is growing. In December 2021, the privacy-focused mailbox provider ProtonMail experienced delivery problems to Gmail as a result of a DKIM replay attack, and we speak to email marketing companies that are fighting attacks more or less constantly. 

First some background. DKIM is a widely used technology to prevent email spoofing. It does so by adding a digital signature linked to the sender’s domain name, for each outgoing email message. This allows the receiver’s email server to check if an email claiming to be from a certain domain is in fact authorized by the owner of that domain name.

Email often travels in multiple hops: it is sometimes redistributed by for example mailing lists or forwarding rules. Therefore, DKIM is designed so that signed messages can be relayed (and consequently, replayed) by any server. It’s a feature of the standard. This feature is however becoming increasingly problematic, as so-called domain reputation is now playing a bigger part in large mailbox providers’ set of anti-spam measures.

What is domain reputation? Many of our readers have probably heard of IP reputation, which is the practice of keeping track of IP addresses that are distributing large volumes of spam. If an IP address is the originator of much spam, it will lead to a poor reputation, and email from that IP address is more likely to be treated as spam. Conversely, an IP address that is known to send much legitimate traffic and very little spam could have a better-than-neutral reputation, and email from that IP is unlikely to be treated as spam. Domain reputation is similar, but considering domain names instead of IP addresses. DKIM is an attractive source of domain information since it is proven by a digital signature. 

What’s the problem? The issue with DKIM and domain reputation is that the DKIM signature only guarantees that the email was once sent from the domain name owner’s server. The same email can be re-sent many times, from any source, and the signature is still valid. As mentioned above, this is a feature of DKIM, necessary for common use cases such as mailing lists to work.

DKIM replay attack. The so-called DKIM replay attack is used by spammers to bypass spam filters at popular mailbox providers known to utilize domain reputation (like Gmail). The spammer does so by sending a single spam to themselves from a provider with a good reputation, and then re-sending that DKIM-signed spam to tons of recipients using the spammer’s own infrastructure.

1. Identify a popular mailbox provider known to use domain reputation (like gmail.com)
2. Identify an email provider (let’s call it X) with a good reputation
3. Sign up for an account at provider X, and send a single spam to yourself
4. You will now have a spam message which is DKIM signed with X’s domain name
5. Re-send (replay) that spam message to millions of recipients at @gmail.com, hoping that the good reputation of X’s domain name will result in those messages not being detected as spam
6. If the domain reputation of X deteriorates, pause sending and wait for X’s reputation to improve before resuming sending

In several cases, the spammers sent many times the provider’s own volume worth of spam. During the Protomail incident in December 2021, the spammers sent 50 times Protonmail’s own volume at one point. 

What can be done? There are some countermeasures and good practices that can be applied by both senders (that DKIM sign) and receivers (that do domain reputation), but no silver bullet as of writing.

On the sending side, both mailbox providers (like telcos or web hosting) and senders (email marketing, ESPs) might be vulnerable, especially if they provide online sign-up. As long as user-generated email messages are DKIM signed with the organization’s domain name, there is a risk. These are some recommendations and mitigation ideas we’ve picked up:

• Consider a separate domain for new customers if you allow unvetted sign-up.
• Set an expiration (x=) as short as feasible to limit the time during which replay can be performed, preferably shorter for newly created or suspicious accounts. While the RFC states that the x= tag is not intended as a replay defense, it has proven an effective countermeasure. We did an analysis of the effective lifetime specified by x= for a few large ESPs and noticed that several are using lifetimes of a few days, and in some cases as little as hours or minutes.
• Re-sign messages in the defer queue as they are being retried, as a way to reduce the expiration time (x=) further. See the example below of how to do that with Halon MTA.
• Oversign important headers like Date, Subject, From, To, and CC to make sure that they cannot be added after being signed if they are missing from the original message.
• Sign with the customer’s domain if possible, which is feasible for most email marketing and web hosting companies where customers bring their own domain name. Even if you also sign with your own (provider) domain, the receiver performing domain reputation is likely to use the customer domain if it aligns with the From header.
• Add a user identity (i=) if you are unable to use a customer domain.
• Signing the entire message and as many headers as possible to prevent the spammer from changing the message to be even more “spammy” after being signed by your server.
• Make sure you have a DKIM rotation system in place so that you can easily rotate keys, in the unfortunate event that you need to do so quickly. That being said, the expiration time (x=) should be the primary way to control expiration.

// Re-sign deferred email as they are being retried in pre-delivery script
$mime = MailMessage::File(File($message["file"]["modified"]));
$dkim = $mime->signDKIM($sel, $domain, $key, ["return_header" => true]);
Try(["additional_headers" => ["DKIM-Signature: ".$dkim]]);

On the receiving side, it’s important that mailbox providers that use DKIM for domain reputation try to detect DKIM replay attacks. I think it’s fair to say that the way mailbox providers use DKIM for domain reputation is the source of the DKIM replay problem. Detecting DKIM replay attacks can be difficult, however. Identifying unusually large volumes of messages with the same signature could be part of the equation, which is also suggested by the RFC. It can be tricky however since legitimate mailing list volumes can be very large too.

I think that the DKIM replay issue highlights why industry groups like M3AAWG are very valuable. They bring organizations together to solve issues and make the internet safer, even if those organizations are competitors or have unaligned business motives. The next meeting is in London, this June. Please let us know if you are interested in collaborating!