DKIM key rotation explained, with zero downtime using multiple selectors
A DKIM private key that never changes is a standing liability: the longer it lives, the more places it has been copied to, the more backups it sits in, and the larger the window in which a leak lets someone sign mail as you. Rotation closes that window on a schedule.
Why rotate at all
DKIM works by signing outbound mail with a private key and publishing the matching public key in DNS at a named selector. Anyone holding the private key can produce mail that passes your DKIM. Keys leak through old servers, departed staff, misconfigured secret stores, and forgotten backups. Rotating every six to twelve months means a key that leaked quietly is only useful for a bounded time, and it forces you to confirm that your signing pipeline can actually swap keys before you need to in an emergency.
The selector is the whole trick
The reason rotation can be seamless is that the selector lets you publish more than one public key at once. A DKIM DNS record lives at selector._domainkey.yourdomain.com, and the signing header names which selector verified mail should check:
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=key2026a; ...
Because the selector is named in every signed message, two keys can coexist. Receivers always look up the selector the message points to, so old mail still in transit verifies against the old key while new mail verifies against the new one.
Zero downtime rotation, step by step
- Generate a new key pair with a fresh selector name, for example
key2026b. - Publish the new public key in DNS at
key2026b._domainkey. Do not touch the old selector yet. - Wait for DNS to propagate everywhere, which means waiting out the TTL on the record, not just the few seconds it takes to save.
- Switch your mail system to sign with the new key and the new selector.
- Leave the old selector published for a grace period so messages already queued or delayed still verify.
- After the grace period, remove the old selector from DNS.
The grace period matters because mail can sit in retry queues for days. Pulling the old selector too early makes delayed legitimate mail fail DKIM.
Key length
RSA keys below 1024 bits are rejected or ignored by many receivers and must not be used. The practical floor is 1024 bits, the sensible default is 2048 bits, and 2048 is what you should publish unless a specific constraint forbids it.
| Key size | Status |
|---|---|
| 512 / 768 bit | Insecure, rejected |
| 1024 bit | Minimum accepted, avoid for new keys |
| 2048 bit | Recommended default |
| 4096 bit | Strong, but some DNS setups struggle with the record size |
One DNS gotcha with 2048 bit keys: the public key string can exceed the 255 character limit of a single DNS TXT string, so it must be split into multiple quoted strings within the same record. Most providers handle this, but verify the record resolves as one key after publishing.
Generate a fresh key pair and the matching DNS record with the DKIM Generator, then follow the selector swap above to rotate without dropping a single message.