DKIM selectors: what they are, how to find yours, and when to rotate

Somewhere in a DKIM setup flow — a DNS host's form, a checker tool, a platform's verification page — you've been asked for a "selector", with no explanation of what one is or where you'd find yours. The domain field is obvious. The selector field is the one people paste wrong things into.

Here's the missing explanation. A selector is the label that lets one domain publish many DKIM keys at once. When a server signs a message, it stamps the signature with the selector it used; when a receiver verifies, it combines that selector with your domain to look up the exact public key it needs. Selector plus domain equals key location. That's the entire concept — the rest of this guide is what follows from it.

Where the selector lives

It appears in two places that must agree.

In the message, inside the DKIM-Signature header, as the s= tag:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1;
    h=from:to:subject:date; bh=4X0e...; b=KpW3...

In your DNS, as the first label of the record's hostname. The receiver takes s=s1 and d=example.com and queries:

s1._domainkey.example.com    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBg..."

The _domainkey part is fixed by the DKIM standard; the selector is whatever the signer chose. If the lookup returns a valid key and the signature verifies against it, the mail passes DKIM for example.com. If the selector in the header points at a hostname where no record exists, verification fails exactly as if you'd never set DKIM up — which is why a typo in the selector during DNS setup is a classic way authentication quietly breaks, and why checking requires knowing the selector at all.

How to find your selector

You can't query DNS for "all selectors on this domain" — DNS doesn't enumerate, which is also why generic domain scans can't audit DKIM without being told where to look. Three reliable ways in:

1. Read a real message. Send yourself an email from the platform in question, open the raw source, and read the s= tag in the DKIM-Signature header. Pasting the source into the email header analyzer does the parsing for you and shows which domain and selector actually signed. This is the ground-truth method: it reports what's happening, not what's documented.
2. Check the platform's settings. ESPs show the exact records they asked you to publish under domain authentication settings — selector included, usually as part of a hostname like em123._domainkey.yourdomain.com.
3. Try the platform's known defaults. Most services use fixed, documented selector conventions. Google Workspace uses google by default; Microsoft 365 uses selector1 and selector2; many ESPs use short fixed labels or per-account values. Punch selector and domain into the DKIM checker and a published key either resolves or it doesn't.

Why platforms use CNAMEs — and why you have several selectors

Modern ESP setups rarely have you paste a raw public key. Instead they ask for CNAME records:

em123._domainkey.yourdomain.com   CNAME   em123.dkim.espmail.net

The selector hostname on your domain aliases to a record the platform controls. Verification still works — the receiver's lookup follows the CNAME — but now the platform can rotate the underlying key without asking you to touch DNS again. That's the delegation pattern, and it's why platforms commonly ask for two or three selector CNAMEs up front: live key, standby key, and room to swap.

A domain sending through several services accumulates several selectors — one or two per platform, each pointing at a different key. This is normal and by design. It's the mechanism that lets your marketing platform, helpdesk and billing system all sign as your domain without sharing key material, and it's what DKIM alignment rides on when each of those services signs with d=yourdomain.com. How the three authentication protocols interlock is covered in our guide to SPF, DKIM and DMARC together.

Choosing selector names

When a platform assigns the selector, you have no choice to make. When you run your own signing — a mail server, or a platform that lets you name the selector — the string itself is arbitrary (letters, digits, hyphens; short is conventional), and the only naming scheme with real operational value is one that encodes rotation, like a date: 2026a, 2026b. The name isn't a secret and isn't security-relevant; don't overthink it. What matters is that the DNS record you publish uses precisely the selector your signer stamps into s=.

Rotation: the reason selectors exist

If one domain only ever needed one key, DKIM could have hardcoded a single hostname. Selectors exist so keys can be replaced without a gap in verification. The rotation sequence:

1. Publish a new key under a new selector (2026b) alongside the old one.
2. Switch your signer to sign with 2026b.
3. Wait out mail in transit — a few days is comfortable.
4. Remove or revoke the old selector's record. Publishing an empty p= value explicitly revokes a selector, which matters if the old private key may have leaked.

Periodic rotation limits the damage window of a stolen private key, and current sender-security guidance treats keys of at least 2048 bits with periodic rotation as the norm; Gmail refuses keys shorter than 1024 bits outright, per the requirements collected on our Gmail sender requirements page. CNAME-delegated setups get rotation done for you by the platform — one more reason the delegation pattern is worth preferring.

Troubleshooting selector problems

Symptoms map to causes fairly cleanly:

• dkim=fail with a body-hash mismatch — the message was modified in transit (footer injection, forwarding). Not a selector problem, despite appearances.
• DKIM fails as "no key for signature" — the s= in the header points at a hostname with no valid TXT record. Check for typos, an unpropagated DNS change, or the record published on the wrong domain level.
• Checker finds nothing, but you copied the record correctly — frequent culprit: your DNS host auto-appends the domain, so entering s1._domainkey.example.com created s1._domainkey.example.com.example.com. Enter only s1._domainkey in hosts that append.
• Signature signs the wrong domain — d= shows your ESP's domain, not yours. The selector setup you skipped is the custom- domain signing step; without it you have DKIM but none of the identity benefit, and DMARC alignment fails.

Each of these is visible from one delivered message's headers plus one DKIM checker lookup — a two-minute diagnosis once you know the selector is the thing to look up. For the wider authentication picture around it, start with email authentication explained.

Related guides

• DKIM checker — look up the published key for any selector and domain
• Email header analyzer — extract the selector and signing domain from a real message
• What is DKIM? — the signature mechanism the selector serves
• DKIM alignment — why the signing domain matters as much as the signature
• SPF, DKIM and DMARC — the three protocols as one system
• Gmail sender requirements — key length and authentication rules Gmail enforces

About this guide

Written by InboxRatio Editorial. Selector mechanics described here follow the DKIM specification (RFC 6376); platform-specific selector conventions are drawn from the providers' own setup documentation and are labeled as defaults, which individual accounts may override. No vendor sponsorship influences this guide.

Methodology

InboxRatio's deliverability tests send DKIM-signed mail from domains we configure ourselves, so selector setup and its failure modes are part of every test cycle's checklist. The protocol is documented in how we test; source rules are in sources.

Last updated

1 September 2026. Platform selector conventions reviewed quarterly against provider setup documentation.

Frequently asked questions

What is a DKIM selector in simple terms? A label that names one specific public key among the several a domain can publish. The signature in each message carries the selector (s=), and receivers combine it with the signing domain to look up selector._domainkey.domain in DNS and fetch the right key.

How do I find my domain's DKIM selector? Send yourself a message from the platform in question and read the s= tag in its DKIM-Signature header — the email header analyzer will extract it. Platform settings pages and documented defaults are the backup routes.

Can a domain have multiple DKIM selectors? Yes, and most sending domains do — typically one or two per service that signs mail for them. Each selector resolves to its own key, so services never share private keys.

Does the selector name affect deliverability? No. Receivers treat the selector purely as a lookup label; no filter scores you on what it's called. What breaks deliverability is a selector mismatch — signing with one label while DNS publishes another.

What's the difference between the selector and the DKIM record? The record is the TXT entry containing the public key; the selector is the first label of the hostname where that record lives. One names, the other contains.

How often should DKIM keys be rotated? For self-managed keys, current practice favors rotation on a regular schedule — commonly every six to twelve months in provider guidance — and immediately on any suspicion of key compromise. CNAME-delegated setups let your platform handle it.

Next time a form asks for a selector: pull a real message, read s= from the signature header, and verify the key it points to resolves — thirty seconds in the DKIM checker settles it.