SPF is a single record at a single name — which is why our daily email infrastructure report can sweep it across all 623,370 SPF-publishing domains in the Tranco top-1M as of the 2026-07-05 snapshot. DKIM is different. A domain's signing keys are scattered across child names of _domainkey, one per selector, and DNS offers no way to list them. You cannot ask a zone "what selectors do you have?" — you can only guess names and query them one by one. The saving grace for measurement, and the leak for anyone curious about a company's stack, is that selector names are anything but random.
How a selector becomes a fingerprint
When a vendor signs mail on a customer's behalf, it needs the customer to publish (or CNAME-delegate) a key under a selector the vendor chooses. Vendors automate onboarding, so they standardise the selector across their entire customer base. The consequence: the existence of a DNS record at a particular selector name is one-bit-per-query evidence of a vendor relationship.
$ dig +short txt selector1._domainkey.example.com
selector1-example-com._domainkey.example.onmicrosoft.com.
$ dig +short txt k1._domainkey.example.com
dkim.mcsv.net.Two queries, two findings: this domain routes mail through Microsoft 365 and has Mailchimp wired up. The CNAME targets — onmicrosoft.com, dkim.mcsv.net — corroborate the attribution beyond the selector name itself.
A field guide to common selectors
| Selector pattern | Vendor it betrays | Typical shape |
|---|---|---|
google | Google Workspace | TXT with the public key directly |
selector1 / selector2 | Microsoft 365 | CNAME into the tenant's onmicrosoft.com zone |
k1 (k2, k3) | Mailchimp | CNAME to dkim.mcsv.net |
mte1 / mte2 | Mailchimp Transactional (Mandrill) | CNAME into Mailchimp transactional infrastructure |
s1 / s2 | SendGrid | CNAME to sendgrid.net names |
pm | Postmark | pm._domainkey CNAME |
zendesk1 / zendesk2 | Zendesk | CNAME to zendesk mail infrastructure |
The pairs are not decoration — they exist for key rotation, with the vendor alternating between two published selectors so a new key can warm up while the old one still validates. Seeing both selectors of a pair resolve tells you the integration is vendor-managed and rotation-capable; seeing one lone hand-named selector like mail or default often indicates a self-run signer.
The archaeology part: stale keys tell migration stories
DKIM records are write-once in practice. Teams add them during vendor onboarding and almost never remove them at offboarding — the vendor no longer sends, nothing breaks, no ticket gets filed. The result is stratigraphy. A domain whose DNS answers for the Microsoft pair, a Mailchimp k1, an old SendGrid s1, and an mte1 is showing you its history: which platforms it tried, roughly in what order, and which it never cleaned up. Our dataset shows the same inertia on the SPF side — Mandrill includes still stand at 3.37% of SPF domains eight years after the 2016 "sunset" that was supposed to retire the product. Infrastructure decays far slower than the decisions that created it.
A resolvable selector for a vendor you left is not just clutter. If the key is vendor-hosted via CNAME, whoever controls that vendor account — or acquires the infrastructure behind it — may still be able to produce signatures your domain vouches for. Audit _domainkey children when you offboard a sender, the same way you would revoke an API key.
Why every selector survey is a lower bound
Here is the honest-methodology section, in the same spirit as our write-up on where the nightly classification breaks. Selector scanning has a hard epistemic limit:
- You can only find what you already know to ask for. A scan probes a dictionary of known selector names. Vendors with per-customer randomized selectors — Amazon SES is the prominent example — are structurally invisible to it, no matter how large the dictionary grows.
- Custom selectors evade attribution. Some platforms let customers choose selector names; a security-conscious admin who names their Microsoft selectors something bespoke disappears from the fingerprint map while remaining fully functional.
- Presence is not activity. As the archaeology shows, a resolving key proves a relationship existed — not that it still carries mail today. Selector evidence is best read alongside SPF, which declares the currently authorized senders.
This is why the durable, enumerable backbone of our measurement is SPF and MX, with selector conventions as a corroborating lens rather than a headline statistic — the same reasoning that makes us flag SPF flattening as a floor on every ESP share we publish. If you want to run the cross-check on a domain yourself, the workflow is three tools deep: dig mx for the mailbox provider, dig txt for the SPF vendor list, and a handful of selector probes from the table above for the DKIM layer. Ten DNS queries, no permissions required, and you know more about a company's mail stack than most of its employees do.