"No DKIM Found" Means Nothing Until You Know Who Runs Your Mail (2026 Study)

DKIM has a design property that makes it uniquely awkward to check: selectors cannot be enumerated from DNS. A DKIM key lives at <selector>._domainkey.<domain>, and there is no record that lists which selectors exist. If you do not already know yours, the only way to find it is to guess.

Every DKIM checker on the web guesses. They have to. Each one ships a hand-picked list of likely selectors, fires a query at each, and reports what comes back. When nothing comes back they tell you "DKIM not found" — and that message is doing something dishonest, because it looks like a finding about your domain when it is really a statement about the checker's word list.

We wanted to know how misleading that is. So we probed 48 candidate selectors against the top 5,000 domains on the web, and joined every result to the domain's mail provider.

The short answer: a negative DKIM result is worth about 97% on Cloudflare Email Routing and about 4% on Amazon SES. Same message, same wording, wildly different meaning — and no checker tells you which one you just got.

This is our own measurement, run on 20 August 2026. The method is below in full, and the harvesting script ships with it.

The headline numbers

Of 5,000 domains, 121 answered nearly every selector identically — wildcard TXT records rather than real keys — and are excluded. That leaves 4,879 domains.

That last row is the first thing to understand about the 46.1%. Roughly a quarter of the sample are infrastructure domains — CDN hostnames, ad-serving domains, tracker endpoints — that never send or receive human mail and have no DKIM to find. They belong in the denominator (a domain with no MX can still send mail, so we cannot simply drop them), but they drag the headline down. Among domains that actually handle mail, 63.1% expose a selector a checker could guess.

The share barely moves with popularity:

Unlike DMARC adoption, which climbs sharply at the top of the list, guessability is flat. That is the first hint that this is not a maturity question. Nobody chooses a guessable selector because they are sophisticated, or an unguessable one because they are careless. It is chosen for them.

Guessability is set by your provider, not by you

Splitting the same domains by mail provider is where the number stops being an average and starts being useful.

The spread is not a gradient — it is close to bimodal. Managed providers that mint one fixed selector per customer sit between 69% and 97%. Providers where each customer generates their own key, or where sending is done through an API with per-account selectors, sit under 10%.

Cloudflare Email Routing is nearly deterministic: 35 of its 36 domains answer at cf2024-1. Microsoft 365 is selector1 and selector2, which is why those two rank so high globally despite Microsoft being a third of Google's share here.

Amazon SES is the opposite, and it is the one worth naming. Of 52 SES domains, two exposed anything guessable. That group includes playstation.net, onlyfans.com, bamgrid.com (Disney's streaming backend) and a cluster of Samsung service domains. These are not domains without DKIM. They are domains whose DKIM you cannot find by guessing, because SES issues per-identity selectors that look like abcd1234efgh5678._domainkey.

Run any public DKIM checker against playstation.net and it will tell you no DKIM was found. That is a false statement about a domain that almost certainly signs everything it sends.

Google is two different answers to the same question

Google Workspace is the largest group in the sample at 1,195 domains, and 77.5% of them are guessable — almost all via the plain selector google.

But run the check against Google's own domains and you get nothing:

google.com · youtube.com · youtu.be · doubleclick.net · ytimg.com · googlesyndication.com · googleadservices.com

All Google Workspace by MX. All showing zero guessable selectors. Google signs its own mail with dated, rotating selectors in the 20230601 style — deliberately unguessable, rotated on a schedule — while handing Workspace customers a static google.

We went into this expecting Google to be the canonical unguessable case, because google.com is the example everyone tests a checker with. That intuition was exactly backwards for the overwhelming majority of Google-hosted domains, which are customers rather than Google. It is a good reminder that the domain you reach for as a test case is often the least representative one in the population.

What a negative result is actually worth

Put the two halves together and you get the practical finding.

When a checker says "DKIM not found":

• On Cloudflare Email Routing, Yandex, or Microsoft 365, that is real information. 84–97% of such domains would have answered. A silence is genuinely surprising and worth investigating.
• On Amazon SES or Tencent Exmail, it is close to meaningless. Fewer than 7% of those domains answer a guessed selector, so silence is the expected result whether or not DKIM exists.

No checker we are aware of makes this distinction. They all report the same flat negative, which means that for a meaningful slice of the web the single most common DKIM diagnostic on the internet is unreliable in a way the user cannot see.

The fix is cheap, which is the annoying part. Any checker already querying MX — ours does, to report mail routing — has everything it needs to qualify its own answer. It costs zero additional DNS queries to say "no DKIM found at 11 common selectors; your provider is Amazon SES, which does not use predictable selectors, so this result does not mean you lack DKIM."

Eleven selectors do 97.6% of the work

The other reason to run this was to check our own probe list. A checker's selector list is a latency budget — one DNS query per selector, per check — so the goal is never a longer list, it is a better one.

Running a greedy set-cover over the results (repeatedly take the selector that adds the most not-yet-covered domains) gives:

Two things worth taking from this.

The curve flattens hard. Selectors 12 through 20 add 1.9 percentage points between them. A 20-selector list is nearly double the query cost of an 11-selector list for a rounding error of extra coverage.

Paired selectors are near-redundant. k3 appears on 440 domains — and on zero domains that do not also have k2. Probing both is a wasted query every single time. zendesk2 adds 3 domains beyond zendesk1. The exception is selector2, which appears on 70 domains without selector1, because Microsoft rotates between the two; it earns its slot where the other second-halves do not.

Our shipped list was chosen from a 300-domain pilot by frequency ranking. At 5,000 domains with proper set-cover it comes out as the same eleven selectors, covering 97.6%. That is a boring result and we are reporting it anyway: the interesting outcome of a verification is not always a change.

What to do about it

If you run a DKIM checker: query MX first, and qualify your negative. You already have the data.

If you are checking your own domain: find your selector from a message you actually sent rather than from a guesser. Open any delivered email, view the raw source, and read the s= tag in the DKIM-Signature header. That is authoritative, takes ten seconds, and works regardless of provider.

If you check MTA-STS too: the same gap between "present" and "working" is larger there than here — a policy URL can return HTTP 200 and serve an HTML page, which a reachability check passes and a parse does not.

If you are on Amazon SES, Tencent Exmail or GoDaddy: assume public checkers cannot see your DKIM, and do not treat their "not found" as a finding either way.

You can run any domain through our DKIM and DMARC checker, which probes the eleven selectors above.

Method

Sample. The Tranco top 5,000, list ID ZJGPG — the same list our DMARC, provider market share and SPF lookup-limit studies use, so all four join on domain.

Queries. For each domain: one MX query, plus one TXT query at <selector>._domainkey.<domain> for each of 48 candidate selectors — 245,000 queries in total, over DNS-over-HTTPS against Cloudflare's 1.1.1.1 resolver.

Candidates. 48 selectors drawn from provider documentation and common practice. Dated and rotating selectors are deliberately absent, because they cannot be guessed — which is the property being measured.

A hit is a TXT record matching v=DKIM1. We separately record whether the key is live: RFC 6376 specifies that an empty p= means the key has been revoked, so a revoked key is a hit but not a working one. Of 5,860 total hits, 162 (2.8%) were revoked keys. The rate is much lower among the common selectors — 0.37% for google, 0.47% for selector1 — so most revocations sit in the long tail, where a domain has left an old provider and abandoned the key rather than removing it.

Provider is classified from the lowest-preference MX hostname, the same method as our provider market-share study.

Wildcard exclusion. A domain answering nearly every candidate with an identical record has a wildcard TXT entry, not real keys. Counting it would inflate every selector simultaneously. 121 domains were excluded this way.

Reproducing it. The script is committed at scripts/study-dkim-selectors.mjs. Run it against any Tranco CSV:

node scripts/study-dkim-selectors.mjs tranco.csv 5000 out.json

Limitations

This measures guessability, not DKIM adoption. We cannot report what share of domains publish DKIM, and neither can anyone else using this method. A domain on a rotating selector is invisible to us. Every number here is "share exposing a guessable selector", and the gap between that and true adoption is unknown — and is precisely the point of the article.

Three wildcards escaped the filter. xxxhindi.to, about.me and brevo.com answered 47–48 selectors with records that varied slightly, so the identical-record test did not catch them. They inflate each selector's count by up to three, which is immaterial against totals of 250–1,090, but it is there.

Small provider samples. Proton (13 domains), GoDaddy (13), Namecheap (15) and Mailgun (16) are too small to carry confident percentages. They are in the chart for shape, not precision. Google, Microsoft, Proofpoint and the self-hosted group are the only groups large enough to lean on.

Provider classification is MX-based, so it identifies who receives mail for a domain, not necessarily who sends it. A domain receiving on Microsoft 365 and sending marketing through SendGrid is counted as Microsoft. This is the same limitation our provider market-share study carries, and it is why the self-hosted bucket is large and internally mixed.

One resolver, one point in time. All queries went to Cloudflare on 20 August 2026. We did not test whether other resolvers return different results, and DKIM keys rotate, so a re-run will not reproduce this exactly.