What is a DKIM selector (and why there are several)

When you set up DKIM, one word keeps coming up without ever really being explained: the selector. You're asked to add a DNS record at something._domainkey.your-domain.com, and that "something" is the selector. Understanding what it is clears up a lot of DKIM confusion at once — why there are several, how key rotation works, and why a signature can fail even though "the key is right there." This guide explains the DKIM selector simply, with what you need to know in practice.

What a selector is for

DKIM rests on a key pair: a private key that signs your messages (kept secret by your sending platform) and a public key published in your DNS, which the receiver fetches to verify the signature. But a domain can have several public keys at the same time — one per sending platform, for example. How does the receiver know which one to use to verify a given message?

That's exactly the selector's role. Each DKIM signature added to an email contains an s= tag (the selector) that tells the receiver: "the public key to verify this message is at this selector." The selector is therefore a pointer: it links a signature to the right public key in your DNS.

Where the selector appears

The selector lives in two places, and it helps to connect them:

1. In the DKIM-Signature header of the message, via the s= tag. For example: s=selector1; d=your-domain.com; ....
2. In your DNS, as a TXT record at <selector>._domainkey.<domain>. For s=selector1 and d=your-domain.com, the receiver queries:

selector1._domainkey.your-domain.com

and finds the public key there:

selector1._domainkey.your-domain.com.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkq... (public key)"

Verification is therefore a clean round trip: the receiver reads s= and d= in the signature, builds the DNS address, fetches the public key, and verifies. If the key isn't there, or doesn't match, the signature fails.

Why you often have several selectors

This is the part that surprises. A domain almost never has a single selector, and that's normal:

• One platform = one selector (at least). If you send via Microsoft 365, a marketing router and a billing tool, each has its own DKIM key, hence its own selector. You publish one TXT record per selector.
• Key rotation creates selectors. When you renew a DKIM key, you publish a new key under a new selector, switch signing to it, then remove the old one. During the transition, two selectors coexist (see key rotation).
• Subdomains can have their own selectors.

Having several selectors isn't a problem — it's the expected behavior. Each selector is independent, and a receiver only uses the one named in the signature it's verifying.

What a selector name looks like

The selector name is free, and each platform has its conventions. You'll see, for example, selector1/selector2 (Microsoft 365), google (Google Workspace), dated names like s1024-2024, or strings generated by a provider. The name has no technical importance: what matters is that the signature's selector matches an existing DNS record. So there's no hidden meaning to chase in a selector name — it's just a label.

How to enable a DKIM selector

In practice, you don't "create" a selector by hand: your sending platform generates it for you and gives you the DNS record to publish (often a CNAME pointing to a record managed by the provider, or a TXT with the public key). Your job comes down to:

1. Enable DKIM in the platform's console (Microsoft 365, Google Workspace, your router…).
2. Publish the record provided, at the indicated selector.
3. Verify that the signature passes and aligns (see how to verify an email signature).

The CNAME is often preferable to a raw TXT: it lets the provider rotate the key without you having to touch your DNS.

Alignment: the selector doesn't do everything

A crucial point for DMARC. A valid DKIM signature proves a domain signed the message — but for DMARC, that domain (d=) must also align with your From:. The selector only concerns the key retrieval; it's the d= tag that carries alignment. So you can have a perfectly valid signature that doesn't count for DMARC, because the d= is the provider's, not yours. The fix is to configure a branded signature (d=your-domain.com) on each platform. This mechanism is detailed in how the three protocols work together.

Troubleshooting a selector

When a DKIM signature fails, the selector is often to blame. The classic leads:

• The selector's DNS record is missing or mis-published (a typo in the name, the wrong ._domainkey subdomain).
• The public key was truncated on copy-paste (keys are long; a missing character breaks verification).
• The signature's selector matches no record — typically after a botched rotation, where the old selector was removed before signing switched over.
• DNS propagation isn't complete: a freshly published selector can take a little while to be visible everywhere.

To confirm, query the selector directly in DNS (dig TXT selector1._domainkey.your-domain.com) and check the public key is there and complete.

Tracing a verification, step by step

To anchor the selector's role, let's follow a real message. You send an invoice from company.com via your platform, which signs with s=mail2025; d=company.com. Here's what the receiving server does:

1. It reads the DKIM-Signature header and finds s=mail2025 and d=company.com.
2. It builds the DNS address: mail2025._domainkey.company.com.
3. It queries that address and fetches the published public key.
4. It recomputes the message hash and compares it to the signature. If everything matches: dkim=pass.
5. Finally, it checks that d=company.com matches the From: domain — alignment, essential for DMARC.

If any of these steps fails — selector not found, truncated key, different hash — the signature doesn't pass. Understanding this chain lets you diagnose any failure: you know exactly where to look, and in what order.

Keeping your selectors organized

Over time, a domain accumulates selectors: one per platform, plus those left by old rotations. A few principles avoid chaos. Give your selectors meaningful, dated names when you control them (mail-2025, marketing-router), rather than opaque strings: you'll find which is which faster. Keep a simple inventory — which selector for which platform, since when — just like your inventory of sending sources. And above all, remove dead selectors once their rotations are done: an orphan selector isn't dangerous, but it clutters and muddies diagnosis the day a signature fails. A well-kept DNS is one where every _domainkey record has a known reason to exist — that's what turns an hour-long troubleshooting session into a two-minute glance.

Frequently asked questions

How many selectors can I have? As many as needed — there's no awkward limit. One platform per selector, plus those created temporarily by rotation. Having several selectors is healthy, not problematic.

Can I delete an old selector? Yes, but only when no signature uses it anymore (typically after a completed rotation). Deleting a selector still referenced by in-transit messages breaks their verification.

Is the selector secret? No. The selector and the public key are public by nature (they're in DNS and in every signed email). It's the private key, on the sending platform's side, that must stay secret.

Why does my provider give me a CNAME rather than a TXT? So it can rotate the key for you without you touching your DNS each time. It's usually the right option: you publish once, the provider handles the rest.

Can two platforms share a selector? In theory, but it's discouraged: each platform has its own key, hence its own selector. Mixing complicates troubleshooting and rotation.

Selectors and subdomains: a case worth knowing

A point that often surprises: subdomains don't "inherit" the root domain's selector. If you send from news.company.com, that subdomain needs its own DKIM record — for example mail._domainkey.news.company.com — and the signature must say d=news.company.com for DMARC alignment to work correctly. Root domain and subdomains are independent, with their own selectors and their own keys. This reality is often overlooked when you configure DKIM only for the main domain, then wonder why marketing sends or automated notifications don't appear aligned in DMARC reports. Before asking "is my key correct?", first check "have I published a key for every domain and subdomain I send from?" It's a common gap that produces the frustrating situation where DKIM passes for human email but fails for everything else — because "everything else" was never configured.

Let Thomas map your selectors

Between each platform's selectors and those left over from old rotations, it's easy to get lost. Thomas, your virtual CISO, identifies each sending source, spots the selector it uses, checks the public key is published and the signature aligns with your domain — and flags dead selectors to clean up.

Analyze your domain for free → or create an account to see your DKIM keys clearly.