How we measure

Generic top-level domains must publish their zone files; country-code registries choose whether to, and many do not. Our zone files arrive through one aggregator rather than from each registry, so a registration in a TLD with no published zone enters the corpus only when something else shows it, such as a certificate.

New-domain and removal counts are therefore floors for the TLDs zone files cover, not counts of registrations everywhere. The day-by-day history of additions also has a gap, stated on the figures it affects.

An MX record names the server that accepts a domain's mail. When that server is a security gateway or a forwarder, the mailbox provider behind it does not appear in DNS at all.

That is why provider shares are computed over the domains whose MX names a provider we recognize, not over every domain that runs mail. A domain behind a gateway is counted under the gateway or not at all, never under a mailbox provider we guessed.

We see what any resolver on the public internet sees. Names an organization resolves only inside its own network, and answers it gives differently to insiders, never reach us.

Every figure here is a statement about public DNS. A company's internal mail routing, internal services and private zones are outside it.

DNS cannot be asked to list the names under a domain. We learn a subdomain when a certificate is issued for it, which certificate transparency logs make public, or when we resolve a name we already had reason to ask about.

Any count of subdomains, or of services found on them, is a floor. A subdomain with no certificate and no reason to be asked about is not in it.

The corpus is event-driven with a sweep under it. A domain is resolved when a certificate or a zone file shows it, and every registered domain is also re-resolved on a rolling cycle: about a week for the domains we score as riskiest, two weeks for medium risk and a month for the rest. A domain with no certificate or zone activity is only as fresh as its last turn in that cycle.

New names are polled closely while they are new. A name a certificate shows before it has an address or a delegation is re-asked from every few minutes up to every few hours for its first day, or three days for names on hosting platforms, for its address and delegation, with its mail records as detail. That is a watch on new names, not on the whole corpus.

A figure describes the corpus on its data date and nothing more. DNS changes continuously, so two figures with different dates are two snapshots, and a difference between them is not automatically a trend.

Some signals arrive in bursts. Impersonation domains, for example, are registered in waves, so a single day can be unrepresentative; those figures are measured over a stated window rather than a single day.

We recognize a parked domain by the nameservers or CNAME of a known parking platform. A domain parked on its own nameservers, or on a platform we hold no signature for, counts as an ordinary domain.

Parked domains publish authentication from a template, so every adoption figure is reported with parked domains separated out.

MTA-STS has a DNS half and a policy file served over HTTPS. Where a domain publishes the DNS record but we hold no policy mode, either the file is not served or we did not retrieve it, and we cannot tell which.

We record that a delegation is signed. Whether its signatures validate today, with current keys and an intact chain to the root, is a separate test we do not run on the whole corpus.

A CAA record is checked by a certificate authority when a certificate is requested. Its presence says which authorities may issue in future; it says nothing about certificates that already exist.

A prefix announced by more than one network is often deliberate. We separate multi-origin arrangements that have held for more than a month from new ones, and count the remainder as candidates worth investigating, not as confirmed hijacks.

Routing is observed from our collection points. An announcement visible only in a region we do not see is not in these figures.

A domain is attributed to the network its primary address is announced from. A domain with no address record sits on no network, so concentration figures are ranked over attributable domains, not over every domain.

More networks announce address space than carry any domain we can attribute. The two network counts answer different questions and do not nest.

Every ESP detection is classified by the strongest signal behind it. Active: a DKIM selector CNAMEd into the provider that still serves a key, or a sending subdomain CNAMEd, delegated or given an MX at the provider, observed within the last 90 days. Configured: the domain's own SPF record includes the provider. Verified: a TXT verification token, and nothing stronger.

Headline figures are active plus configured. Verified is published on its own and never added in, because a token proves only that the domain was verified at some point.

DNS records are rarely cleaned up. A verification token stays after the account is closed, an SPF include stays after the provider is replaced, and a CNAME can point at a provider that no longer serves it.

Active evidence is re-checked, and a DKIM CNAME counts only while the provider still serves its key. Configured and verified evidence are not re-checked against the provider and can describe a past relationship.

A DKIM key lives under a selector name the sender chooses, and DNS cannot be asked which selectors exist. We ask for the names providers are known to issue, so a DKIM-based count is a floor, not a census.

Certificates cannot name DKIM selectors, so certificate transparency does not help here. It tells us which domains to probe, not which selectors to ask for. Only a selector CNAMEd into the provider's own zone counts as active. A key published directly as text names no provider and is reported separately.

Some providers cannot be detected by DKIM at all: their selectors carry an account number (Amazon SES, HubSpot, SMTP2GO, Constant Contact), or no selector of theirs is in the probe (Salesforce, Oracle, Adobe, Dotdigital, Infobip and most European ESPs). For those, a sending subdomain or SPF is the only evidence we have.

Some domains replace a provider's include with the provider's IP ranges, to stay under SPF's lookup limit. The provider's name then disappears from the record.

We do not map those ranges back to providers: a range in a shared cloud names the cloud, not the ESP running on it. A domain with a flattened record counts as configured for an ESP only if it also includes the ESP by name.

Many platforms send through another company's infrastructure. We count the operator the record names: a DKIM key served from SendGrid's zone counts as SendGrid, even when the selector belongs to a platform built on it, and a tenant of a platform that runs on Mailgun counts as Mailgun unless its own DNS names the platform.

Providers are counted by operating group: brands one company owns are one group, so a domain using two of them counts once.

A domain counts under every operating group its DNS names: a marketing platform and a transactional provider is a common pair. Shares by group therefore sum to more than the share using any ESP.

A service shows up in DNS only when it needs something there: mail authorization, a verified domain, a branded subdomain. CRM, finance, HR and most internal tools need none of these.

No detection is not evidence of non-use. SaaS figures are published only for categories with strong DNS signals.