Selectors: how one domain holds many DKIM keys
The selector is the label that lets each sending service have its own key under the same domain, and it is what makes rotation possible without downtime.
A DKIM public key lives at a name built from the selector: <selector>._domainkey.<domain>. The signing server puts the selector in the s= tag of each signature, so the receiver knows exactly which record to fetch. Nothing enumerates selectors, so a receiver can only check the one it is told about.
Two services, two keys, one domain
google._domainkey.example.com TXT v=DKIM1; k=rsa; p=MIIBIjANBg...
s1.vendor._domainkey.example.com TXT v=DKIM1; k=rsa; p=MIIBIjANBg...Choosing selector names
- Name them after the service and a date or version: mailer-2026-03, not key1.
- Providers that manage their own keys will dictate the selector. Take theirs.
- Selectors are public. They leak nothing sensitive, but they do tell an observer which services you use.
The CNAME pattern
Many hosted senders ask for a CNAME rather than a TXT record, pointing your selector at a name they control. That hands them key management, including rotation, which is usually an advantage: they can roll keys without asking you to touch DNS.
s1._domainkey.example.com CNAME s1.domainkey.uXXXXX.vendor.netSince you cannot enumerate selectors from DNS, keep your own inventory of which selector belongs to which service. Without it, nobody can tell a live key from one left behind by a vendor you stopped using three years ago.
More on DKIM
What DKIM actually does
DKIM signs the message itself, so the proof travels with the mail. That is why it survives forwarding when SPF does not.
Publishing your first DKIM key
Generate a 2048-bit key, publish the public half as a TXT record, enable signing, and verify with a real message before you trust it.
Rotating DKIM keys without dropping mail
Rotation is a four-step overlap: publish the new key, switch signing, wait out mail in flight, then revoke the old one.