What is a DKIM selector, and how do I find mine?

Every DKIM checker asks for a "selector," and nobody explains what that is. Here's the plain-English version: it's the label that tells the world which of your public keys to look up.

The one-paragraph answer

When a server signs your outgoing mail with DKIM, it adds a DKIM-Signature: header. Receivers verify that signature by fetching your public key from DNS — but a domain can have many keys (one per sending service), so the signature has to say which one. That's the selector: a short label, carried in the signature's s= tag, that completes the DNS name where the key lives:

<selector>._domainkey.yourdomain.com

Selector google on example.com means the key is a TXT record at google._domainkey.example.com. The name itself carries no meaning — it just has to match what's in DNS.

How to find your selector

  1. Send yourself a message from the service you're checking, to a Gmail address you control.
  2. Open the message and choose Show original (Outlook.com: View message source).
  3. Find the DKIM-Signature: line and read two tags:
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=google; ...

s= is the selector, d= is the signing domain. There may be several DKIM-Signature headers — one per signer. The one that matters for DMARC is the one whose d= matches your visible From domain; a valid signature for someone else's domain doesn't help you, which is the usual reason DMARC fails despite dkim=pass.

One thing you can't do is list a domain's selectors from DNS — there is no directory to query. You either know the selector (from headers or the sending platform's setup screen) or you guess common ones.

Default selectors by provider

Most platforms use predictable selector names, which is handy when you're auditing a domain:

ProviderTypical selector(s)
Google Workspacegoogle
Microsoft 365selector1, selector2
SendGrids1, s2
Mailchimpk1, k2, k3
Zoho Mailchosen at setup (often zmail)

Once you know (or suspect) a selector, you can look the key up directly with our free DKIM checker — it fetches the record and tells you whether the key is valid.

Why domains have several selectors

  • One per sending service. Your mail host, newsletter platform, and CRM each sign with their own key under their own selector. That's by design — it's how each service can be authorized (or revoked) independently.
  • Key rotation. Providers publish selectors in pairs (selector1/selector2, s1/s2) so they can roll to a fresh key on one selector while the other keeps signing — no downtime, no failed signatures. This is also why Microsoft 365 uses CNAME records for its selectors: Microsoft rotates the underlying keys for you.

Selector mistakes that break DKIM

  • Publishing the key on the wrong host. The record belongs at selector._domainkey, not at _domainkey alone and not at the domain root. Provider setup guides for Google Workspace, Microsoft 365, and Zoho Mail cover the exact hosts.
  • Deleting an "unused" selector record. If a service is still signing with it, its mail starts failing DKIM immediately. Check your DMARC aggregate reports before removing anything.
  • Copying a stale key after the platform rotated. If you pasted a TXT value instead of the CNAME a platform asked for, the published key silently stops matching at the next rotation.

Don't want to hunt selectors through headers? Your DMARC aggregate reports already list every service signing as your domain and whether each one aligns. PlainDMARC turns them into a plain-English weekly verdict.

See every sender and selector at work — create a free account