Every DKIM lookup starts with a selector. It is the least explained part of the standard and the most common reason a check “finds nothing” for a domain that signs mail perfectly well. This guide covers what selectors are for, how the record name is built, how to discover the selector a domain actually uses, and the conventions the big providers follow.
What a selector is
A selector is a label the sending server includes in each signature (the s= tag of
the DKIM-Signature header) that tells the receiver which key to fetch.
The receiver combines it with the signing domain (the d= tag) to build a DNS
name:
<selector>._domainkey.<domain>
s=selector1, d=example.com → selector1._domainkey.example.com
The TXT record at that name holds the public key. The _domainkey part is fixed by
the standard; the selector part is entirely the signer’s choice — any DNS-legal label works,
and receivers attach no meaning to the name itself.
Why domains have more than one
Selectors exist so one domain can publish several keys at the same time, and every serious mail setup uses that freedom:
- Multiple senders. Your corporate mail, your newsletter platform, and your support desk can each sign with their own key under their own selector, so a compromise or a rotation in one system never touches the others.
- Key rotation. Replacing a key safely means publishing the new key under a new selector while the old one keeps verifying in-flight mail. Two published keys is the normal state mid-rotation — see how to rotate DKIM keys.
- Dual algorithms. Senders adopting Ed25519 (RFC 8463) sign every message twice — an RSA signature under one selector, an Ed25519 signature under another — so both old and new receivers can verify.
How the well-known providers name theirs
| Provider | Typical selectors | Notes |
|---|---|---|
| Microsoft 365 | selector1, selector2 | Published as CNAMEs pointing into onmicrosoft.com; Microsoft rotates behind them. |
| Google Workspace | google | Default; admins can choose another name when generating the key. |
| Yahoo | s1024, s2048 | Named after the key length. |
| Fastmail | fm1–fm3 | Three CNAMEs delegated to Fastmail’s DNS. |
| iCloud Mail | sig1 | CNAME to Apple’s signing infrastructure. |
| Proton Mail | protonmail, protonmail2, protonmail3 | Three CNAMEs, rotated by Proton. |
| Mailchimp Transactional | mandrill | Plus k1-style selectors on some sending domains. |
Notice how often CNAME appears. Many providers ask you to publish a CNAME at the selector name pointing into DNS they control. That delegation is what lets them rotate keys for you without ever asking you to touch a record again — the TXT lookup simply follows the CNAME to wherever the current key lives. Our checker follows these chains automatically, so a delegated selector checks exactly like a direct one.
Date-based selectors
Organisations that rotate keys on a schedule often encode the date in the selector name:
s202607, 2023, 20230601, jan2026. It costs
nothing, makes the age of every key visible at a glance, and guarantees a fresh name for each
rotation so old and new keys never collide. Our record generator
suggests a date-based selector by default for exactly this reason.
How to find the selector a domain uses
There are two reliable approaches, and one convenient one:
1. Read a real message header
Send yourself an email from the domain, open the raw source (“Show original” in Gmail, “View
message source” in Outlook), and find the DKIM-Signature header. The
s= tag is the selector; d= is the domain it belongs to. This is
definitive — it is the selector actually in use, whatever it is called.
2. Ask the sending system
Your provider’s admin console (or your OpenDKIM/rspamd configuration) states the selector it signs with. Check that side matches what DNS publishes.
3. Sweep the common names
When you cannot see headers or configuration — auditing a client’s domain, say — our selector finder checks 30 common selector names concurrently and reports every key it finds, with a CSV export for your notes. A sweep can never be exhaustive (selectors can be any name), so treat “nothing found” as “none of the usual names”, not proof that DKIM is absent.
Selector pitfalls worth knowing
- The record name must match exactly. A key published at
selector1._domainkeydoes nothing for mail signed withs=selector2. Typos in either place are one of the most common DKIM failures we see — the troubleshooting guide covers the symptoms. - One record per name. Publishing two TXT records at the same selector makes verification unpredictable. If you need two keys, use two selectors.
- Selectors are per-domain.
selector1._domainkey.example.comandselector1._domainkey.example.orgare unrelated records; nothing is shared but the name. - Retired selectors should be revoked deliberately. Publishing an empty
p=tag tells receivers the key is withdrawn. Deleting the record outright works too, but the empty-key form is explicit and distinguishable from an accident.
Related reading
- What is DKIM? — the full signing and verification story.
- DKIM key length — what the key behind the selector should look like.
- How to rotate DKIM keys — selectors doing their real job.
- BIMI Studio deliverability checker — check DKIM, SPF and DMARC together.