DKIM selectors explained, and why 'none found' is not 'no DKIM'

A DKIM selector is the label that tells a receiving mail server where to find the public key for a signed message. The signature header of the message names it, the receiver builds the hostname selector._domainkey.example.com, reads the TXT record there, and uses the key it finds to check the signature. Because the selector is chosen by whoever set up the signing, usually the sending platform, a domain can publish any number of keys under any names, and nothing in DNS lists them. That one fact explains both what a DKIM check can tell you and what it cannot.

What a selector does

DKIM, DomainKeys Identified Mail, is defined in RFC 6376 (2011). The sender signs selected headers and the body of a message with a private key and adds a DKIM-Signature header that carries, among other things, d= for the signing domain and s= for the selector. The receiver looks up <s>._domainkey.<d> in DNS, expects a TXT record of the form v=DKIM1; k=rsa; p=…, and verifies the signature with the public key in p=.

The selector exists so that a domain can hold several keys at once. One platform signs the newsletter, another signs the invoices, and the corporate mail system signs everything else; each has its own key under its own selector, and each can rotate its key without touching the others. Rotation is the second reason: publishing a new key under a new selector, switching signing to it, and retiring the old one later is how a key is replaced without a gap.

A record with an empty p= is a revoked key, which is itself a valid statement under RFC 6376: this selector existed and signs nothing now.

Which selectors the common platforms use

Sending platforms typically use fixed selector names, and because a receiving server never needs the list, the names are simply conventions you can read from their setup instructions.

Two platforms in the same table can point to the same name, and a domain that uses a platform is not obliged to keep the platform's default, so the table is a guide to what is likely, never a guarantee.

What Spaw answers

The domain endpoint carries dkim_selectors, the list of common selectors that publish a key for the domain, read by querying a fixed set of 33 names, the table above plus a dozen more that platforms commonly use. A selector counts when its TXT record carries v=DKIM1 or a p= tag.

curl https://spaw.co/api/v1/email/domain/acme.com \
  -H "Authorization: Bearer sk_live_…"

{
  "domain": "acme.com",
  "dkim_selectors": ["google", "k1"],
  "mta_sts": true,
  "tls_rpt": true,
  "bimi": false,
  "has_spf": true,
  "spf_all": "-all",
  "dmarc_policy": "reject"
}

Three answers are possible, and each means something different. A list of names means those selectors publish keys. An empty list means none of the 33 common names does. null means the lookups themselves failed, typically a nameserver that did not answer, so nothing can be said. The answer is cached for a day, the same as the other policy records the endpoint reads, since keys change slowly and the check is over thirty DNS queries.

The free DKIM checker runs the same check for one domain without a key, and the domain monitor raises dkim_lost when a domain that had selectors in the previous run has none in this one.

Why an empty list is not "no DKIM"

This is the caveat the tool page and the endpoint both carry, and it follows directly from how selectors work. A domain can sign every message with a key under a selector Spaw never asks about, 20250901, say, or acme-prod, and the check reports an empty list for a domain with perfect DKIM. The only way to see such a key is to receive a signed message and read s= from its header.

So the field answers a narrower question than "does this domain use DKIM": it answers "does this domain publish a key under any of the names the big platforms use". That is still useful, in two ways. A listed selector says which platform signs for the domain, which is a fact about who runs its mail. And an empty list at a domain that sends business mail is a prompt to check the headers of a real message rather than a verdict.

Spaw never turns the answer into a risk weight for the same reason. dkim_selectors is information on the domain endpoint; it does not touch the per-address score.

Reading a selector against the rest of the record

DKIM only proves that a message was signed by whoever holds the key. Whether that signer was allowed to speak for the domain is DMARC's question, defined in RFC 7489, and DMARC answers it by checking that the d= of a valid signature aligns with the domain in the visible From address. A domain with a DKIM key under k1 but no DMARC record has a signature nobody is required to act on. The SPF, DKIM and DMARC guide walks through the three together, and the SPF and DMARC checker reads the other two records for the same domain.

A rotation shows up as a change in the list between two monitor runs: the old selector disappears, a new one appears. Only the disappearance of every selector raises dkim_lost, because a rotation that replaces one name with another is healthy.

What to do with the answer

For your own sending domains, use the check to confirm that the key your platform told you to publish is actually there under the name it uses, and keep a domain monitor on the list so a key that is removed during a DNS migration is noticed the same day rather than when deliverability drops.

For a domain you are evaluating, treat a listed selector as a sign of a maintained mail setup and an empty list as an unknown, never as a fault. Combine it with the fields that do decide something: has_spf and spf_all, dmarc_policy and dmarc_pct, mta_sts, parked and mx_blocklisted.

What to do next

• Run a domain through the free DKIM checker.
• Read dkim_selectors beside the SPF and DMARC details on the domain intelligence endpoint.
• Watch a list of sending domains for a lost key with a domain monitor.