Just a few days ago, we explained a DomainKeys Identified Mail (DKIM) authentication vulnerability that gained attention thanks to a recent security disclosure by Estonian security researchers.
Our prior article covered the basics, but today we’ll explain how this specifically impacts email service providers (ESPs), marketing automation platforms, and their customers.
What is the DKIM vulnerability?
Check our prior blog post for more details, but the quick recap is this: DKIM has an optional field, the l-tag, and it is meant to allow the DKIM signature to only cover the first part of an email message. When configuring DKIM settings for an outbound mail transfer agent (MTA, aka mail server), the admin could, for example, configure the l-tag to always be included with, say, a numeric value of 1, 100, or 1000. These examples would translate to the DKIM signature covering – affirming that the content remains unchanged since creation–for only the first, 1, 100, or 1000 characters of the email message.
This isn’t good; bad guys could then modify messages to add or edit content past the l-tag limitation point in a message, re-send that message, and still find that the DKIM signature passes checks. Messages would still seem to be fully DKIM authenticated when they have actually been tampered with.
Checking the data: Are senders affected?
While the l-tag was never intended to be used for email marketing or newsletter messages (and carries risks dire enough that they’re even referenced in the RFC), a few email service providers (ESP) and marketing automation platforms do seem to have implemented l-tag support. Whether intentional or not, whether a past test configuration or not, there is an indication that live mail messages are being sent today with the l-tag in place, and some of it with a very low value (l=1).
Looking at a four day snapshot of my own spamtrap network feed, I see just over one percent of messages utilizing the l-tag and less than half of those are utilizing an l-tag value of one. This mail is a mix of spam from unrecognizable bad guys and messages from legitimate marketing automation platforms (as almost all marketing senders show up to some degree in spamtrap feeds).
The good news is that rolling these up to identify the affected sending platforms tells us that there aren’t many out there sending mail using the l-tag at this time. The bad news is that the number is not zero; there appear to be a few affected email marketing platforms whose use of the l-tag means that their email messages are not protected against this vulnerability.
How senders are affected
The l-tag vulnerability means that bad guys can take specific email messages, modify them to add additional content, or change existing content, and then drop those messages back into the mail stream, and it’ll still pass DKIM authentication checks.
If bad guys take and repurpose your email messages and shuffle them off to new recipients, those recipients will be unhappy. That unhappiness will translate into spam reports, and those spam reports (and low engagement) will translate into spam folder placement or blocking. Let this go, and poor domain reputation will lead to deliverability issues, which is the big potential risk.
And even if you don’t think the risk of your messages being repurposed is great enough, a number of inbox providers have decided to take matters into their own hands. The disclosure indicates that Google and Yahoo are looking to take mitigating steps to help address the issue from the inbound side of things; IONOS 1&1 has said the same. I don’t have exact details of their intent, but in their shoes, I’d be quick to treat an email message as not having a DKIM signature if the inbox provider finds an l-tag present in the email message’s DKIM header. I strongly suspect that this is going to broadly become the case.
Meaning: Even if your messages seemed to deliver okay with the l-tag in place today, very soon they’ll start to fail DKIM checks.
Senders should never use the l-tag
I’ve been careful not to name-and-shame affected brands, companies, or platforms, and Valimail is making an effort to notify any entities that we find to be affected. But due to the nature of the issue and the fact that we’re not a large inbox provider, we’re not likely to stumble across all of them.
If you’re wondering if you could be affected, take a peek to check your email headers to make sure that there’s no l-tag in the DKIM signature header. And for those of you managing email service provider platforms, make sure you’re not including l-tag support in your DKIM signature configuration for you or any of your customers.
The net here is that if there was any practical value to the l-tag in a DKIM authentication, security concerns around this vulnerability mean that use of the l-tag in messages going forward will be nothing but problematic–both directly from bad guys attempting to exploit this vulnerability, and from inbox providers ignoring DKIM signatures of messages referencing the l-tag.
The good news
Thankfully, only a very small sliver of the email service provider community seems affected by this vulnerability. Chances are, you’re not using one of the platforms known to be utilizing the insecure “l tag” option in DKIM authentication. But it’s always good to be aware, and be able to test and confirm that the latest issue of the day is something that you won’t be affected by.
Need more help testing and monitoring for DMARC and email authentication compliance issues?
Al Iverson is Valimail’s Industry Research and Community Engagement Lead, bringing over 25 years of experience in email marketing, technology, and deliverability. He’s committed to helping people learn more about DMARC and adopt it beyond just the minimum requirements while also helping good people send email and get their email delivered.
