DKIM Key Rotation Without Downtime: The Dual-Selector Playbook

Rotating a DKIM key sounds risky because signing keys sit in the critical path of every message you send. Done the naive way, swapping a key can strand in-flight and forwarded mail that was signed with the old key, causing authentication failures that push your messages to spam. The fix is the dual-selector overlap: you publish a brand new public key under a new selector, keep the old selector live, cut your signer over to the new key, then wait long enough for every cached and queued message to clear before you retire the old record. This guide walks through why and how often to rotate, the exact DNS steps, how to split a 2048-bit key across TXT strings, and a selector naming scheme that keeps the whole thing auditable.

Why and how often to rotate DKIM keys

A DKIM key is a signing secret. The longer it lives, the larger the blast radius if it leaks, and the more likely it was generated at a weaker length. Two triggers drive most rotations:

• Upgrading key length. RFC 8301 requires at least 1024-bit RSA and recommends 2048-bit. If you are still signing with a 1024-bit key from years ago, moving to 2048-bit is the single most common reason to rotate.
• Periodic hygiene. The widely cited cadence is every 6 to 12 months. Shorter cycles limit exposure; longer than a year is hard to justify for a key that signs production mail.

You should also rotate immediately on any suspicion that a private key was exposed, and whenever you change email service providers that generate their own keys.

Anatomy of a DKIM DNS record

A DKIM public key lives in a TXT record at selector._domainkey.yourdomain.com. The selector is an arbitrary label you choose; it lets one domain hold many keys at once, which is exactly what makes overlap possible. A typical record looks like this:

s2026a._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

The p= value is the Base64-encoded public key. The matching private key stays on your mail server or with your sending platform and is never published. When a receiver validates a message, it reads the selector from the message's DKIM-Signature header, looks up that exact TXT record, and checks the signature against the published p= key.

The dual-selector rotation playbook

The entire point is that old mail must keep validating while new mail starts using the new key. Because two selectors can coexist, you never have a moment where a signed message has no matching DNS record. Follow these steps in order.

Step 1: Generate a new key under a new selector

Create a fresh 2048-bit key pair and assign it a new selector that does not collide with the current one. Keep the old private key and selector untouched for now.

openssl genrsa -out s2026b.private 2048
openssl rsa -in s2026b.private -pubout -outform der 2>/dev/null \
  | openssl base64 -A

Step 2: Publish the new public key in DNS alongside the old one

Add the new TXT record at s2026b._domainkey. Do not remove s2026a. You now have two valid DKIM records live at the same time. Confirm the new one resolves before touching the signer:

dig +short TXT s2026b._domainkey.example.com
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..." "...AQUAA4GNADCBiQKBgQC..."

Step 3: Switch the signer to the new key

Update your mail server or sending platform so outbound messages are signed with the new selector and private key. From this moment, new mail carries s2026b in its DKIM-Signature header, while any message signed earlier still references s2026a.

Step 4: Wait for overlap to drain

This is the step people skip, and it is the one that prevents downtime. Wait at least 48 hours. That window covers three things: messages still queued or in transit that were signed with the old key, mail sitting in forwarders and mailing lists that will be delivered late, and DNS resolvers that cached the old record. As long as both records exist, every one of those messages validates against the selector it names.

Step 5: Retire the old selector

Once the overlap window has passed and your DMARC aggregate reports show no mail still signing with the old selector, delete the old TXT record and securely destroy the old private key. Rotation complete, with zero authentication failures.

Splitting a 2048-bit key across TXT strings

A 2048-bit public key is roughly 392 characters of Base64, but a single DNS TXT character-string cannot exceed 255 bytes. The solution is not multiple TXT records; it is multiple quoted strings inside one TXT record. DNS concatenates adjacent strings with no separator, so the resolver rebuilds the full key automatically:

s2026b._domainkey IN TXT ( "v=DKIM1; k=rsa; "
  "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9kR2..."
  "...8aF1qP0bX7wZ3mY6nQ2rT5vU9cE4dG7hJ0kL3mN6pQ=" )

Keep all the strings in the same record and do not add spaces between the pieces of the key itself. If you accidentally create two separate TXT records at the same selector, validators may see conflicting keys and fail.

A selector naming scheme that scales

Random selectors make rotations hard to audit. A date-encoded scheme tells you at a glance which key is current and when it was issued. Two common patterns work well:

Pair the naming scheme with separate selectors for separate mail streams. Your transactional platform, your marketing platform, and your own SMTP relay should each sign with their own selector, so rotating one never touches the others.

Common mistakes to avoid

• Deleting the old record too soon. If you remove s2026a the moment you switch signers, any delayed or forwarded message signed with it fails DKIM.
• Reusing the same selector for the new key. Overwriting the existing record breaks validation for mail already signed against the old key value.
• Forgetting to raise the key to 2048-bit. A rotation is the natural moment to drop 1024-bit keys for good.
• Not checking DMARC reports before retirement. Aggregate reports confirm whether any source is still signing with the old selector.

When you finish a rotation, verify both selectors resolve and that live mail passes alignment before you retire anything. Run the new record through the Valla DNS propagation checker to confirm every resolver is serving it, and pair this with our other email-authentication guides in the Valla DNS learning hub on SPF, DKIM basics, and reading DMARC reports to keep your whole sending setup healthy.