A DKIM selector is a label that tells the receiver where to find the public key for a signature. The key lives in DNS at selector._domainkey.yourdomain. Because each selector is a separate key, you can publish a new key, switch signing to it, and retire the old one without a gap in verification.
How a selector is used
Each DKIM signature carries two tags that matter here: d= names the signing domain and s= names the selector. The receiver builds a DNS name from them and fetches the TXT record at s._domainkey.d.
RFC 6376 describes selectors as the way to support several concurrent public keys per signing domain. Its examples include delegating signing to a partner for a limited time, or giving different mail streams different keys. In practice, each sending service you use usually gets its own selector, which is why you will see several in DNS.
A selector can be any string made of valid DNS labels. Many teams put a date in it, such as a year and month, which makes rotation records easy to read.
Why selectors make rotation safe
RFC 6376 includes operational advice that is worth following closely. Verifiers may check a signature late, perhaps when the final recipient opens the message. So a signer should not sign with a key whose public record is about to be removed.
The recommended pattern in the RFC: when rotating to a new key pair, start signing with the new private key immediately, and keep the old public key published for a reasonable validation interval before removing it.
Rotation steps
- Generate a new key pair. Use at least 2048 bits if your DNS provider and signing service support it. See the key size post.
- Publish the new public key under a new selector name.
- Wait for DNS to propagate, then test that the record resolves.
- Switch your signer to the new selector.
- Send test messages and confirm DKIM passes and aligns at a major mailbox provider.
- Leave the old selector published for a validation window, then delete it. RFC 6376 also says a key record with an empty p= value means the key has been revoked, which is another way to retire it.
If you use a third-party sender that publishes your selector through a CNAME, the vendor handles rotation. Your job is to keep the CNAME in place.
Common problems
- Deleting the old key too early. Mail still in transit or read later fails verification.
- Truncated TXT records. Long keys must be split into quoted strings inside one record. A copy and paste error here is common.
- Forgotten selectors. Old selectors for retired vendors are live signing keys with no owner. Removing them shrinks your exposure.
- No inventory. Keep a table of selector, owner, key size and created date.
Quick check
Do I need a different selector for every email service?
It is the usual practice and easier to manage. Separate selectors let you rotate or revoke one service without touching the others.
How often should I rotate DKIM keys?
The RFCs do not set a schedule. Pick an interval your team can sustain, rotate on any suspected exposure, and when a vendor or employee with access to a key leaves.
Sources
Last reviewed: 19 October 2026.
