# DKIM selector: Definition and How It Works Source: https://wraps.dev/glossary/dkim-selector The DKIM selector is the label a sender chooses to name a specific public key at .\_domainkey., letting one domain publish and rotate several DKIM keys at once. ## Why the selector exists at all DKIM signatures name the selector they were signed with directly in the \`DKIM-Signature\` header (\`s=\` tag), so a receiver knows exactly which DNS record to fetch rather than needing a single fixed location per domain. That indirection is what makes key rotation possible without downtime: a new selector's record can be published and verified working before the old selector is retired, and multiple sending systems (marketing platform, transactional API, a third-party app) can each sign with their own selector under the same domain simultaneously. ## Discovery has to guess, because there is no fixed name Since the selector is arbitrary, a tool that wants to find a domain's DKIM records without being told the selector has to guess from known conventions. Wraps' email-check package ships both a quick list (~25 common selectors) and a full list (~100), checked in batches of 10 in parallel, stopping at the first valid, non-revoked hit unless verbose output is requested. That is a scan against likely names, not an exhaustive proof that no DKIM record exists. ## Some providers make guessing pointless AWS SES issues a randomly generated selector per verified identity rather than a fixed or even a predictable one, so no selector list will find it — the actual value has to come from the SES console or from the CNAME/TXT records SES itself instructs you to publish during domain verification. SendGrid and Mailgun use their own vendor-specific selector conventions that a generic scan may or may not include, which is why a DKIM check that comes back empty does not necessarily mean DKIM is missing. ## Selectors don't expire, but keys effectively do A selector's DNS record stays exactly as valid as the key it names — there is no separate expiration mechanism for the selector itself. What actually retires a selector is either deleting the record or publishing an empty \`p=\` tag against it, which is a deliberate revocation rather than an expiry. Rotation in practice means: publish a new selector, confirm outgoing mail is signing with it and validating cleanly, then revoke the old one. ## Why it matters Without the selector, DKIM would need one public key per domain, which makes rotation and multi-sender setups painful in exactly the way this scheme avoids. Knowing which selector a sending system actually uses — rather than assuming a common one — is usually the difference between a DKIM check that correctly finds nothing and one that incorrectly reports a false negative. ## How to check it ``` wraps email verify ``` ## Common questions ### Can a domain have more than one DKIM selector at once? Yes, and it's common. Each sending system — a marketing platform, a transactional API, an internal app — can sign with its own selector, and a receiver looks up only the one named in the specific message being verified. ### Why does my DKIM check find nothing even though DKIM is set up? The checking tool likely doesn't know the selector your provider actually uses. AWS SES and several other providers generate selectors that aren't in any common-selector list, so a scan against known names can miss a perfectly valid record. ### How do I rotate a DKIM key without breaking signing? Publish the new selector's record first, confirm outgoing mail is signing with it and validating, then revoke the old selector by emptying its p= tag or removing the record. Never remove the old selector before the new one is confirmed working.