DKIM Key Rotation: When and How to Change Selectors
DKIM key rotation boils down to three moves: publish a new public key under a new selector, switch your signing over to it, and delete the old record only once the mail already in transit has been verified. When is it worth the trouble? When your current key is 1024-bit and the DNS host accepts longer ones. When the private key may have been exposed. Or when the whole setup was rushed with default settings. That last one is more common than people admit: since February 2024 Gmail requires authentication from all senders and DKIM plus DMARC from bulk senders, so plenty of domains got their records in a hurry.
What is a DKIM selector and why does it make rotation possible?
A selector is just a label. It sits in the message signature and tells the receiving server which DNS record holds the public key. As the Google Workspace DKIM setup guide explains, the public key lives in a TXT record of your domain, while the private one stays on the mail server and signs each outgoing message. The record name follows the pattern selector._domainkey.yourdomain.com, and you will find the same label in the s= tag of the DKIM-Signature header.
And here is the useful part: several selectors can coexist on one domain. That is exactly what lets an old key and a new key stay valid at the same time. Google’s default prefix is google, and you enter a different one when that name is already taken.
When should you rotate DKIM keys?
Short answer: when the key is short, when the private key may have leaked, when a provider or an employee with access changes, and otherwise on a schedule you can actually keep. How often to rotate DKIM keys, then? Honestly, no single interval suits every team. Pick a rhythm that matches your capacity and write it down (a schedule nobody follows is worse than none). The usual triggers:
- a 1024-bit key still in use,
- a private key stored or shared insecurely,
- a move to another sending platform,
- leftover selectors from tools you no longer use,
- a current key whose age nobody knows.
There is a second benefit to a regular routine. It keeps the procedure rehearsed, so an emergency change is never your first attempt. And if the original configuration was done under deadline pressure, go back over the basics of authenticating a sending domain before you touch the keys.
Is your key long enough? Moving from 1024-bit to a 2048-bit DKIM key
Go with a 2048-bit DKIM key whenever your domain provider supports it. Keep 1024-bit only when the DNS host cannot store the longer value. Longer keys are more secure than shorter ones, simple as that, and a domain already signing with the weaker option can switch.
Not sure what you have? Look up the TXT record of the active selector and compare the length of the p= value, or read the setting in your sending platform. One practical snag: depending on the DNS panel, a long value may need to be split into several quoted strings within a single TXT record. My advice is to treat the upgrade as a rotation with a fresh selector. Don’t overwrite the existing entry.
How to do DKIM key rotation step by step
The whole thing in one breath: generate a new key pair under a new selector, publish the public half, wait for DNS, switch signing, verify, retire the old record. Now in detail:
- List every system that signs for the domain and the selector each one uses.
- Generate the new DKIM key with a new selector name.
- Add the new DKIM DNS record alongside the existing one.
- Confirm that it resolves publicly.
- Switch signing to the new selector.
- Send test messages and read the headers for dkim=pass and the new s= value.
- Keep the old record until mail in transit has been verified.
- Delete the old record and the old private key.
Name selectors with a date or a sequence, so the age of a key is visible later (future you will be grateful). Order matters too. Publish first, switch second. Why? Because a signature made with a key that receivers cannot find yet fails verification.
Each sending service has its own selector and gets rotated separately, whether it is a mailbox provider, a marketing platform or a transactional system. This bites hardest when you run transactional and marketing mail together. In MailCraft the sending domain is authenticated with SPF, DKIM and DMARC, so its selector belongs on that inventory as well.
How long should the old DKIM record stay in DNS?
Until every message signed with it has been delivered and checked. Then it goes. Delayed, queued, retried and forwarded messages get verified some time after sending, and a missing key turns them into DKIM failures. So base the overlap on your own queue and retry behavior, and on DMARC reports showing that the previous selector no longer appears.
But don’t leave it there forever either. Removing the record is what actually retires the key, because a leaked private key stays usable for as long as its public half is available. Suspected compromise? Shorten the overlap and accept some failures on mail still in transit.
What can go wrong during rotation and how to check the result
Most failed rotations trace back to DNS: a record that is malformed, published under the wrong name, or not yet visible when signing switches. The classics are a truncated key value, extra spaces or broken quotes, a record created on the wrong subdomain, and one sending system left off the list. Patience helps as well, because Google’s instructions for adding a key note that it can take up to 48 hours for DKIM authentication to start working.
Checking the result is easy. The message header should show dkim=pass with the new selector. A header with no DKIM line at all? Then messages are not being signed. Keep an eye on DMARC aggregate reports after the switch, too. And one more thing: the signing domain must still match the From address, otherwise DKIM passes but DMARC does not, which is the most frequent reason why DMARC alignment fails.
Make DKIM key rotation a routine, not an emergency
A short written record turns the next change into a checklist exercise. Nothing fancy. Note the selectors in use, which system signs with each, the key length, the creation date and who can access the private key. Campaigns and automations sent from MailCraft rely on the same authenticated domain, so that key deserves a line in the document too.
Put the next date in the calendar and reuse the same steps each time. And today? Check your current key length and plan the move to 2048-bit if the DNS host allows it. Once that first dkim key rotation is behind you, every later one is just a familiar chore.
FAQ
Does rotating a DKIM key affect deliverability?
Not if the new key is published before signing switches and the old record stays in place during the overlap. Receivers simply verify each message against whichever selector its signature names. Failures come from skipped steps, like pulling the previous record too early or forgetting one sending system.
Can two DKIM selectors be active on one domain at the same time?
Yes. Each selector is a separate DNS record with its own public key, so they don’t get in each other’s way. That is how multiple senders sign for a single domain, and how old and new keys overlap during a change.
What if my DNS host does not accept a 2048-bit key?
Try splitting the value into multiple quoted strings inside one TXT record first, since many panels reject the long entry only as a single string. If the host really cannot store it, use 1024-bit, which Google’s guidance on key length allows for exactly that situation. Afterwards, moving DNS to a provider that supports longer keys is worth a thought.
