What is a DKIM selector?
A domain can have any number of DKIM keys published at once, and receivers need to know which one to use for the message in front of them. The selector is the label that answers that. It is a small piece of the design, and almost every "DKIM isn't working" question turns out to be about it.
If DKIM itself is new to you, start with What is DKIM?.
Where the selector lives
It appears in two places, and they have to agree.
In the message, inside the DKIM-Signature header, as the s= tag:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google;
h=from:to:subject; b=dzjK4h1p...In DNS, as a DKIM selector record — a TXT record at a name built from the selector and the signing domain:
<selector>._domainkey.<domain>
google._domainkey.example.comThe receiver reads d= and s= from the signature, constructs that name, fetches the public key, and verifies. That is the entire lookup. If the record is missing or malformed, verification fails immediately — the signature is not "weak", it is unverifiable.
The _domainkey label is fixed and case-insensitive. The selector itself is chosen by whoever generated the key, is case-insensitive too, and carries no meaning to the protocol — google, k1, s1, 20230601 and mailchimp are all equally valid.
Why every sender gets its own
Multiple DKIM selectors on one domain are normal, not a mistake. You do not have "a DKIM key" — you have one key per sending platform, each under its own selector, all published on the same domain at the same time.
| Sender | Typical selector | DNS name |
|---|---|---|
| Google Workspace | google | google._domainkey.example.com |
| Microsoft 365 | selector1, selector2 | selector1._domainkey.example.com |
| SendGrid | s1, s2 | s1._domainkey.example.com |
| Mailchimp | k1 | k1._domainkey.example.com |
This is the point of selectors. Each platform holds a private key it will never share, so each needs its own public key in your DNS. Adding a fifth sender does not disturb the other four, and removing one is a matter of deleting one record.
Microsoft 365 publishing two selectors is not a mistake — it rotates between them, which is why both must exist even though only one signs at a time. The same logic applies to any provider that rotates keys; see DKIM key length and rotation.
How to find the DKIM selector you are using
Three routes, in order of reliability:
- Read a real message. In Gmail, open a message you sent, choose "Show original", and find
s=in theDKIM-Signatureheader. This is the ground truth: it is what you actually signed with, not what a control panel claims. - Check the sending platform's setup page. Every provider that offers DKIM tells you the selector and hands you the DNS record to publish.
- Look in your DNS for TXT records containing
_domainkey. This finds what is published, which is not always what is being used.
There is no way to enumerate selectors from the outside. DNS offers no "list everything under this name" operation, so a checker can only confirm a selector you already suspect. Anyone claiming to discover all of a domain's selectors is guessing from a list of common ones.
What goes wrong
| Symptom | Cause |
|---|---|
| DKIM fails for one platform only | That platform's selector record is missing or was never published |
| DKIM fails after a provider migration | Selector changed with the new tenant; the old record is still there and is now unused |
| DKIM passes but DMARC still fails | The signature is valid, but d= is the provider's domain, not yours — a signing-domain problem, not a selector one |
| Intermittent failures, roughly half the mail | A provider rotating between two selectors where only one record was published |
That third row is worth dwelling on, because it is the one people misdiagnose. A perfectly valid DKIM signature earns you nothing under DMARC if the domain it authenticates is mailer.provider.example rather than yours — DMARC requires the passing check to be aligned. Most platforms call the fix "authenticate your domain" or "branded sending". The rule itself is in DMARC alignment explained.
Choosing a selector when you generate a key yourself
If you run your own mail server, the name is yours to pick. Two habits pay off:
- Encode the date:
202608._domainkeymakes it obvious when the key was issued, and makes rotation a matter of publishing the next month's name. - Never reuse a selector for a new key. Publish the new selector, switch signing to it, then remove the old record once no in-flight mail can still be verifying against it.
Once signing is live, the reports tell you whether receivers agree. How to read a DMARC report shows the per-source DKIM result — including which of your senders is signing correctly and which is not signing at all.