What Is a DKIM Selector? How Signature Keys Are Found

A DKIM selector is a short label that tells a receiving mail server exactly which public key to use when it verifies a message's DKIM signature. It travels in the `s=` tag of the `DKIM-Signature` header, and the receiver combines it with the signing domain from the `d=` tag to look the key up in DNS.

That one small label is what lets a single domain run several DKIM keys at once — a different key for each service that sends mail as you — and rotate keys without breaking delivery. This guide covers what a DKIM selector is, how a receiver uses it to find the key, and why every sending platform asks you to publish its own.

What is a DKIM selector?#

The DKIM standard, RFC 6376, defines the selector as the value that subdivides the key namespace under a signing domain. In the standard's own words, selectors exist "to support multiple concurrent public keys per signing domain." Each key a domain publishes lives under its own selector, so the selector is how a receiver picks the right key out of however many that domain has.

In a signed message, the selector is carried in the `s=` tag of the `DKIM-Signature` header, and it is required — a signature without it cannot be verified. RFC 6376 describes `s=` as "the selector subdividing the namespace for the `d=` (domain) tag." The `d=` tag names the signing domain (the standard calls it the SDID, the Signing Domain Identifier); the `s=` tag names which of that domain's keys was used.

The selector itself is just a label the signer chooses. It is not secret, not a password, and carries no security on its own — it appears in plain text in every signed message and is openly queryable in DNS. All the security rests on the private key, which never leaves the sender. The selector's only job is to point a receiver at the matching public key.

How does a receiver find the DKIM public key?#

When a receiving server accepts a signed message, it reads two tags from the `DKIM-Signature` header: `d=` (the signing domain) and `s=` (the selector). It slots them into a fixed pattern to build one specific DNS name: `<selector>._domainkey.<domain>`. The literal label `_domainkey` in the middle is the reserved subdomain where DKIM stores all of a domain's keys, and it never changes.

RFC 6376 gives the exact construction: for a signature with `d=example.com` and `s=foo.bar`, "the DNS query will be for `foo.bar._domainkey.example.com`." The receiver queries that name for a TXT record, reads the public key out of its `p=` tag, and uses that key to verify the signature. No selector — or a selector that points nowhere — means there is no key to fetch and a signature the receiver cannot check.

Why do DKIM selectors exist?#

If a domain only ever needed one key, it would not need selectors at all — the receiver could look in a single fixed place. Selectors exist because real domains almost never send from just one system, and because keys have to be replaced from time to time. RFC 6376 leaves the number of selectors entirely up to the domain owner: "Many domain owners will be satisfied with just one selector, whereas administratively distributed organizations can choose to manage disparate selectors and key pairs in different regions or on different email servers."

The first reason is multiple senders. A single domain often sends through several services at once — its own mail server, a marketing platform, a transactional email service, a help-desk tool. Each one holds its own private key and signs under its own selector, so they sign independently and none has to share a secret with the others. That is why every sending platform asks you to publish its selector: it is publishing the address of its own key.

The second reason is key rotation. To replace a key safely, you publish a new key under a new selector, switch signing to it, and leave the old selector live until no in-flight mail still relies on it — then remove it. Because both keys are valid during the overlap, nothing fails verification mid-swap. Without selectors there would be nowhere to stand up the new key while the old one was still in use.

• Multiple senders: one selector per service, each with its own private key, so streams sign independently.
• Safe rotation: publish the new key under a new selector, overlap, then retire the old one — no failed signatures during the swap.
• No shared secrets: because each sender has its own selector and key, exposing one does not expose the others.

How do I find my DKIM selector?#

This is where a lot of people get stuck, because DNS gives you no way to list a domain's selectors. You cannot ask DNS "what selectors does example.com have?" — you can only query a name you already know, like `selector1._domainkey.example.com`. So the reliable way to find a selector is to read it off a message the domain actually sent.

1. 1

   Send yourself a message from the domain

   Send an email from the address in question to an account you can inspect, ideally at a different provider so the receiver adds its own authentication results.

2. 2

   Open the raw headers

   Use "Show original" in Gmail, or "View source" / "View message details" elsewhere, to see the full headers including DKIM-Signature.

3. 3

   Read the s= tag

   Find the DKIM-Signature header and look for s=. Its value is the selector; the d= value beside it is the signing domain.

4. 4

   Confirm the record is published

   Query <selector>._domainkey.<domain> for a TXT record. A DKIM checker, or a dig / nslookup TXT query, will show the p= public key if it exists.

If a domain signs with more than one service, you will see more than one `DKIM-Signature` header, each with its own `s=` — that is normal and expected. Your sending provider's DKIM setup page also lists the selector it uses. As of 2026, Google Workspace commonly publishes its key under the selector `google`, and Microsoft 365 typically uses `selector1` and `selector2` via CNAME records — but check your own provider's setup page rather than assuming, since selector names can differ per account and change over time.

DKIM selector (s=) vs signing domain (d=)#

The two tags are easy to mix up because they always travel together and are used together, but they answer different questions. The `d=` tag answers who took responsibility for the message; the `s=` tag answers which of that party's keys was used. You need both to find a key: the domain tells the receiver whose DNS to look in, and the selector tells it which record within that domain's `_domainkey` space to read.

Common misconceptions about DKIM selectors#

Because the selector is small and rarely explained, a handful of wrong ideas about it circulate widely. Each of these is worth correcting, because acting on the wrong one is how DKIM setups get broken or feared for no reason.

• "A domain has one selector." It can have many — one per sending service, plus extra ones live during a key rotation. Seeing several is healthy, not a fault.
• "The selector is secret or security-sensitive." It is a public label that appears in every signed message and is meant to be looked up in DNS. Security comes from the private key, not from hiding the selector.
• "I can list all of a domain's selectors in DNS." You cannot — DNS has no way to enumerate the names under `_domainkey`. You learn a selector by reading the `s=` tag of a real message.
• "The selector points to the private key." It points to the public key, which is published openly. The private key never appears in DNS and never leaves the sender.
• "Changing selectors means telling receivers." It does not. The selector rides inside every signature in the `s=` tag, so a receiver always learns the current selector from the message itself — which is exactly why rotation is painless.

How this shows up in AI Emaily#

DKIM selectors are configured at the sending domain — in DNS and at whatever service sends your mail — not inside the mail client you read messages in. AI Emaily does not publish DKIM records or manage selectors, and no email client does; that job belongs to your domain and your sending platform. What a client can do is respect the result. By the time a message reaches you, the receiving server has already run the selector lookup and recorded the outcome, and AI Emaily leans on those authentication signals — trusting verified mail and flagging senders that fail authentication, which feeds its spam and phishing protection instead of presenting a forgery as if it were genuine.

We build AI Emaily, an AI-native client that brings Gmail, Outlook, and any IMAP account into one place and keeps you in control of what the AI does. It is private by design — your mail is used to help you read and write, never to train models for anyone else — and it starts with a 7-day free trial. On DKIM itself the honest boundary is simple: the standards live in DNS and on sending servers, and a good client just makes their outcome legible and acts on it sensibly.