What is a DKIM selector?

A DKIM record is a TXT record at a subdomain built from the selector. The selector goes first, then the fixed literal _domainkey, then your domain:

google._domainkey.yourdomain.com   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBg…"
└─ selector    └─ fixed literal

There is no record that lists your selectors. DNS gives you no way to ask “which DKIM keys does this domain publish?” — you can only ask about a name you already know. That single fact explains most of this page: finding a selector means either reading it off a message you sent, or guessing well.

This is the exact list our checker probes, grouped by who publishes each one. If your provider is not here, it either mints a per-account selector (see below) or has you publish a CNAME that points at a record it hosts.

The table tracks our probe list rather than a provider’s current documentation. Providers do change selectors; when one does, the authoritative answer is still the s= tag on a message you actually sent.

In rough order of how often each one is the actual cause:

1. Wrong selector. The commonest cause by a distance. The record is fine; you are asking for the wrong name. Read s= off a real message rather than guessing.
2. You looked up the bare domain. There is no DKIM record at the apex. It lives one level down, under the selector.
3. The CNAME is not followed. Most providers have you publish a CNAME pointing at a TXT record they host. If it is missing, mistyped, or your DNS host silently flattened it, the lookup dead-ends.
4. DNS has not propagated. A new record can take up to the zone’s TTL. Minutes usually, an hour sometimes.
5. Your DNS host appended the domain twice. Entering a fully-qualified name where the host expects a relative one produces google._domainkey.yourdomain.com.yourdomain.com. Check the record’s resolved name, not what you typed into the box.
6. The key was rotated and the old selector retired. Mail signed with the old selector now fails while new mail passes — see rotation below.

Publishing several selectors at once is normal and correct — one per sending service:

google._domainkey.yourdomain.com   →  Google Workspace (staff mail)
k1._domainkey.yourdomain.com       →  Mailchimp (marketing)
s1._domainkey.yourdomain.com       →  SendGrid (transactional)

Each service signs with its own key; a receiver fetches whichever one the s= tag names. Nothing conflicts, and there is no limit worth worrying about.

Rotation means publishing a new selector, moving signing to it, then retiring the old one — after every message signed with it has aged out. Retire it too early and mail still in flight fails DKIM. A common cadence is two selectors alternating every 6–12 months.

This is also the failure DMARC reports surface first: one service starts failing DKIM while the rest keep passing, usually because its key was rotated at the provider and the DNS record was never updated.

Worth separating, because these three get conflated constantly:

• s= (selector) — which key to fetch. Purely a lookup detail.
• d= (signing domain) — who claims responsibility for the message. This is what DMARC cares about.
• Alignment — DMARC passes on DKIM when d= matches the visible From: domain. The selector plays no part in alignment. Sign with any selector you like; what matters is that d= lines up.

Hence a frequent misdiagnosis: “DMARC fails, so the selector must be wrong.” If DKIM verified at all, the selector was right — the problem is d= not aligning. The DMARC checker reads the policy side of that.