Methodology

The selector dataset

The list is one JSON file of provider records, published in full on Selectors and at GET /api/v1/dataset. Each record names a company and its products, the literal selectors it uses, any selector patterns, the DNS record type the customer publishes (TXT or CNAME), where the selector is used (customer domains, the provider’s own domains, or self-hosted software), a status, a confidence level (how sure the dataset is that the provider uses these names), notes, source URLs and a last_verified date. A short list of generic selectors, used by many systems and tied to none, sits beside the records. Two tables in the code are published with it: CNAME-target suffixes that identify a provider, and the MX, SPF and DMARC rules that decide which selectors to try first.

Where the records come from

The vendor’s own documentation comes first. A claim about a provider rests on a page fetched from that provider; a search snippet, a cached summary or a page behind a login does not count. Live DNS on a customer domain is the second kind of evidence. Third-party selector lists and open-source wordlists are leads to check.

Every observation in DNS is paired with a control: a random selector queried on the same domain. If the control also answers, the domain has a _domainkey wildcard and the observation is void.

The admission bar for a literal selector

Every literal selector costs one DNS query for every domain anyone scans, so the rule for adding a name is that both of these hold:

1. It is used on customer domains, not only on the vendor’s own. A selector seen only on a vendor’s domain shows that the vendor signs its own mail, nothing more.
2. A vendor page fetched for the check names it, or it answers on a customer domain that has no wildcard.

Selectors a provider generates per account, per identity or per key cannot be guessed. They are recorded as patterns, which describe the scheme and are never probed.

Vendor, observed and legacy

On the provider pages a selector’s source reads Vendor documentation when the provider’s own documentation names it, and Observed elsewhere when it comes from DNS or third-party lists. CNAME-target suffixes carry a similar basis: documented in the provider’s setup guide, observed on real DKIM records, or inferred from a mail domain the provider runs, which counts for less.

When a vendor’s current pages name different selectors, or a generated scheme, the literals they no longer support are not deleted. They move to a separate legacy record with their original sources and confidence, and stay on the probe list, because older accounts and old mail still carry them. A later DNS round on customer domains either confirms each one or retires it to historical. A legacy record split out this way has no verification date, since no current vendor page supports it.

What “last verified” means

A record’s last_verified is the date its vendor documentation was read and found to support the record’s literal selectors or its documented scheme. It stays empty when the vendor page could not be fetched, or was fetched but names no selector and no scheme. It does not mean every literal was seen in DNS that day: where a vendor lets the customer choose the selector, the record can still list common names the page does not mention. The date at the foot of a reference page is the day that page’s facts were last checked against its sources.

How discovery ranks and bounds its lookups

A scan starts with four lookups: MX, the TXT records at the domain’s apex (for SPF), the _dmarc record, and a random selector to detect a wildcard. Hint rules match MX hosts, SPF include: and redirect= domains, and the hosts in DMARC report addresses. The selectors of every matching provider go first, in hint order. The rest follow by confidence, high to low, with provider selectors ahead of generic ones and ties broken alphabetically. Every literal on the list is checked; a hit does not stop the scan.

The browser sends the candidates in chunks of 40, and the server checks at most six at a time. Each chunk is one request to a Cloudflare Worker, which keeps every request inside the platform’s limit on outbound fetches. For N candidates a full scan costs N + 4 DNS queries and 1 + ⌈N/40⌉ requests. With a little over two hundred candidates that is seven requests. A single-record check costs two queries, the selector and the wildcard probe.

What a selector name proves

A record’s confidence is about the list: how sure it is that a provider uses a name. A key found under that name on some domain is a separate question, and the attribution on each result answers it with the evidence it has, weakest first:

1. Selector name alone: a hint. Names such as s1, k1, selector1 and default are shared or generic. The name says who might use it, not who owns this key. The attribution shows it as “selector name only: a hint”, at medium confidence at most.
2. Name plus the domain’s MX, SPF or DMARC records pointing at the same provider: likely. It shows the domain uses that provider, not that this key is theirs, because mixed setups are common, such as Google for mail and SendGrid for marketing. For providers that publish a TXT key on the customer’s own domain (Google Workspace, Zoho and many mailbox hosts) this is the most DNS can show. Discover marks such hits “likely”.
3. CNAME target in the provider’s zone: strong. The domain handed its key to that provider. Name plus CNAME is the top rung, shown as “selector name and CNAME target” at high confidence.
4. A real signed message, read from the s= and d= tags: it proves the selector signs live mail for that domain. It names the provider only if the key is also a CNAME to one.

Some evidence counts against a name. A provider that only publishes CNAMEs, such as Microsoft 365, is not supported by a TXT record reached with no CNAME. A CNAME that points into another provider’s zone outranks the name. In both cases the name-only match drops to low confidence, as it does when the name is generic or several companies list it.

What dkim.fyi cannot know

1. Which selectors a domain uses. DNS cannot list them, so a miss against the list proves nothing.
2. Whether a published key is in use. A record shows that a key exists at a name, not that current mail is signed with it.
3. Anything outside the public view. Queries go over DNS-over-HTTPS to Cloudflare’s 1.1.1.1 resolver, with Google’s as a fallback. A zone that answers differently inside a company network (split horizon), or a change that has not reached the resolver yet, will look different from here. Single-record checks may use an answer cached for up to five minutes; the selector lookups of a scan never use the cache.
4. Whether DNSSEC holds. dkim.fyi does not validate DNSSEC itself. It reports the resolver’s authenticated-data (AD) flag as "validated" or "not validated", and a SERVFAIL can mean the resolver’s own validation failed.

Corrections

Send corrections to corrections@dkim.fyi. Name the provider and selector, and include the vendor page or a domain that shows the problem.

A wrong attribution is fixed the same way a record is added: the vendor page is fetched again or the selector is checked on customer domains with a control, the record is changed, and its sources and date are updated. A selector that is out of date usually moves to a legacy or historical record rather than being deleted, since old mail still carries it. One whose only evidence turns out to be void, such as a wildcard answer, is removed.

Privacy

There are no accounts, cookies or analytics. Lookups are not stored beyond the few minutes of DNS caching, and messages pasted on Headers are parsed and not kept. The email check reads only the headers of the messages it receives and keeps a minimal analysis for 24 hours or until you delete it. A separate private catalog records each signing domain and selector pair it sees, unlinked to any address or session, and is not published. The resolvers see the names being queried. About has the details.