DKIM Selector Not Found: How to Find and Verify Your Selector

A DKIM selector is the label your sending provider chose for a signing key, published at selector._domainkey.yourdomain.com. A “selector not found” message usually means either the record is not in DNS yet or the checker guessed a different selector. Find the real one in a sent message’s DKIM-Signature header (the s= value) and query that exact name.

How selectors work

When your provider signs an outgoing message, it adds a DKIM-Signature header that includes two important tags: d= (the signing domain) and s= (the selector). Receivers combine them into a DNS name, s._domainkey.d, fetch the TXT record there and use the public key to verify the signature.

Because the selector is just a label, nothing stops one domain from having many. A company might have google._domainkey for Workspace mail, s1._domainkey for a marketing platform and k1._domainkey for a newsletter tool. Rotating keys uses new selectors too. This flexibility is why DKIM cannot be found by scanning for a single fixed name.

Why checkers miss selectors

A public checker has no access to your provider’s settings. It tries a list of common selector names and reports what it finds. BusinessMCP’s free deliverability checker states exactly this on its page: DKIM results depend on selectors, the tool tries the most common ones, and it may miss a custom selector, so a miss should be checked in your provider’s console rather than treated as a confirmed failure.

That caveat is a reason to read DKIM results differently from the other three. A missing SPF or DMARC record is a plain fact. A missing DKIM record is a question.

Situation	What it likely means	What to do
Checker finds DKIM, headers show dkim=pass	Healthy	Nothing
Checker misses DKIM, headers show dkim=pass	Custom selector, tool did not guess it	Ignore the miss, note your selector
Checker finds DKIM, headers show dkim=none	Key published but provider not signing	Enable signing in provider
Checker misses DKIM, headers show dkim=none	Not set up	Generate key, publish records
Headers show dkim=fail	Signature broken or key mismatch	See troubleshooting below

Key takeaway: the message header is the ground truth for DKIM. A third-party scan is a hint.

Find your selector in three ways

From a message header.

1. Send a test from the service you want to check to a Gmail address.
2. Open the message, choose “Show original”.
3. Find the DKIM-Signature: header and read s= and d=.
4. Query s._domainkey.d with any DNS lookup tool, asking for TXT (or CNAME).

From your provider’s console. Most services have a “domain authentication”, “sender authentication” or “DKIM” page that lists the exact host name to publish.

From your DNS zone. Look for records ending in ._domainkey. Each one corresponds to a service that was set up at some point.

Publishing the record correctly

Providers give you one of two formats.

• TXT record containing v=DKIM1; k=rsa; p=<long public key>. Long keys may need to be split into quoted strings if your DNS host has a 255-character limit per string; many hosts handle this for you.
• CNAME record pointing to a name the provider controls, so the provider can rotate keys without you touching DNS.

Common publishing errors:

• Including your domain twice, such as google._domainkey.yourdomain.com.yourdomain.com. Some DNS hosts append the zone automatically; enter only google._domainkey there.
• Pasting line breaks or stray quotes into the key.
• Truncating the key, which breaks verification.
• Publishing at the wrong domain when sending from a subdomain.

Key size matters too. BusinessMCP’s guide notes Gmail requires at least 1024-bit keys for personal accounts and that 2048-bit is the common default. Use 2048 where your DNS host supports the length.

Troubleshooting a dkim=fail

If the headers show a failure rather than none:

1. Key mismatch. The published key does not match the one your provider uses, often after regenerating a key in the console without updating DNS.
2. Message modified in transit. A mailing list, footer-adding gateway or security tool altered the body after signing.
3. Stale DNS. You changed the record and it has not propagated. Changes can take up to about an hour depending on TTL.
4. Expired or rotated selector. The provider moved to a new selector and the old record is irrelevant.

Fix one thing at a time and re-test with a fresh message. Old messages keep the old result.

DKIM and DMARC alignment

DKIM passing is not the same as DMARC passing. DMARC wants the d= domain to match your visible From domain. If your marketing platform signs with its own domain, DKIM can pass while DMARC still fails. Enable custom-domain signing so d= is yours. This is covered in the SPF, DKIM and DMARC setup guide and BusinessMCP’s SPF, DKIM and DMARC guide.

Key rotation hygiene

Keys should be rotated from time to time. If your provider uses CNAMEs, rotation is automatic. If you publish TXT keys yourself, publish the new selector first, switch signing, wait, then remove the old key. Never delete the old record before signing has switched, or in-flight mail will fail. Document which selector belongs to which service in a short note, so a future teammate does not delete a live key believing it is stale.

Next steps

Once DKIM is verified, return to the wider audit: check email deliverability walks through all four records. If the selector is right and authentication passes but mail still misses the inbox, see why emails go to spam despite passing SPF, DKIM and DMARC. For the DKIM specification itself, RFC 6376 is authoritative.

Selector naming patterns you may meet

Selectors are arbitrary, but providers tend to follow habits. Knowing them speeds up detective work, though you should never rely on a pattern without confirming it in the console or a header.

Pattern	Typical meaning
google	A common default for Google Workspace
selector1, selector2	Often used by Microsoft 365, which rotates between two
s1, s2	Used by several email platforms for a primary and secondary key
k1, k2	Seen with some newsletter tools
Dates or random strings	Keys generated per domain or per rotation

If you manage several tools, record each tool’s selector in one place. When a checker reports a miss, compare against that list before assuming anything is broken.

Checking DKIM with a command line

If you prefer raw answers, query the TXT record directly, substituting your own selector and domain:

dig TXT google._domainkey.yourdomain.com +short

You should see a string beginning v=DKIM1. An empty answer means nothing is published at that name. A CNAME answer is also valid when the provider hosts the key. This is exactly what a graded checker does behind the scenes, only for a list of guessed selectors. When you already know your selector, a direct query is more reliable than any scan.

Why the grade still helps

None of this makes a checker useless. Run the domain through BusinessMCP’s free checker to get the other three records graded together, and treat the DKIM line as a prompt rather than a verdict. For the wider requirements that make DKIM mandatory for bulk senders, see BusinessMCP’s Google and Yahoo sender requirements guide and our bulk sender summary, which note that bulk senders need both SPF and DKIM.