The DKIM l= tag (lowercase “L”) in DKIM is an optional tag that specifies the length of the message body that should be signed. This can be considered a DKIM vulnerability since the l= tag enables partial signing of the message body. This can make it easier for threat actors to exploit DKIM-signed messages.
Let’s explore how DKIM works and why we do not encourage using the DKIM l= tag in your DKIM signature.
The Purpose of DKIM Body Length Limitations (l= tag)
DKIM (DomainKeys Identified Mail) is an email authentication protocol that ensures that your emails’ contents have not been altered during transit. It allows the receiver to verify that an email was indeed sent and authorized by the owner of that domain.
When intermediary servers forward your messages, they may change the message body. They may add additional information in the footer or to your message’s contents. The DKIM l tag was introduced to prevent your legitimate messages from failing DKIM, in case the contents were modified during forwarding or by mailing lists.
How the DKIM l= Tag Works
- Specifying Length: The l= tag is followed by an integer that indicates the number of bytes in the message body that are covered by the DKIM signature.
- Partial Body Signing: By specifying a length, only the first ‘n’ bytes of the body are included in the hash used to generate the DKIM signature. Any modifications to the body beyond this length won’t affect the DKIM signature verification.
Example: DKIM Signature with the l-Tag DKIM Vulnerability
Consider an email where the body is 1000 bytes long, but only the first 500 bytes are signed:
In this example, the l=500 indicates that only the first 500 bytes of the email body are included in the DKIM signature.
However, Europe-based leading domain registrar, Zone.eu’s team of analysts uncovered a serious vulnerability linked to the l tag in the DKIM signature. Overriding its benefits in mail forwarding scenarios, the l tag can be easily exploited by cybercriminals to send phishing emails that still pass DKIM checks.
DKIM l= Tag Vulnerability
We do not recommend using the DKIM l= tag as it can weaken your security posture, leaving your domain vulnerable to attacks even with email authentication configured.
An attacker can change the contents of your message body and attach malicious files or links in the unsigned section of the email that is beyond the byte scope defined in your “l” tag. When this email reaches your receiver, it will pass DKIM verification. Subsequently, if you have DMARC enabled for your domain, it will pass too.
Your receiver may open this email, trusting your domain name, and fall victim to yet another phishing attack! This may cause a serious breach of privacy, credential theft, and loss of trust in your credibility. If your customer loses money in the process, you may even be liable to provide financial compensation.
The Role of BIMI in Worsening This DKIM Vulnerability
BIMI is an emerging protocol, gaining popularity in both security and marketing industries due to its ability to append brand logos to emails. Not long back, major email providers like Gmail and Apple Mail extended support to BIMI, to make your emails look and feel professional and enhance security through visual verifications.
As forged messages sent from domains using the DKIM l tag in their signature pass DKIM and DMARC checks – the brand’s BIMI logo gets attached to these malicious emails as well! Now not only does this fake message sent from your domain name pass all authentication filters, but it also has your brand logo attached to it! This further amplifies the chances of receivers trusting its credibility.
Due to this potentially exploitative nature of the DKIM l= tag, Gmail in their Google Admin Workspace Help Centre heavily discouraged its usage. Here’s what Google has to say about it:
“If you’re setting up DKIM with an email system other than Google Workspace, do not use the DKIM length tag (l=) in outgoing messages. Messages using this tag are vulnerable to abuse.”
The risks associated with the DKIM l tag are further highlighted in RFC 6376 section 8.2 titled “Misuse of Body Length Limits (“l=” Tag)”. RFC warns users that specifying the l tag in your DKIM signature may lead to users accessing malicious email content without any warning. RFC urges DKIM signers to take extra caution in the presence of this tag and also preaches assessing servers to completely disregard DKIM signatures with an l= tag specified.
Check Your DKIM Signature for l-Tag DKIM Vulnerabilities
It is essential to first determine whether your domain is vulnerable. To do so we have listed below a few methods you can use:
Manual Method: Checking Original DKIM Signature Headers
1. Send a blank email to yourself (in this case we are taking the example of a Gmail user)
2. Open this email.
3. Go to “more options” which is denoted by three dots on the top right corner.
4. Click on “Show original”.
5. On the Original Message page, scroll down to see the raw headers.
6. Navigate to the “DKIM-Signature:” section and analyze the syntax. If you see the DKIM l= tag is present in the DKIM signature header, your domain is vulnerable. If it is absent, you are good and no action needs to be taken.
Automated Method: Using an Email Header Analyzer Tool
1. Sign up on PowerDMARC to take a free trial. Go to Analysis Tools > MailAuth Analyzer.
2. Copy the auto-generated email address and paste it as the recipient of a new test mail in your Gmail. Send the test mail.
3. Now head back to the portal and refresh the page. Click on the “view” icon in the Actions section to examine your results.
4. We instantly produce an aggregate report with information on your DKIM, SPF, and DMARC configurations and much more!
5. You can scroll down to view your DKIM signature header in raw and parsed formats. Here you will be able to determine whether your signature has l= tag present. If it is present actions need to be taken to remove this vulnerability.
Example: A DKIM Signature without the l-Tag DKIM Vulnerability
Preventing DKIM Vulnerabilities: What Are DKIM Best Practices?
If you wish to make the most of your DKIM protocol, here are some tips that our experts recommend:
- Avoid using the DKIM l= tag in your DKIM signature header.
- Get in touch with your email service provider to set you up with new DKIM public keys (without the l= tag) to add to your DNS.
- Rotate your DKIM keys periodically to ensure old keys with the l-tag vulnerability can be replaced by new keys without this vulnerability.
- You can use strong DKIM keys like 2048-bit keys, instead of 1024-bits to enhance the strength of your DKIM email security.
- Use a hosted DKIM solution to manage your DKIM selectors and keys, and monitor your DKIM authentication results from a single centralized dashboard.
- Create your DKIM keys using an automatic DKIM generator tool. This will help you avoid syntax errors that are easy to overlook.
Complementary Protocols to Use with DKIM
To increase DKIM’s efficacy, you can implement the following protocols (along with a bonus recommendation at the end!):
- Use ARC (Authenticated Received Chain) to ensure legitimate emails pass authentication checks even when forwarded or while using mailing lists. This automatically negates the need for the DKIM l= tag. ARC automatically preserves your message’s original headers to prevent false negatives.
- Configure fallback mechanisms like SPF and DMARC to increase your authentication accuracy and overall security.
- Enable DMARC reports to keep track of your email channels and sending sources. DMARC reports can help you detect malicious IP addresses and senders so you can take action against them quickly.
By adhering to these best practices, organizations can significantly enhance their email security posture and protect their domain reputation. While the l= tag can provide flexibility in handling emails that might be altered in transit, it can weaken your domain’s security. Hence, we along with various email providers, industry experts, and organizations do not recommend it. To explore more domain security and email authentication services, contact us today!
- PowerDMARC in 2024: A Year in Review - December 24, 2024
- Travel Cybersecurity Threats and How to Stay Protected - December 18, 2024
- Cybersecurity Best Practices for Digital Nomads in Japan - December 17, 2024