What is a DKIM selector, and how do you find yours?

You are trying to check a DKIM record, and the tool asks for something your DNS dashboard never mentioned: a selector. Not the domain, not the key, a selector. Nobody told you it existed, and without it the lookup returns nothing.

Here is the short answer. A DKIM selector is the label that picks which public key a receiving server fetches to verify a message’s DKIM signature. It travels in the s= tag of the DKIM-Signature header, and it is the first part of the DNS name where the key lives:

<selector>._domainkey.<domain>

So a selector named google on example.com publishes its key at google._domainkey.example.com. The naming comes straight from the standard. RFC 6376 §3.5 defines s= as “the selector subdividing the namespace for the d= (domain) tag”, and §3.6.2.1 spells out the query: given d=example.com and s=foo.bar, the DNS query is for foo.bar._domainkey.example.com.

The reason selectors exist at all is in §3.1 of the same RFC: a domain almost never has just one DKIM key. One key per sending platform, one key per rotation period, sometimes one per office. Selectors are what let all of those keys coexist under a single domain without colliding.

That is the theory. The practical problem is that the selector name is not published anywhere you can browse. There is no DNS query that lists a domain’s selectors. You either know the name or you go looking for it. The rest of this post is about how to look.

The selector your provider uses

Most people never chose a selector; their email platform chose one for them during setup. The names in this table are the selector dictionary our DKIM checker probes for each provider. The Google, Microsoft, Amazon SES, SendGrid, Klaviyo, and Zendesk conventions are checked against each vendor’s current documentation.

Provider	Selector(s)	Notes
Google Workspace	google	Default prefix when you generate the key in the Admin console; admins can pick a different one if google is taken. TXT record.
Microsoft 365	selector1, selector2	Always these two names, as CNAME records pointing at Microsoft-hosted keys. Microsoft signs with one while the other stands by for rotation.
Amazon SES (Easy DKIM)	Random tokens	Three CNAME records with account-specific token names. They cannot be guessed.
SendGrid	s1, s2	CNAME records created by automated security, pointing at sendgrid.net hosts.
Mailchimp	k2, k3 (older setups: k1)	CNAME records; the exact pair is shown in your account’s domain-authentication page.
Klaviyo	km1, km2 (marketing)	Send-type pairs: kt1/kt2 for transactional, ks1/ks2 for service; legacy domains use kl1/kl2. Published under the branded sending subdomain. See the Klaviyo DMARC setup.
Zendesk	zendesk1, zendesk2	CNAME records pointing at zendesk1._domainkey.zendesk.com and zendesk2._domainkey.zendesk.com.
Salesforce Marketing Cloud	Account-specific	Selector names are generated per account. They cannot be guessed.
Proofpoint	Tenant-specific	No fixed public default; the selector is set during implementation. Read it from your Proofpoint configuration or from a signed message’s header.

Self-hosted mail servers are their own category: OpenDKIM setups commonly use default, mail, or a date-style selector like 20230601 that encodes when the key was created.

Two patterns in that table are worth calling out.

First, the CNAME pattern. Microsoft 365, SendGrid, Mailchimp, Klaviyo, and Zendesk do not have you paste a public key into a TXT record. You publish a CNAME that delegates the selector to a hostname the provider controls, and the provider serves the actual key from their side. Klaviyo’s recommended dynamic mode goes further and delegates the whole sending subdomain with NS records, which also leaves the keys on Klaviyo’s side. The upside is that they can rotate the underlying key without you touching DNS. The downside is that a deleted or broken CNAME target silently disables DKIM until someone looks.

Second, the random pattern. Amazon SES and Salesforce Marketing Cloud generate selector names per account. There is no dictionary that finds them, which matters when you are auditing a domain from the outside: finding nothing does not prove DKIM is absent. Our checker reports these cases as “undetectable” rather than “no DKIM” for exactly this reason.

How to find your selector

There are two reliable ways, and both take under a minute.

Read it from a real message. Send yourself an email from the platform in question, open the raw headers, and find the DKIM-Signature header. The s= tag is your selector, and d= is the domain it belongs to:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google;
        h=from:to:subject; bh=...; b=...

If digging through raw headers is not your idea of a good time, paste the whole thing into our email header analyzer and it will pull out the selector, the signing domain, and whether the signature aligns for DMARC.

Scan the domain. Sometimes you cannot send a test message. You may be auditing a client’s domain, or checking a supplier from the outside. Run the domain through our DKIM checker. You do not need to know the selector: the checker fingerprints the domain’s email provider from its MX and SPF records, then probes a dictionary of roughly 130 common selector names over DNS from your browser. It reports every key it finds, its strength, and whether it is active, revoked, or broken. If a provider’s expected selector is missing, it names that too.

Once you know the selector, verifying the record manually is one query:

dig TXT google._domainkey.example.com +short

A healthy answer contains v=DKIM1 and a p= tag holding the public key. An answer with an empty p= means the key was revoked. No answer means no key at that selector.

Why providers give you two selectors

Microsoft 365 creates selector1 and selector2. SendGrid creates s1 and s2. Zendesk creates zendesk1 and zendesk2. The pairing exists so the provider can rotate a signing key with zero downtime.

DKIM verification happens after delivery, sometimes hours after a message was signed. If you replaced the key under a single selector in place, every message signed with the old key and still in transit would fail verification the moment the new key went live. With two selectors, the provider signs with one, publishes the next key under the other, switches signing over, and leaves the old key resolvable until nothing in transit references it. Messages signed under either selector verify throughout, because each signature names its own selector in s= and receivers fetch exactly the key that signed it.

That is also why you should not “clean up” the selector that appears inactive: it is the standby half of the rotation.

What this means in practice

• A missing or misspelled selector record fails DKIM outright. If the platform signs with s=selector1 and DNS has no record at selector1._domainkey.yourdomain.com, receivers cannot fetch the key and the signature fails verification. There is no fallback and no partial credit. Under a DMARC policy of p=reject and with no aligned SPF pass, that mail is refused.
• Multiple selectors on one domain are normal. Google under google, SendGrid under s1/s2, and Microsoft under selector1/selector2 coexist on the same domain without touching each other. What you must never have is two TXT records at the same selector name. That is the real failure mode, and we cover it in multiple DKIM records on one domain.
• The selector is not a secret. Anyone with a message you sent can read s= from its header, and the public key it points to is, by definition, public. Knowing your selector lets someone verify your signatures, which is the entire point of publishing it. The security lives in the private key on the signing side.

If you take one action from this post: run your domain through the free DKIM checker. It finds your selectors without you knowing a single name, grades every key it discovers, and flags the revoked and broken ones. For platform-specific detail, read DKIM on Amazon SES and DKIM on Zendesk.

DKIM is one third of the authentication story; DMARC is where you see whether it holds up across every receiver. DMARCTrust reads your aggregate reports and shows which selectors actually signed your mail in the wild. Start for free with aggregate reports for one domain.

FAQ

Can a domain have more than one DKIM selector?

Yes, and almost every real domain does. Each selector is an independent DNS name under _domainkey, so one domain can hold keys for Google Workspace, an ESP, and a support platform side by side. RFC 6376 §3.1 describes this as the design intent: selectors subdivide the key namespace precisely so that multiple keys and periodic rotation can coexist. The one real conflict is two TXT records published at the same selector name, covered in multiple DKIM records.

What happens if the selector in a signature has no DNS record?

The signature fails verification. The receiver builds the query from the header by joining s=, ._domainkey., and d=. If nothing answers, there is no key to check the signature against. The message is then evaluated on SPF alone; if SPF does not pass with alignment either, DMARC fails and your policy (p=quarantine or p=reject) decides its fate.

Is a DKIM selector secret or sensitive?

No. The selector appears in plain text in the header of every message you send, and the record it points to contains a public key. Publishing it reveals nothing an attacker can use to forge your signatures. Forging requires the private key, and that never appears in DNS. Choose selector names for clarity and rotation hygiene, not concealment.

Where do I find the selector for my own domain?

Send yourself a message from the platform and read the s= tag in the DKIM-Signature header, or paste the headers into the email header analyzer. If you cannot send from the domain, the DKIM checker discovers selectors by fingerprinting the domain’s provider and probing roughly 130 common names, so you do not have to supply one.