Private DKIM keys grant signing authority to your email servers. Many organizations treat these keys like disposable Post-it notes stuck inside a desk drawer, rotating them whenever someone remembers or leaving them forever. This casual approach creates risk.
Why This Matters
A compromised DKIM private key lets attackers send authenticated emails that pass DMARC checks, even if the SPF check fails. Unlike SPF, which at least limits sending to specific IP addresses, DKIM signatures work from anywhere. Once an attacker has your private key, they can impersonate your domain until you complete a full key rotation. To pass DMARC, a message has to pass either SPF or DKIM, not both, so compromised keys mean that an attacker can send messages “from you” that pass DMARC.
Proper DKIM key management requires specific actions. You need regular key rotation – generate new 2048-bit RSA key pairs every six months.1 Keep the previous key active for at least 72 hours during the transition.2 Most importantly, verify your new key deployment before retiring the old one.
Finally, your private key should remain private. The list of people who need access to the private key should be limited to the system administrators responsible for maintaining (and rotating) the key.
What Goes Wrong
Several issues appear repeatedly in DKIM deployments:
DNS propagation catches teams off guard. DNS updates don’t go everywhere instantaneously. Deploy your new public key records at least 24 hours before using the corresponding private key, although 48 hours is a better policy. Watch propagation across major DNS providers. Keep the previous key active until at least three days after propagation is complete, and you begin using the new key so that messages that got stuck in transit have time to arrive and get checked.
Key size selection becomes a guessing game. 1024-bit keys have been disallowed by NIST since 2013.3 Keys over 2048 bits increase CPU load without meaningful security benefits. The optimal choice is 2048-bit RSA keys ‒ at least for now.
Key rotation frequency is another important aspect. While some might consider it an overhead, rotating DKIM keys is essential for long-term email security. I recommend rotating keys every six months. This timeframe strikes a balance between security and operational practicality. Rotating too infrequently extends the window of vulnerability should a key be compromised. Conversely, excessively frequent rotations can create administrative overhead and increase the chance of errors. Six months aligns with industry best practices and provides a reasonable timeframe to mitigate potential risks while maintaining manageable operations. This also allows organizations to stay ahead of advances in cryptanalysis and ensure they are using sufficiently strong keys.
Selector naming creates unnecessary confusion. I suggest that you use date-based selectors for clear rotation tracking. Document whatever naming convention you choose, but maintain one format across all your domains.
What You Need to Do Now
Start by checking your current DKIM key age and strength. Document where those keys are stored and who has access. Create a rotation schedule with clear procedures. Test your deployment process in staging before touching production.
Legal Disclaimer: This technical documentation provides general information about email authentication implementation. It does not constitute legal advice. Consult qualified legal counsel regarding your specific situation.
Footnotes
- Messaging, Malware and Mobile Anti-Abuse Working Group, M3AAWG DKIM Key Rotation Best Common Practices, (2019), http://www.m3aawg.org/DKIMKeyRotation (last visited Feb 6, 2025). ↩︎
- I recently rotated my keys and left the old one up for two weeks, just to be sure. ↩︎
- Elaine Barker & Allen Roginsky, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, 5 (2011), https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-131a.pdf (last visited Feb 6, 2025). ↩︎
