DKIM key rotation: the security step most admins skip after setup

You set up DKIM, published the public key in DNS, verified alignment passes in your DMARC reports, and moved on. That was 18 months ago. The key is still the same one.

This is where most email security setups silently rot.

DKIM signing keys are long-lived credentials. Unlike a session token or an API key with a 30-day expiry, DKIM private keys typically sit in a mail server config file untouched for years. Nobody rotates them. Nobody even thinks about them unless something breaks.

The problem is that “nothing breaking” and “being compromised” look identical from the outside.

What DKIM is actually protecting

DKIM works by having your mail server cryptographically sign outgoing messages with a private key. Receiving servers fetch your public key from DNS and verify the signature. If it checks out, the message passes DKIM authentication.

The private key never leaves your mail server — or it’s not supposed to. That’s the trust model. The public key in DNS is safe to share; the private key must stay secret for the scheme to mean anything.

When your DKIM private key is compromised, an attacker can sign messages exactly as your mail server would. Those signed messages pass DKIM authentication. They pass DMARC. Spam filters treat them as legitimate email from your domain, because cryptographically they are. Phishing emails, fake invoices, credential theft lures — all signed, all passing, all yours.

You won’t see it in your DMARC reports either. Legitimate-looking DKIM passes don’t trigger failures. The only signal you might catch is unusual sending volumes from IPs you don’t recognize — if you’re looking closely enough.

Where DKIM private keys actually leak

Private keys don’t usually leak in dramatic breaches. They leak from the mundane things:

Server access logs and config backups. Mail server configs often end up in version control, S3 buckets, or backup archives. If your DKIM private key is in main.cf or a config file that gets committed to a repo, anyone with repository access has the key. Add a misconfigured bucket policy and it’s public.

Infrastructure exports and snapshots. When you snapshot a server for migration or take a VM image for testing, everything on disk goes with it — including the keystore where your DKIM key lives. Development and staging environments often inherit production keys this way.

Staff and contractor access. Whoever has shell access to your mail server has access to the private key. People leave companies. Access doesn’t always get cleaned up immediately.

Third-party service providers. If you use a managed email service, their infrastructure holds a copy of your key or signs on your behalf using their own infrastructure. Provider security incidents, credential leaks, or misuse by rogue employees can expose your signing capability without exposing your server at all.

None of these scenarios require a sophisticated attacker. Most of them require nothing more than an honest mistake.

RFC 6376, the core DKIM specification, explicitly recommends rotating signing keys regularly. The document suggests that keys should be rotated with a frequency appropriate to the sensitivity of the email traffic. Security frameworks like NIST and email security guidance from M3AAWG have echoed this for years.

The industry norm for high-security environments is 6 to 12 months. Many organizations do it yearly. Some do it never.

The argument against rotation is always operational overhead: you have to generate a new key pair, publish the public key in DNS, wait for propagation, update your mail server config to use the new key, and then retire the old selector. Do that wrong and email stops working. It feels risky.

The argument for rotation is that you eliminate the risk from every past exposure event. A key that gets rotated can’t be misused indefinitely. Rotation doesn’t require knowing whether the old key was compromised — it ends the exposure window regardless.

How DKIM rotation actually works

DKIM uses selectors to support multiple simultaneous keys. Your DNS record for a DKIM public key looks like this:

selector1._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=<base64-public-key>"

The selector (selector1 in this example) is referenced in the d= tag in the DKIM signature header of every signed message. To rotate:

Step 1 — Generate a new key pair. Using openssl or your mail platform’s key generation tool:

openssl genrsa -out dkim-private-2026.key 2048
openssl rsa -in dkim-private-2026.key -pubout -out dkim-public-2026.key

Step 2 — Publish the new public key in DNS under a new selector name:

selector2026._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=<new-base64-public-key>"

Leave the old selector in DNS for now. Don’t touch your mail server configuration yet.

Step 3 — Wait for DNS propagation. TTL on DKIM records is often 3600 seconds (1 hour). Wait at least that long before continuing.

Step 4 — Switch your mail server to sign with the new key and selector. For Postfix with OpenDKIM, this means updating KeyFile and Selector in your signing table. For managed services (SendGrid, Postmark, Amazon SES), this is a configuration change in their dashboard.

Step 5 — Verify the new key is working. Send a test email and check the DKIM signature header. The s= tag should show your new selector. Confirm DMARC passes with the new selector in your aggregate reports within 24–48 hours.

Step 6 — Retire the old selector. Once you’ve confirmed the new key is working and your DMARC reports show clean passes, remove the old selector’s DNS record. Any messages in transit that were signed with the old key will still verify until TTL expires.

The overlap period (steps 2–5) is what makes rotation safe. Both keys are valid simultaneously during transition. There’s no outage window.

Key length and algorithm

If you set up DKIM a few years ago, you may have a 1024-bit RSA key. That was the common recommendation at the time. Current guidance calls for at least 2048-bit RSA, or preferably Ed25519, which offers stronger security with shorter keys.

Ed25519 isn’t universally supported — some older receiving mail servers and some managed sending platforms don’t handle it yet. For maximum compatibility with existing infrastructure, 2048-bit RSA is still the safe default. If you know your sending and receiving environment well, Ed25519 is worth considering.

When you rotate, use the opportunity to upgrade key length if you haven’t already.

What this looks like in DMARC reports

DMARC aggregate reports don’t flag “your key is old.” They don’t tell you whether you’ve rotated recently or whether your private key has been compromised. The only thing they tell you is whether each message passed or failed DKIM at authentication time.

Where DMARC reports help is in detecting anomalies that might indicate key misuse: unexpected sending sources, unusual volumes from unfamiliar IPs, or DKIM passes from providers you haven’t configured. If you see DKIM passing from an IP range that doesn’t correspond to any service you use, that’s a red flag worth investigating.

DMARC Guardian’s IP attribution column maps sending IPs to known providers automatically — Google Workspace, Amazon SES, Postmark, Mailgun, and hundreds of others. If an IP is signing your DMARC-passing email and it maps to “unknown” or to a provider you don’t use, that’s the earliest available signal that something is wrong.

Building rotation into your process

Key rotation fails operationally when it’s a one-time manual procedure. The overhead of doing it ad-hoc is too high and it never gets prioritized.

The practical approach is to treat DKIM key rotation like a certificate renewal. Put it in a calendar. Set a reminder for 90 days before your target rotation date — enough lead time to generate the new key, publish it, and validate it before the switchover. Document the steps once. Follow them on schedule.

A 12-month rotation cycle is manageable for most teams. Six months if you have particularly sensitive email traffic (financial services, healthcare, B2B with high transaction value) or if you’ve had any staff turnover with server access.

The one thing that makes rotation cheaper is having clean documentation of which selectors you’re using, which servers or services are signing, and where the private keys live. If you don’t know those things right now, finding out is step zero.

DMARC Guardian shows your current DKIM selectors per domain and flags selectors that haven’t changed in more than 12 months. If you’re logging into the dashboard today, the DNS tab is the right place to start your audit.