Your provider's dashboard shows DKIM turned on. The DNS record has been live for months. Then a deliverability check reports DKIM as missing, your health score drops, and nothing you look at explains why. This is one of the most common false failures in email authentication, and it almost always comes down to one overlooked detail: the DKIM selector.
A DKIM selector is the short label — usually one word — that tells a receiving mail server which DNS TXT record holds the public key used to verify a message's signature. It appears as the s= tag inside the DKIM-Signature header attached to every outgoing message, paired with your domain in the d= tag, and together they point a receiver to a record at selector._domainkey.yourdomain.com. Get the selector wrong, or check for one that was never published, and the lookup fails even though DKIM itself is configured correctly.
What Is a DKIM Selector?
A DKIM selector is the pointer that lets more than one signing key exist for the same domain at the same time. Without it, a domain could only ever have one DKIM record, which would make key rotation or switching providers impossible without a gap in coverage. RFC 6376, the DKIM specification, defines the selector as part of the tag-value list in every signed message, and requires receivers to build the DNS query from it before they can validate anything.
Two domains sending through the same provider will often share a selector name — Google Workspace defaults to google, for example — but the selector itself is just a string. A provider can name it anything, and several do, especially transactional and marketing platforms that rotate keys automatically.
The selector also matters for DMARC. DMARC does not check DKIM directly — it checks whether the domain in DKIM's d= tag matches the sending domain closely enough to count as aligned, then relies on the underlying DKIM check to have already confirmed the signature against the right selector. If a receiver's DKIM lookup fails because it queried the wrong selector name, DMARC sees a DKIM failure too, even though your actual key and record are correct.
Why Do Some DKIM Checks Report a Valid Record as Missing?
A DKIM check has to guess the selector before it can look anything up, because nothing in a domain's base DNS records announces it. Most checking tools keep a short list of common selectors — names like default, google, selector1, selector2, k1, and dkim — and query each one in turn. If your provider signs with one of those, the check passes. If it signs with something else, the check comes back empty, and the report reads as though DKIM were never set up at all.
This produces a specific, frustrating pattern: mail is authenticating correctly at every receiving server that reads the actual signed message, because the message itself carries the right selector. The monitoring check fails anyway, because it never sees the message — it only guesses at DNS names from the outside.
How Do You Find Your Actual DKIM Selector?
The fastest way to find your real selector is to read it directly out of a message your domain already sent, rather than guessing.
- Send a test email from your domain to an account you control that shows full headers, such as Gmail.
- Open the message and view the original or raw source, not the rendered view.
- Find the
DKIM-Signatureheader near the top of the source. - Read the value after
s=— that is your selector — and the value afterd=, which confirms the signing domain. - Query
selector._domainkey.yourdomain.comas a TXT record to confirm the public key resolves. - Give that exact selector to any monitoring tool that lets you add a custom one.
This works regardless of provider, because every compliant DKIM implementation has to include the selector in the header by definition — it is not optional metadata. If your provider has an admin console for email authentication, the selector is often listed there too, sometimes labeled DKIM record name or TXT host rather than selector — read the raw header if the console's wording is ambiguous, since that value is what receivers actually use.
Which Selector Does Each Provider Use by Default?
Defaults vary enough that a one-size list of common selectors will always miss some senders. The table below covers the platforms that come up most often.
| Provider | Typical default selector | Notes |
|---|---|---|
| Google Workspace | Set when DKIM is enabled in the admin console | |
| Microsoft 365 | selector1 / selector2 | Two active selectors for rotation |
| Many transactional senders | Custom per account | Often includes an account ID or random string |
| Self-hosted mail (OpenDKIM) | Whatever the admin names it | Commonly set to default or mail |
A monitoring service that only tries the handful of common names in that first row and a few others will always have a blind spot for the second row. EmailControl checks the common selectors — default, google, selector1, selector2, k1, and dkim — which covers Google Workspace, Microsoft 365, and most transactional providers out of the box, and lets you add a custom one when your provider uses something else. If a check is telling you DKIM is missing and step three above shows a selector outside that list, that mismatch is almost certainly the cause, and it is worth confirming your monitoring is actually watching the record that matters — see the FAQ for how selector coverage works.
Is a Selector Mismatch Worth Fixing If Mail Already Arrives?
It is easy to conclude this does not matter, since messages keep landing in inboxes. The real cost shows up on the DMARC side, not the inbox side. If your monitoring silently reports DKIM as failing when it is actually passing, you lose the one signal that would tell you when DKIM genuinely breaks — a key rotation gone wrong, a provider migration, a DNS record deleted during a domain move. A false failure you have learned to ignore looks identical to a real one, and by the time a real failure changes your open or reply rates, the cause is already days old.
There is also a migration case worth planning for on purpose. When you rotate a signing key or move providers, publishing the new selector's DNS record before the new provider starts signing with it — and leaving the old selector's record in place until you confirm the switch — keeps every message authenticated through the transition. Skipping that overlap is a common reason authentication drops sharply right after a provider change, with no other configuration having moved.
Fix Selector Coverage Before It Costs You a Signal
Pull the selector out of one real message using the steps above, confirm the TXT record resolves, and make sure whatever monitors your domain is checking that exact name instead of guessing from a generic list. Start free monitoring, add your domain, and if the automatic check does not find your provider's selector on the first pass, submit the exact one you found — it takes about a minute and closes the blind spot for good.