DKIM Key Rotation: How to Do It Without Hurting Deliverability

Estimated reading time: 10 minutes

Most teams set up DKIM once, see dkim=pass in a test message, and never think about it again. That works fine until a private key leaks, a former vendor still holds a copy, or a security audit asks when the key was last changed and nobody can answer.

DKIM key rotation is the scheduled replacement of the key pair your mail is signed with. Done properly, receiving servers never notice. Done carelessly, it breaks authentication for part of your mail, and under a strict DMARC policy that mail gets quarantined or rejected. Below we cover when rotation makes sense, how to do it without a gap in authentication, and what to check once it’s done.

Key takeaways

• DKIM key rotation limits how long a stolen or weak key can be used to sign mail as your domain. It’s a security practice first.
• Mailbox providers tie reputation to your signing domain, not to a specific key. A clean rotation won’t raise or reset your reputation, but a sloppy one can cause DKIM and DMARC failures.
• Always publish the new key under a new selector and keep the old public key in DNS for at least a week after you switch.
• Use 2048-bit RSA keys. If you still have 1024-bit keys, they’re the first ones to replace.
• Every six to twelve months is a sensible schedule for most senders. Rotate right away after a suspected leak or a vendor change.
• Confirm the switch in message headers, DMARC reports and inbox placement tests before you remove the old key.

How DKIM keys and selectors work

DKIM relies on a key pair. Your sending server holds the private key and uses it to add a DKIM-Signature header to each outgoing message. The matching public key sits in your DNS as a TXT record, where any receiving server can look it up.

The receiver finds that record using two tags from the signature: d= (the signing domain) and s= (the selector). If a message is signed with d=example.com and s=mail2026a, the receiver queries mail2026a._domainkey.example.com. When the public key found there validates the signature, and the signed headers and body haven’t changed in transit, DKIM passes.

Selectors are what make rotation possible. A domain can publish as many selectors as it needs, each holding a different key. That means a new key can go live next to the old one instead of overwriting it, which is the whole trick behind a rotation with no downtime.

Why rotate DKIM keys at all

A DKIM private key is a credential. Anyone who has it can sign mail that receivers will accept as genuinely coming from your domain. Keys get exposed in ordinary ways: a compromised mail server, a config backup left in the wrong place, an admin who left the company, or an email platform you stopped using years ago that still holds a valid key.

Key strength matters too. RSA keys of 512 bits can now be factored with a few dollars of cloud compute, and 1024-bit keys no longer have much safety margin. The longer a key stays in service, the more time an attacker has to steal or crack it, and the more mail it can be abused for.

There’s also a practical benefit. A team that rotates on a schedule knows exactly which systems sign mail and how to swap a key quickly. When an incident forces an emergency rotation, that’s not the moment to learn the process.

Where deliverability comes in

Rotation on its own won’t move your inbox placement. Gmail, Yahoo, and Outlook build reputation around the signing domain and the visible From domain, not around a particular key. Swapping one valid 2048-bit key for another changes nothing in how your mail is scored.

The deliverability stakes are on two other sides:

• A leaked key lets someone else spend your reputation. Phishing or spam signed with your key passes DKIM, can pass DMARC, and the complaints it generates count against your domain.
• A broken rotation fails authentication. If the selector in the signature doesn’t resolve, or points to the wrong key, DKIM fails. When SPF isn’t aligned with your From domain, which is common with ESPs that use their own return-path, DMARC fails too. Under a quarantine or reject policy, that mail goes to spam or bounces. Gmail and Yahoo also require bulk senders to pass DMARC, so a gap in DKIM shows up quickly in your numbers.

In short, rotation protects your domain’s reputation from misuse. Doing it carefully is what keeps it from becoming a deliverability problem in its own right.

How often to rotate, and which key length to use

The most widely cited industry guidance is to rotate at least every six months. Some ESPs go further: Mailgun’s automatic rotation runs every 120 days by default. For a typical business sender with 2048-bit keys, a six-to-twelve-month cycle is reasonable. What matters more than the exact number is that the schedule exists and someone owns it.

Situation	When to rotate
Suspected key exposure, server breach, or a person or vendor with key access leaving	Immediately
Still signing with a 1024-bit key	As soon as possible, moving to 2048-bit
High-volume, regulated or frequently targeted sender	Every 3 to 6 months
Typical business sender on 2048-bit keys	Every 6 to 12 months
Stopped using an ESP	Remove its DKIM records once it no longer sends for you

For key length, 2048-bit RSA is the standard to aim for. The DKIM specification requires at least 1024 bits and recommends 2048, and receivers treat anything under 1024 as a failed signature. Keys longer than 2048 bits are rarely worth it, since they make DNS records unwieldy without a practical gain today.

One technical catch: a single string inside a DNS TXT record holds at most 255 characters, and a 2048-bit public key is longer than that. The record has to be split into several quoted strings that receivers join back together. Most DNS providers handle this automatically, but some web panels quietly cut the key short. Always check the published record after you add it.

How to rotate a DKIM key without breaking authentication

If you manage DKIM records yourself as TXT records, the safe process is the same whatever your mail server is. The core idea: the new key goes live before the old one leaves, and the two overlap.

1. Generate a new 2048-bit key pair. Do it in your mail server, your provider’s console, or with a tool such as OpenSSL. Keep the private key out of tickets, chat threads, and shared drives.
2. Pick a selector name you’ve never used. Date-based names like s202610 or mkt-2026q4 make it obvious which key is current and when it was created.
3. Publish the new public key as a TXT record at newselector._domainkey.yourdomain.com. Leave the existing record exactly as it is.
4. Wait for DNS to catch up. Query the new record from a couple of public resolvers and make sure the full key comes back intact. Propagation is often quick, but give it up to 24 to 48 hours if your TTLs are long.
5. Switch signing to the new private key and the new selector.
6. Check real messages. Send to a few mailboxes at different providers and confirm the Authentication-Results header shows dkim=pass with your domain and the new selector.
7. Keep the old public key published for at least seven days. Messages already queued, retried by a busy server, or checked late by a forwarding system still need the old key to verify. Two weeks is a comfortable margin.
8. Retire the old key. Remove the old TXT record, or first replace it with an empty key value (p=), which tells receivers the key has been revoked. Then securely delete the old private key.
9. Log the change. Note the selector, key length, date and the systems that use it, so the next rotation, or the next person, starts from facts.

Mistakes that cause DKIM failures during rotation

Most rotation problems come from a handful of predictable slips:

• Overwriting the current record or reusing a selector. Mail signed with the old key now finds a different public key under the same name and fails verification.
• Removing the old key the same day. Queued, retried and forwarded messages still point to the old selector.
• Switching signing before DNS has propagated. For a while, receivers can’t find the new key at all.
• A truncated or mangled 2048-bit key. Missing characters, stray spaces or bad quoting break the record while it still looks fine at a glance.
• Forgetting a sending source. Your CRM, help desk or billing system may sign with its own selector. Keep an inventory so nothing is left on an old or abandoned key.
• Leaving old ESP records in DNS. A platform you no longer use can still sign as your domain.
• Rotating right before a big send. Pick a quiet week, not the days before a product launch or a holiday campaign, so a mistake hits low volume and gets caught early.

How to verify the rotation and monitor what follows

A single dkim=pass on a test message is a good start, not proof that every stream is fine. Check three things before you retire the old key.

Message headers. In a received message, the Authentication-Results header should show dkim=pass, with header.d set to your domain and header.s set to the new selector. Check dmarc=pass on the same line, since that’s the result receivers act on when your DMARC policy is enforced.

Inbox placement. Authentication can pass while placement still shifts, especially if a rotation coincided with other changes. Running the same campaign through GlockApps Inbox Insight before and after the switch shows where messages land across Gmail, Outlook, Yahoo, and other providers, along with their SPF, DKIM, and DMARC results, so you can confirm nothing moved.

DMARC aggregate reports. These are the best view of real traffic, because they cover everything sent under your domain rather than a few test messages. During the overlap, DKIM results for the old selector should fade toward zero while the new one takes over. A source still signing with the old key, or a sudden drop in DKIM pass rates, points to a system that was missed. Raw XML reports are hard to read in bulk, so use a reporting tool that groups results by sending source.

Only when all three look clean should the old key come out of DNS.

After that, keep an eye on the records themselves. DKIM rarely breaks on its own; it breaks when someone edits DNS, a provider changes a setting, or a cleanup removes a CNAME that looked unused. GlockApps Uptime Monitor checks your SPF, DKIM, and DMARC records on a schedule and alerts you by email, Slack, or Telegram as soon as one changes, so a broken key is caught in minutes rather than after a week of failed authentication.

Conclusion

DKIM key rotation won’t lift your inbox placement, and it isn’t meant to. Its job is to keep a stolen or aging key from being used against your domain, and with it, against the reputation you’ve built. The process itself is simple: new selector, overlap period, verification, then retirement of the old key. Put it on a calendar, keep an inventory of everything that signs your mail, and check headers, DMARC reports and placement before you delete anything. Handle

FAQ