10 Most Common Errors in DKIM Records

As part of our study on SPF, DKIM, and DMARC, we analyzed nearly 500,000 DKIM records. We discovered that about 16,000 of these records contained mistakes, rendering them invalid.

This article focuses on the most common errors with DKIM records that we encountered. We’ve put together this list to help you identify and avoid these pitfalls.

1. Multiple DKIM TXT Records

A domain’s public DKIM keys are stored in the domain’s DNS settings as TXT records under a specific _domainkey subdomain, with selectors used to differentiate between multiple keys. Each subdomain must only have a single TXT record with exactly one key.

In our analysis, we identified over 4,000 domains with two or more TXT records for the same selector, as illustrated in the example below:

$ dig +short TXT dkim._domainkey.pixabay.com
"v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDGB2jMemtae4C4+NWCPr1o4EOqrG68zHEJmEXLS2lUgzCitxGgccPk/l8bRYWT71CoE4TL9svN4GnpSsvLW5ICQcu EnMId6SaORivk2r0K8gKkrY/R1eDbs0FG0H/9ApUHKyAuNIvMFRJcQ4bKjDEccMKDPNkbecHo0eY5LEynLwIDAQAB"
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlxj3ojSWxMiNbAYyT7LNtP2hhU2DWDSRB07AeHM6qhxlZV0drzMe/L7b2RIpQ7bHvzfZ77TgMlcdXqa8ksPjuStCxVNcRoYUMR8+QAp7IgfF0KQNQxvu J1/EWRcd/Xx7qoR9rALO8PS0z/OKuh7BXguDGxW/eXHbGvlCT+AE2LwIDAQAB"

2. RSA Keys Shorter Than 1,024 Bits

While the DKIM specification originally permitted RSA keys of 512 bits, RFC 8301 updated the minimum requirement to 1,024 bits. This adjustment was made due to the vulnerability of 512-bit keys, which can now be cracked in just a few days using ordinary home computers. Despite this, our study found nearly 2,000 public RSA keys under 1,024 bits in size, including ones from prominent domains such as monster.com, quickbooks.com, and taskrabbit.com.

3. Invalid Characters

A common issue we encountered was the presence of characters that should not be there. A typical example includes newline characters (ASCII codes 10 and 13). Consider the DKIM record from mail._domainkey.outbrain.com, which illustrates this issue:

$ dig +short TXT mail._domainkey.outbrain.com
"v=DKIM1; k=rsa;\010p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDK7zalftNnD+ifE1fsTBb8XJNk9gNhFYnjBq7SYizupqQj/s2jWFBk3RLFmQ8GChmTIK5vpWKbropLe/70Zm1DFXiSOx2ipVVwL07TKXy027YlWCymwV05wSypu3CFR2WqunDKwt3WiiZNU6R51qQZzv2fvZt3aYkwuQNXMtKtCQIDAQAB\010"

Similarly, we identified dozens of records with consecutive semicolons, such as k=rsa;;p=MIGfMA0GCS…IDAQAB found at mailjet._domainkey.dihk.de. While some DKIM verifiers might accept a record like this, it is not compliant with the official DKIM specification.

Another example of invalid character usage was found in the DKIM record for mail._domainkey.teilar.gr. This record improperly included the PEM certificate headers (-----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----) within the RSA key: v=DKIM1; n=mail.teilar.gr; p=-----BEGINCERTIFICATE-----MIIEKjCCAx…7ckMk=-----ENDCERTIFICATE-----.

4. Truncated Keys

Base64 encoding converts a 1,024-bit key into approximately 216 characters, while a 2,048-bit key typically results in about 388 characters. Consequently, keys shorter than these expected lengths may indicate they are incomplete. An example can be seen in the DKIM record for mandrill._domainkey.lilly.com, where the key is significantly shorter than expected: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrLHiExVd55zd/IQ/J/mRwSRMAocV/hMB3jXwaHH36d9NaVynQFYV8NaWi69. Starting with MIGfMA0GC…, as a standard 1,024-bit key would, it spans only 98 characters, significantly below the anticipated 216. This discrepancy suggests that a portion of the key might have been inadvertently truncated when it was added to the domain’s DNS records.

5. Quoted DKIM Records

We observed a considerable number of DKIM records that were mistakenly enclosed within single or double quotes. Examples include the records found at google._domainkey.mariadb.org, which was enclosed in double quotes ("v=DKIM1; k=rsa; p=MIIBIjANBg…IDAQAB"), and mail._domainkey.enzu.com, which was enclosed in single quotes ('v=DKIM1; g=*; k=rsa; p=MIGfMA0GCS…IDAQAB').

6. Invalid Tokens in the Record

Similar to the issue with invalid characters that do not belong in DKIM records, many records also contain tokens that have improperly been included. For instance, we observed several records incorrectly starting with Value:, as seen in Value: v=DKIM1; k=rsa; p=MIGfMA0GCS…IDAQAB;, a record found at mandrill._domainkey.hcl.com.

7. Missing p Tag

Although the DKIM specification mandates that every DKIM record must include a p tag, we encountered several records lacking one. For instance, the records at mandrill._domainkey.reverbnation.com (v=DKIM1) and k1._domainkey.pcmag.com (k=rsa) were missing this essential tag. However, both records could have been considered valid if they had included an empty p tag, as in v=DKIM1;p= or k=rsa;p=, indicating that no key is available or the previous key has been revoked.

Additionally, we found several TXT records that contained only the public RSA key without any accompanying tags, such as the record from s1._domainkey.wcrf.org: MIICXgIBAAKBgQC1TA8WEHzdLFHAaV17KFW8qFakUzHeMbCLawIF4xT5stDpk/WF…lebt1CD0G3RIXyHxymbcaVj3POk3Wbv5JeKUiqzkV2Jv4A==.

8. Invalid Version Tag

DKIM records are not required to include a version tag, but if present — as recommended by the specification — it must be the first tag and strictly set to DKIM1. Therefore, the DKIM record at google._domainkey.softonic.com with k=rsa; v=DKIM1; p=MIGfMA0GCS…IDAQAB is invalid because the tags are in the incorrect order. Additionally, the version value must be in uppercase; a record like v=dkim1; p= from google._domainkey.algolianet.com, which uses lowercase, does not comply. Other examples of records with invalid version tags include:

9. Missing Semicolons

The individual tags within a DKIM record must be separated by semicolons. Consequently, records that only use a space character between two tags are invalid. For example, the record v=DKIM1; k=rsa p=MIGfMA0GCS…IDAQAB (smtp._domainkey.degiro.nl), which lacks a semicolon between k=rsa and p=, does not adhere to the required format.

10. Invalid Hash Algorithm

According to the original DKIM specification, both SHA-1 and SHA-256 hash algorithms were acceptable. However, since January 2018, with the adoption of RFC 8301, SHA-256 has become the sole permitted algorithm. Consequently, if a DKIM record includes the h= tag, it must explicitly specify sha256 as its value (h=sha256). Any deviation from this, such as v=DKIM1; h=rsa-sha256; k=rsa; p=MIGfMA0GCS…IDAQAB found at mail._domainkey.calmradio.com, or v=DKIM1; k=rsa; h=sha1; p=MIGfMA0GCS…IDAQAB; at dkim._domainkey.verticalresponse.com, renders the record invalid and leads to a PERMFAIL result.

Conclusion

In this article, we’ve explored the 10 most common errors encountered in DKIM records through our analysis of nearly half a million records. These errors, ranging from simple syntax issues to more complex configuration missteps, can significantly impact email deliverability and security.

It’s important to remember that DKIM is just one part of an email authentication strategy. Similar attention must be given to SPF and DMARC configurations to ensure protection against phishing, spoofing, and other email-based attacks. For more insights into common configuration errors and best practices, refer to our separate articles on the most common SPF configuration errors and the most common DMARC errors. Additionally, we recommend using our free DMARC Checker to verify if your DKIM/SPF/DMARC setup is correctly implemented.