DKIM Selector
A DKIM selector is a label that points to one specific DKIM public key, letting a domain publish several keys - one per sending service. It forms the DNS host selector._domainkey.yourdomain.com and appears as the s= tag in the DKIM-Signature header.
This guide is part of our complete guide to DKIM. Related: the DKIM record and the DKIM signature.
A DKIM selector is a short label that points to a specific public key stored in your domain’s DNS, letting a single domain publish many DKIM keys at once — one for each sending service or key generation — so receiving servers know exactly which key to fetch when they verify a given message’s signature.
How the selector fits into a DKIM lookup
Every DKIM-signed email carries a selector inside its signature. The receiving mail server combines that selector with your domain to build a DNS hostname, then looks up the public key stored there. The convention is fixed:
selector._domainkey.yourdomain.comThe middle label _domainkey is always present — it is the namespace DKIM reserves in DNS. The selector is whatever the signing service chose. For example, if a message from example.com is signed with the selector google, the verifier queries:
google._domainkey.example.comThat hostname holds a TXT record containing the public key. The receiver fetches it, uses it to check the cryptographic signature on the message, and passes or fails DKIM accordingly. Because the selector is baked into each signature, the same domain can operate several keys side by side without collisions.
How to find your DKIM selector
The most reliable way to find a selector is to read it straight from a message that was actually signed by the service you care about. Open any received email from that sender, view the raw source or original headers, and locate the DKIM-Signature header. The s= tag is the selector:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=google;
h=from:to:subject:date; bh=...; b=...Here d=example.com is the signing domain and s=google is the selector, so the key lives at google._domainkey.example.com. A single message can carry more than one DKIM-Signature header — each one has its own s= tag, which is common when mail passes through multiple signing services.
If you do not have a signed message handy, or you want to confirm what is actually published in DNS, use the auto-discovery in our free DKIM lookup tool. It probes the common provider selectors for your domain and returns the public keys it finds, so you can verify your DKIM setup without hunting through raw headers.
Common selectors by provider
Most email platforms use predictable, documented selectors. The signing service — not you — decides the selector name, so the value depends on who sends your mail:
| Provider | Typical selector(s) |
|---|---|
| Google Workspace | google |
| Microsoft 365 | selector1, selector2 |
| SendGrid | s1, s2 |
| Mailchimp | k1 |
| Amazon SES | generic tokens (a long unique string per identity) |
These are conventions, not guarantees — a provider can change its scheme, and some let you customize the selector during setup. When in doubt, read the s= tag from a real signed message rather than assuming.
Why domains have multiple selectors
It is normal, and usually healthy, for one domain to publish several selectors at the same time. There are two main reasons.
First, each sending service gets its own selector. If you send transactional mail through Amazon SES, marketing campaigns through Mailchimp, and internal mail through Google Workspace, each service signs with its own key under its own selector. They coexist in DNS without interfering with one another.
Second, key rotation relies on multiple selectors. DKIM keys should be rotated periodically to limit the damage if a private key is ever exposed. During a swap, the old key stays live under its existing selector while the new key is published under a fresh selector. Mail signed with either key still verifies, and once all in-flight mail has cleared, the old selector can be retired. This is exactly why Microsoft 365 ships with selector1 and selector2 — it can flip between them cleanly.
Choosing a selector when you set up DKIM
When you generate a new key yourself, you pick the selector name. Any short, DNS-safe label works — teams often use something descriptive plus a date or version, such as mail2026 or smtp1, so the purpose and vintage are obvious later. The name has no effect on security; it is simply a lookup key. What matters is that the selector in your DNS record matches the s= tag your signing system stamps on outgoing mail. For a full walkthrough, see how to generate a DKIM record.
Frequently Asked Questions
What is a DKIM selector?
A DKIM selector is a text label that identifies which public key a receiving server should fetch to verify a signed message. It is combined with your domain as selector._domainkey.yourdomain.com to form the DNS lookup. Selectors let one domain publish multiple DKIM keys at once, one per service or key version.
How do I find my DKIM selector?
Open a message the service actually signed, view its raw source, and read the s= tag inside the DKIM-Signature header — that value is the selector. If you have no signed message on hand, the auto-discovery in our free DKIM lookup tool probes the common provider selectors for your domain and reports which keys are published.
Can a domain have multiple DKIM selectors?
Yes, and it is common. Each sending service typically signs with its own selector, so a domain using several mail platforms will publish several selectors simultaneously. Multiple selectors also enable safe key rotation: the old and new keys live under different selectors during the swap, so mail signed with either one still verifies.
Does the DKIM selector name matter?
The exact name has no effect on security or deliverability — a selector is just a lookup label. What matters is that the selector published in your DNS record matches the s= tag your signing service stamps on outgoing mail. Teams often add a date or version to the name so its purpose and age are easy to track.