DKIM selectors explained

12 June 2026 · 10 min read

DKIM gives a domain a way to sign its outgoing mail with a private key and let receivers verify that signature against a public key published in DNS. That much is well known. What trips people up is the small piece of the mechanism that makes the whole thing flexible enough to survive in the real world: the selector. It is the part of a DKIM setup that lets you hold several keys at once, rotate them without an outage, and let half a dozen different sending services each sign your mail without ever colliding.

This article explains what a selector actually is, how to read one out of a real message and out of DNS, why a single domain usually has more than one, and how selectors quietly do the heavy lifting behind key rotation and multi-sender setups. By the end you should be able to look at any signed email, find every selector your domain uses, and understand why adding a new sender means adding a new selector rather than editing an old one. If you just want to confirm a specific selector is published correctly, the DKIM checker will resolve it for you in a few seconds; the rest of this is the reasoning behind that lookup.

A quick recap of how DKIM signing works

To see why selectors exist, it helps to picture the signing flow in concrete terms.

When a sending server prepares a message, it computes a cryptographic hash over a chosen set of headers and the body, then encrypts that hash with a private key to produce a signature. It attaches that signature to the message as a header called DKIM-Signature. The private key never leaves the sending infrastructure.

The matching public key lives in your DNS, published as a TXT record. A receiving mail server reads the DKIM-Signature header, fetches the public key from your DNS, and uses it to verify that the signature is genuine and that the signed content was not altered in transit. If the maths works out, DKIM passes.

The problem this leaves open is purely one of addressing. Your domain can have many public keys in play at the same time: one for your mailbox provider, one for your marketing tool, a fresh one you are rotating in, an old one you have not retired yet. The receiver needs to fetch the exact public key that matches the private key used for this particular message. It cannot guess. There has to be a label that points at the right key. That label is the selector.

What a selector actually is

A selector is a short, free-form name that you choose, and it does exactly one job: it picks which DNS record holds the public key for a given signature.

DKIM public keys are always published at a fixed, predictable location built from two pieces of information:

• the selector, and
• the literal string _domainkey, followed by your domain.

The record name is assembled like this:

<selector>._domainkey.<your-domain>

So if your selector is s1 and your domain is example.com, the public key lives in a TXT record at:

s1._domainkey.example.com

The selector is not secret, it is not random in any cryptographic sense, and it carries no security weight on its own. It is just a routing label. You could call it s1, google, mail, selector1, k1, 2026a or dkim; the receiver does not care what it means, only that the name in the signature matches the name of a published record.

Crucially, the selector is announced inside every signed message, so the receiver never has to know it in advance. It reads the selector out of the DKIM-Signature header, constructs the DNS name above, and looks it up. This is the whole trick: by putting the selector in the message and the key under a selector-derived name in DNS, a domain can run any number of independent keys with no central registry and no coordination beyond agreeing on names.

Reading a selector out of a real message

You can find a selector for any email you have received in about ten seconds, because it is written in plain text in the headers.

Open the original or raw source of a message (in Gmail this is "Show original", in Outlook it is "View message source", in Apple Mail it is "View, Message, Raw Source"). Look for the DKIM-Signature header. It is a single logical line broken across several physical lines, made of tag=value pairs separated by semicolons. A typical one looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=s1;
 h=from:to:subject:date:message-id;
 bh=2jU8...; b=Q9fk2P...

Two tags matter here for our purposes:

• d= is the signing domain. This is the identity the signature claims, and the one DMARC checks for alignment.
• s= is the selector. In the example above it is s1.

Put those two together with _domainkey and you have the exact DNS record that verifier will fetch:

s1._domainkey.example.com

If a message has been signed by more than one party (your own platform plus a forwarder, say), you will see more than one DKIM-Signature header, each with its own d= and s= pair. Each one is evaluated independently, and DMARC only cares about a signature whose d= aligns with the header From domain. Alignment is the bridge between DKIM passing and DMARC passing, and it is worth understanding in its own right; we cover it in how DMARC alignment works.

Finding the keys your domain publishes

Reading a selector out of an email tells you about one message. To understand your whole setup you want to know every selector your domain has live in DNS, and that is harder, because of a genuine quirk of DKIM: there is no way to list selectors.

DNS does not let you ask "show me every record under _domainkey.example.com". You can only ask for a specific name. Since a selector can be any string, there is no way to enumerate them blindly. This catches people out constantly. You cannot discover your selectors purely from DNS; you have to know the names first, and you learn the names from one of three places:

1. Your sending services tell you. When you set up DKIM with a provider, the provider gives you the exact selector (or selectors) to publish. Google Workspace typically uses google; many platforms use s1 and s2, or k1, or a long random-looking string unique to your account.
2. You read them out of real messages, as in the section above. Send yourself a test message through each service and collect the s= value from each signature.
3. Your DMARC aggregate reports name them. Every aggregate (RUA) report lists the DKIM domains and selectors that were seen authenticating your mail. This is the most reliable way to find selectors you forgot you had, because it reflects what is actually signing live traffic, not what you think you configured. If you are not yet collecting these reports, aggregate reports explained walks through what they contain, and you can turn raw XML into a readable inventory with the DMARC report analyzer.

Once you have a selector name, confirming the published key is straightforward. Paste the selector and domain into the DKIM checker and it fetches and parses the record for you. If you prefer the command line, a plain DNS query does the same job:

dig TXT s1._domainkey.example.com +short

A healthy result is a TXT record beginning v=DKIM1; and containing a p= tag with a long base64 public key. If the record is missing, the lookup returns nothing and any message signed with that selector will fail DKIM.

Why one domain has several selectors

Here is the heart of it. A naive design might have used one key per domain. DKIM deliberately did not, and selectors are the reason. Multiple selectors solve two everyday problems cleanly: rotating keys safely, and letting several senders sign the same domain at once.

Selectors make key rotation safe

A DKIM private key should not live forever. The longer a key is in service, the more exposure it has, and short RSA keys (1024-bit) are now considered weak enough that you want to move to 2048-bit. Rotating a key means switching to a new key pair. The danger is timing: if you swap the public key in DNS at the same instant the sender starts using the new private key, any message in flight signed with the old key will suddenly fail to verify, because the matching public key has vanished.

Selectors remove this race entirely, because the new key gets a new name, so the old and new keys can coexist. A clean rotation looks like this:

1. Generate a new key pair and publish its public key under a fresh selector, for example 2026b._domainkey.example.com, while the current selector 2026a stays exactly where it is.
2. Wait for the new record to propagate through DNS and any caches.
3. Tell the sending service to start signing with the new selector. From this point new mail uses 2026b; mail already sent with 2026a still verifies because that record is untouched.
4. Wait out the period in which old messages might still be in transit or sitting in forwarding queues, typically a few days to be safe.
5. Only then remove the old 2026a record.

At no point is there a window where a message is signed with a key whose public half is missing from DNS. That is the entire value of selectors for rotation, and it is why automated DKIM management leans on them. Our DKIM product handles this overlap-and-retire cycle for you so you never have to manually time a swap.

Selectors let many senders share one domain

The second problem is more common still. Almost every organisation sends mail from the same domain through several unrelated services: a mailbox provider for staff mail, a marketing platform for newsletters, a billing system for invoices, a help-desk for support, perhaps a CRM for sales sequences. Each of those services has its own signing infrastructure and its own private key, and none of them can share a key with the others, because none of them ever has the others' private keys.

Selectors let each sender own its own key without stepping on the others. Each service publishes its public key under a selector of its own:

google._domainkey.example.com      (Google Workspace)
s1._domainkey.example.com          (a marketing platform)
mandrill._domainkey.example.com    (a transactional sender)

When mail goes out through Google, the signature carries s=google; when it goes out through the marketing platform, it carries s=s1. Each receiver fetches the matching key, and every service authenticates correctly with zero coordination between them. This is why adding a new sending service almost always means adding a new selector, never editing an existing one. Editing an existing selector to repurpose it is how you break the sender that was relying on it.

There is an important corollary for getting to DMARC enforcement. Every legitimate service that sends as your domain needs to be signing with its own working selector before you tighten your policy. A sender that is not signing, or is signing with a broken selector, will fail DKIM, and if it also fails SPF alignment it will fail DMARC. Building a complete inventory of senders and their selectors is precisely the groundwork that lets you move from p=none to p=reject without losing legitimate mail, a journey we lay out in moving from p=none to p=reject.

Common selector mistakes and how to spot them

A handful of selector problems account for most DKIM failures, and all of them are visible if you know where to look.

• Publishing the key under the wrong name. The most frequent mistake is putting the public key at _domainkey.example.com or dkim.example.com instead of <selector>._domainkey.example.com. The receiver builds the name from the selector in the signature, so if the record is not at that exact name, the lookup fails. Check it with the DKIM checker using the selector from a real message.
• Selector mismatch between sender and DNS. If the provider is signing with s=s2 but you only published s1, every message fails. This happens when a provider rotates its own selector and you miss the notice. DMARC aggregate reports will show the failing selector.
• CNAME pointing at a stale target. Many providers ask you to publish the DKIM record as a CNAME that points into their infrastructure, so they can rotate the underlying key for you. That is fine and often preferable, but if the CNAME is mistyped or the provider's target moves, the chain breaks. A dig on the selector name will show whether the CNAME resolves to a real key.
• A 1024-bit key you never rotated. Old setups often still carry weak keys. Rotating to a 2048-bit key under a new selector, using the overlap process above, fixes this without risk.
• Treating the selector as a secret. It is not, and trying to hide it gains nothing. Selectors are visible in every message you send. Security comes from the private key, never from the selector name.

If you want a single place to see which senders are passing and which selectors they use, continuous monitoring is the practical answer. The monitoring service reads your aggregate reports, names every selector seen in the wild, and alerts you when a key stops verifying so you catch a broken rotation before it dents your deliverability.

The practical takeaway

A DKIM selector is nothing more than a chosen label that points a receiver at the right public key, published at <selector>._domainkey.<domain> and announced in the s= tag of every signature. That small piece of indirection is what makes DKIM workable: it lets you keep an old key and a new key live at the same time so rotation never causes an outage, and it lets every sending service sign your domain with a key of its own. The rule of thumb that follows is simple. Adding a sender means adding a selector, and rotating a key means adding a selector then retiring the old one later, never editing in place.

To check a selector you already know, run it through the DKIM checker. To discover the selectors actually signing your mail, read your aggregate reports with the DMARC report analyzer or browse the wider free tools. And if you would rather not manage key generation, publication, overlap windows and retirement by hand across every sender you use, the done-for-you DKIM service keeps your selectors and keys correct as part of taking your domain safely to enforcement.