DKIM Selector Record Not Found: Fix the Missing Key

What the error means

A DKIM lookup tool is looking for one exact DNS name. If that name has no key, your signed mail can fail even when the rest of the domain looks fine.

The selector is the name before ._domainkey. If a message has s=google and d=example.com in the DKIM-Signature header, the public key must be published at google._domainkey.example.com. The DKIM key is a TXT record with a public key in the p= tag. A v=DKIM1 tag is common and recommended when present first, but the key lookup still depends on the exact selector and signing domain.

"DKIM selector record not found" means the receiver, or the test tool, could not find that selector record in DNS. The common causes are simple: the key was never published, it was published under the wrong selector, it was added to the wrong DNS zone, the provider changed selectors, or DNS has not finished propagating.

DKIM is a signing system from RFC 6376. Your mail server signs the message with a private key. Receivers fetch the matching public key from DNS. If the key is missing, they cannot verify the signature. Gmail, Outlook, and other mailbox providers treat that as a real trust problem, especially for bulk or automated mail.

Check the selector first

Do not start by editing SPF or DMARC. First prove which selector your live mail is using.

• Send a fresh message from the system that is failing to a Gmail, Outlook, or test inbox.
• Open the raw message headers and find DKIM-Signature.
• Read the s= value for the selector and the d= value for the signing domain.
• Look up selector._domainkey.domain as a TXT record. Replace both words with the values from the header.
• If the TXT answer is empty, publish the DKIM record from the sender that created the signature.
• If the TXT answer exists but verification still fails, check for a broken copied key, extra quotes, bad line wrapping, or an old private key still signing mail.

Example: if the header says s=selector1 and d=example.com, the record belongs at selector1._domainkey.example.com. A record at default._domainkey.example.com does not help that message.

Be careful with subdomains. Mail signed with d=mail.example.com looks under selector._domainkey.mail.example.com, not under the root domain. This is one of the most common reasons a record looks correct in the DNS panel but cannot be found by receivers.

Fix the DNS record

The right fix is to publish the exact key from the tool that sends the mail.

For Google Workspace, Microsoft 365, Shopify, Klaviyo, Mailchimp, HubSpot, Postmark, SendGrid, and similar senders, turn on DKIM in that product and copy the record it gives you. Some providers use a TXT record. Some use a CNAME that points to a key they host. Use the type they give you.

• Check that the host name is only the selector part your DNS provider expects. Some panels add the domain name for you.
• Publish only the public key. Never paste a private key into DNS.
• Keep old selectors live while old mail is still being delivered or retried.
• After rotation, confirm new outbound mail uses the new selector in the DKIM-Signature header.
• Wait for DNS TTL, then test the selector from outside your network.

If your provider uses CNAMEs, the target must resolve all the way to a DKIM key. If it points to a deleted tenant, a misspelled host, or a provider account you no longer use, lookup tools may still show a DNS answer while DKIM verification fails.

You can run a free InboxRadar domain check after the change. It reads the live SPF, DKIM, DMARC, and MX records and shows the exact item that is still failing.

How this affects DMARC and spam placement

A missing selector can break more than one DKIM test. It can also make DMARC fail.

DMARC, defined in RFC 7489, passes when either SPF or DKIM passes and aligns with the visible From domain. If DKIM cannot find the selector key, DKIM fails. If SPF also fails or uses a domain that is not aligned, DMARC fails too.

That is why the same domain can show several symptoms at once: DKIM selector not found, DMARC fail, and mail going to spam. A DMARC policy of p=none only monitors. p=quarantine asks receivers to treat failing mail as suspicious. p=reject asks them to reject failing mail. Receivers still make their own filtering choices.

SPF matters too. Publish one SPF TXT record for the sending domain, stay under the RFC 7208 10-DNS-lookup limit, and use ~all while you are still checking senders. Move to -all only when you are confident every real sender is covered. Multiple SPF records or a lookup-limit permerror can leave DMARC depending on DKIM, so a missing DKIM selector becomes a bigger problem.

MX records do not prove outbound authentication, but broken MX can hurt replies and domain trust checks. Public blocklists can also affect delivery if your domain or sending IP has a bad history. Authentication comes first because Gmail and Outlook use SPF, DKIM, DMARC, alignment, reputation, complaint rate, and message quality together when they decide inbox or spam.

If you have DMARC aggregate reports, use a DMARC report reader to see which sources are failing DKIM, SPF, or alignment before tightening policy.

Do not confuse DKIM with AI crawlability

DKIM affects email trust. AI search visibility is a separate crawlability problem, but both can break because one DNS or policy file changed.

For AI answers, the crawlers that matter are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews through the normal Search index, and Applebot for Apple Intelligence. Disallowing those in robots.txt removes you from that engine's live discovery path.

Training and opt-out controls are different. GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not remove you from live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent.

Robots.txt is a stated policy, not proof of what any bot did. Perplexity-User and Bytespider have been reported to ignore it, so treat logs as evidence and avoid guessing. Googlebot documents JavaScript rendering. For the other AI crawlers, client-side-only content is an undocumented risk, so keep key text server-rendered when it matters. You can check this with the free AI visibility checker.