On Friday, May 17, 2024, security researchers from ZONE published details of a vulnerability inherent to the DomainKeys Identified Mail (DKIM) email authentication protocol – one that can allow bad guys to take existing messages, modify or add content significantly, and re-inject those messages into the email stream and have them still pass DKIM authentication.
The team at Valimail quickly followed up with a detailed blog post that day, helping folks to understand this in more detail, what it has to do (or not) with BIMI, and what everyone should do to help mitigate the potential risks associated with the vulnerability.
Fast forward to Tuesday, May 21, and I’ve authored a followup blog post for the Valimail blog where I’ve focused more specifically on deliverability: the email service provider/mailbox provider and marketing sender impact of this vulnerability.
To summarize that: One or more email service providers were utilizing the “l tag” in DKIM in a way that is extremely problematic, giving bad guys a potentially easily discoverable and large corpus of email messages to take and republish with swapped out content. At the same time mailbox providers seem to be moving quickly to mitigate the issue inbound, with (I think) plans to treat DKIM-signed messages as though they are unsigned, if the signature header contains the “l tag.”
This means that marketing senders and/or affected email sending platforms now have two very important reasons to address this issue. Not only do they not want their domain and brand abused to send unwanted, spammy and/or unsafe content, even “legitimate” messages containing reference to the DKIM “l tag” messages will soon likely to see a degradation in deliverability as the mailbox providers will no longer give these messages any of the benefits associated with DKIM email authentication.
Indeed, Google now explicitly warns against using the "l tag" in messages, specifically highlighting that it makes messages vulnerable to spoofing. (Thanks to Autumn Tyr-Salvia for finding and sharing this new MBP warning.)
The good news is that folks have been working to identify and notify affected email service provider or marketing automation platforms. One of the most prominent ESPs affected has already released a hotfix to remove the “l tag” from their DKIM configuration, and I’m sure that more will follow.
The good people at the Certified Senders Alliance have also put together a blog post on this very topic, providing an overview and their take on what can and should be done about it. They raise a good point regarding implementing the “x tag” setting to expire DKIM signatures automatically -- it is something I hadn’t considered before.
Marketing senders and deliverability folks at email service providers and email automation platforms, please make sure that you’re not affected. Check your DKIM system configuration, if you can, or at least send a test message to Gmail (or to Steve Atkins’ Aboutmy.Email tool), and confirm that there’s no “l tag” in the DKIM signature header. The Aboutmy.Email tool will itself highlight presence of the “l tag,” as well.
Don't be overly alarmed! Thankfully, the percentage of mail observed in the wild with "l tag" utilizing DKIM signatures seems to be relatively low. But be aware, and test to make sure you're not sending via an affected platform. Better safe than sorry.
Disclaimer: I’m currently employed by Valimail, but I wanted to recap this here so that as many folks in the email community as possible are made aware of this issue, and that it can be something that gets addressed sooner, rather than later. Good luck and feel free to reach out to me if you have any questions or need help testing for the vulnerability.
On Friday, May 17, 2024, security researchers from ZONE published details of a vulnerability inherent to the DomainKeys Identified Mail (DKIM) email authentication protocol – one that can allow bad guys to take existing messages, modify or add content significantly, and re-inject those messages into the email stream and have them still pass DKIM authentication.
The team at Valimail quickly followed up with a detailed blog post that day, helping folks to understand this in more detail, what it has to do (or not) with BIMI, and what everyone should do to help mitigate the potential risks associated with the vulnerability.
Fast forward to Tuesday, May 21, and I’ve authored a followup blog post for the Valimail blog where I’ve focused more specifically on deliverability: the email service provider/mailbox provider and marketing sender impact of this vulnerability.
This means that marketing senders and/or affected email sending platforms now have two very important reasons to address this issue. Not only do they not want their domain and brand abused to send unwanted, spammy and/or unsafe content, even “legitimate” messages containing reference to the DKIM “l tag” messages will soon likely to see a degradation in deliverability as the mailbox providers will no longer give these messages any of the benefits associated with DKIM email authentication.
The good news is that folks have been working to identify and notify affected email service provider or marketing automation platforms. One of the most prominent ESPs affected has already released a hotfix to remove the “l tag” from their DKIM configuration, and I’m sure that more will follow.
The good people at the Certified Senders Alliance have also put together a blog post on this very topic, providing an overview and their take on what can and should be done about it. They raise a good point regarding implementing the “x tag” setting to expire DKIM signatures automatically -- it is something I hadn’t considered before.
Marketing senders and deliverability folks at email service providers and email automation platforms, please make sure that you’re not affected. Check your DKIM system configuration, if you can, or at least send a test message to Gmail (or to Steve Atkins’ Aboutmy.Email tool), and confirm that there’s no “l tag” in the DKIM signature header. The Aboutmy.Email tool will itself highlight presence of the “l tag,” as well.
Disclaimer: I’m currently employed by Valimail, but I wanted to recap this here so that as many folks in the email community as possible are made aware of this issue, and that it can be something that gets addressed sooner, rather than later. Good luck and feel free to reach out to me if you have any questions or need help testing for the vulnerability.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.