What Is a DKIM Selector? (And Why “DKIM Missing” Is Often Wrong)

You ran a free checker, it told you DKIM is missing, and you panicked — even though your email has been signing and delivering fine for months. Before you change anything, know this: a huge share of “DKIM not found” warnings are false alarms. The checker simply looked in the wrong spot. The thing it didn’t know how to find is called a selector.

If you want the full picture of how DKIM fits alongside SPF and DMARC first, start with our plain-English guide to all three. This post zooms in on the one piece that trips up nearly every checker.

DKIM in one sentence

DKIM (DomainKeys Identified Mail) signs every message you send with a private key, and publishes the matching public key in your DNS. The receiving server fetches that public key, verifies the signature, and confirms the message really came from your domain and wasn’t altered in transit. Simple enough — the catch is where that public key lives.

The selector is the address of your DKIM key

A domain can have many DKIM keys at once — one for Google Workspace, one for your marketing tool, one for your support desk. So DKIM keys aren’t stored at a single fixed location. Each one lives under a unique label called a selector, at a DNS record shaped like this:

<selector>._domainkey.yourdomain.com

The selector is chosen by whoever generates the key — usually your email provider, automatically. A few real examples:

• Google Workspace — google._domainkey
• Microsoft 365 — selector1._domainkey and selector2._domainkey
• SendGrid — s1._domainkey and s2._domainkey
• Mailchimp — k1._domainkey

There’s no way to guess a selector from the domain name alone. That’s the whole problem.

Why generic checkers cry “missing”

Naive DKIM checkers ask you to type a selector, or they try one or two common guesses (default, dkim) and give up. If your provider uses anything else — and most do — the check comes back empty and reports DKIM as missing, even though it’s published and working perfectly. You’re being told you have a problem you don’t have.

The only reliable way to find a selector without guessing is to look at a real signed message: open an email you sent, view the raw headers, and find the DKIM-Signature line. The s= tag in it is your selector, and d= is the signing domain. A better checker detects your provider and knows which selectors to look for automatically — that’s exactly what our free DKIM checker does, so you get a real answer instead of a false alarm.

The failures that are actually real

False alarms are common, but genuine DKIM problems do exist — they just look different from “missing”:

• A revoked key. A DKIM record with an empty p= value silently switches signing off. The record is there; it just doesn’t work.
• A rotated key never re-published. Your provider generated a new key during a migration, but the matching DNS record never got added — so signatures fail to verify.
• DKIM enabled in the dashboard but never published in DNS. You flipped the switch in your provider’s settings but skipped the DNS step.
• A truncated record. DKIM public keys are long, and some DNS hosts split or cut them off, corrupting the key.

How to check yours the right way

Run your domain through the free DKIM checker — it identifies your email provider, looks for the correct selector on both your apex and sending subdomains, and tells you whether your key is present, valid, or revoked. No selector guessing, no false “missing” verdicts.

The harder part is that DKIM drifts. Providers rotate keys, migrations drop records, and a signature that verified yesterday can break today — silently, with no error, just a slow slide toward the spam folder. That’s why Zeqo Mail monitors your DKIM every day and alerts you the moment a key disappears or is revoked. For the bigger picture on why authenticated mail still misses the inbox, see the real reasons email lands in spam.