a woman typing on her laptop

DKIM Key Rotation: Stop Leaving the Door Open

A compromised DKIM private key allows an attacker to send mail that passes DMARC. From anywhere, using any IP address, until you do a DKIM key rotation. SPF at least limits sending to addresses you’ve authorized. DKIM signatures carry no such geographic constraint. If someone has your private key, your domain name is theirs to use, and your receivers have no way to distinguish the traffic.

Many organizations don’t treat their DKIM keys as if this were true.

A Compromised Key Bypasses Your Entire Authentication Stack

DMARC requires a message to pass either SPF or DKIM, but not both. An attacker with your private key satisfies the DKIM requirement regardless of where the message originates. SPF failure doesn’t save you.

The response is straightforward: generate new 2048-bit RSA key pairs every six months.1 Deploy the new public key in DNS at least 48 hours before activating the corresponding private key because DNS propagation is not instantaneous, and a message signed with a key your receivers haven’t seen yet will fail verification. After activating the new key, leave the previous key’s DNS record unchanged for at least 7 days, up to 30 days, before retiring it.2 Verify new key deployment before retiring the old one.

Access to the private key itself belongs to the system administrators responsible for maintaining and rotating it — no one else.

2048-Bit Keys Are the Right Size, and the Rotation Window Is Not Arbitrary

NIST deprecated 1024-bit keys in 2013; they are no longer acceptable.3 Keys over 2048 bits increase CPU load without meaningful security improvement, given current cryptanalysis. 2048-bit RSA is the right answer for now.

Six months is the right rotation interval for the same reason: it limits exposure while avoiding the administrative overhead and error risk that come with more frequent rotation. It also keeps you ahead of advances in cryptanalysis without forcing continuous operational churn. Rotating whenever someone remembers or never rotating leaves the window of exposure open indefinitely.

Use date-based selectors — they make rotation history legible and audits tractable. Whatever naming convention you adopt, document it and apply it consistently across all your domains.

Verify the Deployment, Then Retire the Key Correctly

The failure mode that catches teams most often is not compromise — it’s a botched rotation. Deploy your new public key record, confirm propagation across major DNS providers, test signing with the new private key, and only then retire the old one. Staging exists for this reason.

When you do retire the old key, set the p field to empty (p=) rather than deleting the selector entry.4 A missing selector causes a hard DNS lookup failure; an empty p= field signals intentional revocation and fails gracefully.

An outbound mail stream that fails DKIM verification because you retired a key before its replacement was visible is entirely self-inflicted.

Footnotes

  1. 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). ↩︎
  2. Id. ↩︎
  3. Elaine Barker & Allen Roginsky, Nat’l Inst. of Standards & Tech., Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, NIST SP 800-131A Rev. 2, at 5 (Mar. 2019), https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf (last visited Feb. 6, 2025). ↩︎
  4. M3AAWG, supra. ↩︎

About the Author

Mickey
Mickey Consultant & Attorney

Mickey is a Consultant & Attorney with over 28 years of experience in Email Deliverability & Privacy Law. He has a strong background in email authentication infrastructure (SPF, DKIM, DMARC), ISP and mailbox provider relations, anti-spam policy and compliance, CAN-SPAM and state anti-spam law gained through overseeing the Abuse & Compliance team at Salesforce Marketing Cloud, originating the ISP relations role at Informz (now part of Higher Logic), and working in the fight against spam since 1997. He holds a B.A. in Government, a B.S. in Computer Information Systems, and a J.D. from the University of Houston Law Center. He is a certified CIPP/US professional and a certified CIPM professional.