Where do I find my DKIM selector?

In the DKIM-Signature header of an email you sent, in the s= tag. View the raw source (Gmail 'Show original', Outlook 'View source') and read s= for the selector and d= for the signing domain.

Can a domain have more than one DKIM selector?

Yes. Each selector points to its own public key in DNS, so you can run several at once, one per sending platform, plus extras during key rotation. They never conflict.

My DKIM is failing, could the selector be wrong?

Often. If the s= value in your header has no matching ._domainkey. TXT record, verification fails. Confirm the published record matches the selector your platform is actually signing with.

DKIM Selector Explained: What It Is and How to Find Yours

VigilDog Team · September 16, 2026 · 6 min read

Every signed email carries a small clue about how it was authenticated: the DKIM selector. It is easy to overlook, but the moment you need to fix a failing DKIM record, rotate a key, or set up a new sending platform, the selector is the first thing you have to find. This guide explains what a DKIM selector is, how receivers use it, and exactly how to find yours.

What a DKIM selector actually is

DKIM (DomainKeys Identified Mail) signs outgoing email with a private key and publishes the matching public key in DNS. The selector is the label that tells a receiving server which public key to use. You will see it as the s= tag inside the DKIM-Signature header, right next to d= (the signing domain).

Receivers combine the two into a single DNS lookup: the public key lives at <selector>._domainkey.<domain>. So a message signed with s=google and d=example.com sends the receiver to google._domainkey.example.com to fetch the key. The selector is just a name you choose; its only job is to point at the right TXT record.

Because the selector is part of the DNS path, one domain can host many keys at once, one per selector. That is what makes selectors useful: different platforms, and different key generations, never collide.

How the selector fits into a DKIM check

When a message arrives, the receiver reads the DKIM-Signature header, extracts s= and d=, and queries DNS for the public key. It then verifies the cryptographic signature over the message body and selected headers. If the signature validates, DKIM passes, and that result feeds into DMARC alignment.

The diagram below shows where the selector sits in the wider email-authentication flow, alongside SPF and DMARC.

How SPF, DKIM and DMARC verify an email

How to find your DKIM selector

The most reliable way is to read a message you actually sent. Send yourself an email, open the raw source (in Gmail, 'Show original'; in Outlook, 'View source' or message details), and find the DKIM-Signature header. The s= value is your selector and d= is the signing domain.

Once you have both, confirm the key is published with a quick DNS query:

dig TXT google._domainkey.example.com +short
nslookup -type=TXT selector1._domainkey.example.com

Common selectors by email provider

You do not always have a sent message to inspect; sometimes you are configuring DNS before the first email goes out. In that case, knowing your provider's default selector helps. If a lookup returns a record starting with v=DKIM1; k=rsa; p=..., the selector is live. Our free DMARC checker can walk the whole SPF, DKIM, and DMARC chain for you if you would rather skip the command line. Common defaults:

Google Workspace: google
Microsoft 365: selector1 and selector2 (two rotating CNAMEs)
SendGrid: s1 and s2 (published as CNAMEs)
Mailchimp / Mandrill: k1
Postmark: a custom token per domain, shown in its DNS setup screen
Amazon SES: a long generated token ending in the SES domain
Zoho: zoho or a dated selector

Selectors, key rotation, and deliverability

Selectors are what make DKIM key rotation painless. To rotate without downtime, you publish a new key under a new selector, switch your mail platform to sign with it, and only retire the old selector's record once no in-flight mail still references it. Because each key has its own DNS path, old and new coexist safely.

This is also why you should never reuse a selector for a different key generation: mail signed with the old private key would suddenly fail against the new public key. Microsoft 365's selector1/selector2 pattern exists precisely so the platform can flip between two keys automatically.

If you are moving toward an enforced policy, getting selectors and rotation right first is essential. Our DMARC p=reject rollout guide covers how DKIM alignment feeds into that decision.

Keep an eye on it

A DKIM record is not set-and-forget. Keys get rotated, DNS records get edited, a platform migration drops a selector, and suddenly a slice of your mail fails authentication, usually discovered only when something lands in spam. Spot-checking with dig works, but it only catches problems the moment you happen to look.

That is the case for continuous monitoring. VigilDog watches your domain's email authentication, SPF, DKIM, and DMARC, and alerts you when a record changes or a lookup starts failing, so a dropped selector never quietly costs you inbox placement. For a walkthrough of building the records themselves, see our SPF, DKIM, and DMARC fix guide.