Weak DKIM key

DKIM is the link that lets a recipient establish that a message genuinely comes from your domain and was not altered in transit. That assurance rests entirely on the key used to sign. If that key is too short, the check still exists but its outcome becomes unreliable. Here is why, and how to clean it up.

What is DKIM and where does the key sit?

DomainKeys Identified Mail (DKIM) adds a digital signature over the content and a number of headers to every outgoing message. You publish the matching public key in your domain’s DNS, under a name of your choosing called the selector. The receiving server fetches that key and verifies the signature with it.

We speak of a weak DKIM key when the key used is too short to make that check meaningful. In practice it is nearly always an RSA key of 1024 bits, sometimes shorter. The standard mandates a minimum of 1024 bits and recommends 2048; the common norm is now 2048.

The comparison with a seal on a letter works well here. The seal is there, the recipient checks it, and the process works as intended. Only the seal is simple enough in form that someone with the right equipment can make a copy. From that moment the seal proves nothing, while everyone still relies on it.

How do you check your DKIM key length?

Vulnerable:

sel1._domainkey.yourcompany.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

The key length can be read from the published value. A key starting with MIGfMA0GCSqGSIb3DQEB and totalling around 216 characters is an RSA key of 1024 bits. A 2048-bit key starts with MIIBIjANBgkqhkiG9w0B and is roughly twice as long.

If such a key is broken, an attacker can sign messages that pass your DKIM check. That is more serious than DKIM being absent, because the message then does not merely arrive but is actively confirmed as authentic, and thereby passes your DMARC policy too. A recipient checking everything correctly is told the message is genuine.

Safe:

# New 2048-bit key, with a new selector
openssl genrsa -out dkim-2026a.private 2048
openssl rsa -in dkim-2026a.private -pubout -outform PEM \
  | grep -v '^-----' | tr -d '\n'

; The record is split because one text block holds at most 255 characters
dkim2026a._domainkey.yourcompany.com. TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
                                             "7Xk2pQvR8xM1nZ0Yf1yqk8dK1vI0IuqC3dLm9Rt4Wp7Nx2Vb6Hs..." )

The new key deliberately gets its own selector. Switching over then proceeds seamlessly: you publish the new key, switch your mail server to signing with that selector, and remove the old one only after the last messages signed with it have been delivered. There is no moment at which the check fails.

Then build rotation into your regular maintenance. A selector carrying the date in its name makes the age of the key visible at a glance.

What is the impact of a weak DKIM key?

The severity is low to medium. Unlike a completely absent email configuration, there is no attack here that is simply executable: breaking the key requires considerable computing capacity and therefore an attacker with means and a motive.

Where the finding does gain weight is at organisations that make an attractive target for targeted fraud: financial service providers, notarial offices, organisations processing large payments. There the investment an attacker has to make is proportionate to what a credible, correctly signed email can yield.

What makes it notable is the inversion that occurs. Without DKIM, a forged message can at best be recognised. With a broken DKIM key, a forged message is actively confirmed as authentic: it passes the signature check, thereby passes your DMARC policy, and lands in the recipient’s inbox as verified mail from your domain. The measure then works against you.

How do you detect a weak DKIM key?

The check consists of retrieving the DKIM record for the selector in use and determining the key length. The selector can be read from the DKIM-Signature header of an email the organisation has sent; it appears there in the s= field.

Then it is examined whether multiple selectors are in use and whether old, short keys sit among them that were never cleaned up. Records for services the organisation no longer uses get attention too, because a key left behind at a former supplier is a risk in itself. Beyond that, which headers are signed is assessed: a signature not covering the From field offers considerably less than it appears. AssistSec assesses this as part of your email configuration as a whole, because the strength of the key only gains meaning in combination with an SPF record that enforces and a DMARC policy set to reject.

How do you prevent a weak DKIM key?

• Use an RSA key of at least 2048 bits for signing outgoing email.
• Split the DNS record into multiple text blocks when the key does not fit in one.
• Perform a key change with a new selector, so there is no moment at which the check fails.
• Rotate the key periodically, for instance every six to twelve months.
• Remove DKIM records for selectors and suppliers you no longer use.
• Make sure the signature covers at least the From field and the main headers.
• Store the private key with the same care as other secrets, in a key vault.
• Assess DKIM together with your SPF and DMARC configuration; the three only work as a whole.