Close this search box.

DKIM : Do you use the L tag? Danger!

Unfortunately, email deliverability incidents doesn't always come from where we think it will! During the month of May 2024, an old security flaw linked to authentication DKIM for a time undermined the BIMI (see Brand Indicators for Message Identification)! As proof of this, Google deactivated BIMI on desktop and mobile applications between May 26th and 31st (I was able to see for myself) and strongly advises against using the tag l= in your DKIM signatures. I suggest you take a look at the origin of this flaw and check whether you're using it in your emails.

DKIM: Where does the security flaw come from?

On May 17, analysts from (an Estonian registrar and hosting company) have published an article on a security flaw which concerned the DKIM signature. This vulnerability, which has existed for over 10 years, allows an attacker (e.g. a malicious hacker) to create and send false emails (e.g. phishing) with DKIM, DMARC and therefore BIMI validation!

DKIM kesako? DKIM - or DomainKeys Identified Mail - is an email authentication standard that uses a cryptographic signature system to guarantee message integrity from the moment it is sent to the moment it is received by a recipient.

This DMARC validation on a phishing email would be perfectly valid, since if the DKIM key is validated and aligned, the email will be DMARC-compliant (only SPF or DKIM is sufficient to validate DMARC) and the remote server will distribute the fake email as a legitimate one.

Coming back to this DKIM vulnerability, it concerns the optional tag l= (l for length, its value being an integer) and corresponds to the number of bytes in the e-mail that will be signed by DKIM. This means that a hacker could very well exploit the unverified part of the email to insert his own malicious code!

Representative diagram published by on its article dedicated to the vulnerability of the l= tag.
What's it for? Originally, this l= made it possible for the DKIM key to survive when redirecting an email in the event of content modification during transfer.

Even though this flaw is long-standing, Google has taken it seriously. strongly recommends not to use this tag on its DKIM key.

Do not use the DKIM length tag (l=) in message headers. This tag makes messages vulnerable to spoofing.

How do you check whether you are using the l= tag on your DKIM key?

The best way to find out if you may be affected by this vulnerability is to check the header of one of your emails and look at the DKIM signature to see if it has (or not) the tag l=.

DKIM signature without the l= tag

DKIM-Signature : v=1; a=rsa-sha256; s=mail; t=1718359739; c=relaxed/relaxed;; q=dns/txt; bh=UAAZMuYNBKK...;

DKIM signature with l= tag

DKIM-Signature : v=1; a=rsa-sha256; s=mail; t=1718359739; l=1000; c=relaxed/relaxed;; q=dns/txt; bh=UAAZMuYNBKK...;

In this second example, the value of the l= (l=1000) indicates that the first 1000 bytes of the email will be signed with DKIM and verified by the remote server. The rest of the content will be ignored.

Following this announcement, I started checking our customers' domains and various emails received from different routers to see if I could find this famous tag l= in a header... And unfortunately, I couldn't find any signature with the tag (which is a good thing after all). On the other hand, Al Iverson (cf. founder of the famous blog Spamresources) found an email with the DKIM signature tag l=. So there's reason to be alarmed by the configurations of certain advertisers!

Sources for this article

- :
- Valimail :
- Spamresources :

The author

Laisser un commentaire

Your email address will not be published. Les champs obligatoires sont indiqués avec *