The verification-token census: third-party tokens in DNS, ranked

A verification token is a TXT (Text) string at the apex of a domain, shaped <token>=<value> or <token>:<value>, that isn’t an SPF (Sender Policy Framework), DMARC (Domain-based Message Authentication, Reporting and Conformance), DKIM (DomainKeys Identified Mail) or v= record. It’s the string a service asks you to publish to prove you control the domain before it sends mail as you or issues you a certificate. This page is the ranked count of those tokens in the October 2026 census. The denominators and the counting threshold come before the ranking, and the full table ships as CSV and JSON twins.

Two denominators, before any row

Each percentage on this page is computed against one of two bases, and both are stated here so you can see what the ranking is a ranking of.

The first is txt_present: 174,990,877 domains published at least one apex TXT record in the census. That’s the pool the extraction searched. A domain with no TXT record at all can’t carry a token and isn’t in this number.

The second is token_present: 46,336,520 domains carried at least one verification-style token, which is 26.48% of txt_present. The rest of the pool holds the ordinary apex strings, SPF records above all, which the extraction set aside on purpose because they answer a different question.

Both share columns in the table are computed against one of these two bases, so a percentage from the table only means something inside that pool. This page never states a token count as a share of all domains, and if you cite a row you shouldn’t either, because the pool is domains with a TXT record and the ranking means nothing outside it.

The counting threshold, which makes each row a floor

The rollup covers 1434 TLD (Top-Level Domain) partitions. A token is counted only where at least three domains in the same TLD carry it; smaller per-TLD tails are not in these sums. A token published by two domains in a small country-code TLD adds nothing to its row, so treat each row as a floor on the true count.

The threshold is there to keep one-off private strings and typos out of the ranking. The cost is an understated tail in TLDs with few registrations, and you should read the TLDs column with that in mind: it counts partitions where the token cleared the threshold, which is a stricter test than “seen at least once”. The order of the rows is by domain count alone.

The ranked table, top 20

Each token is printed as the exact matched string, in code formatting, because the exact string is what you’ll grep your own zone file for. The columns are the sheet’s own: rank, token, domains, share of txt_present, share of token_present, and the number of TLDs in which the token cleared the threshold.

The full 80 rows ship as CSV and JSON twins of this page, with the same columns and the same values, so an analyst or an engine can cite the row itself.

What the top and the tail of the table say

google-site-verification is first, on 30,511,620 domains, 17.44% of the 174,990,877 that publish any apex TXT record and 65.85% of the 46,336,520 that carry any token, and it cleared the threshold in 891 TLDs. It’s the string a site owner publishes to claim a property in a search console, and it appears in more TLDs than anything else on the list.

ms is second on 8,456,816 domains, 4.83% of txt_present and 18.25% of token_present, across 834 TLDs. That’s the Microsoft 365 tenant marker, the MS= record an admin adds when attaching a custom domain to a tenant. From there the counts fall away quickly, and by row 80 trustpilot-one-time-verification-id is on 20,926 domains, 0.01% of txt_present and 0.05% of token_present, in 162 TLDs. The published table stops at row 80, and the twins carry those same 80 rows.

One vendor, two strings

A naive grep undercounts, because some vendors have published two different token names for the same product. GlobalSign appears as _globalsign-domain-verification on 496,990 domains and as globalsign-domain-verification on 119,471. Canva appears as canva-domain-verify on 263,966 domains and as canva-site-verification on 29,614. Mail.ru appears as mailru-domain on 119,880 and as mailru-verification on 58,275. Brevo, which used to trade as Sendinblue, is on 1,396,088 domains as brevo-code and is still on 141,006 as sendinblue-code.

When you write a detection rule, match both forms. When you read the counts, don’t add the two rows together: the census counts distinct domains per token, a domain can carry both strings, and the overlap between each pair isn’t on the sheet. The leading _ in _globalsign-domain-verification is part of the token as published, so a rule that strips punctuation before matching will merge two rows the census keeps apart, and a rule that anchors on a letter will miss the larger of the pair.

Rows that aren’t vendors

Some rows don’t name a vendor at all. Strings like include, ip4, mx and https in the full table look like fragments of SPF records or DNS (Domain Name System) terms that ended up published as bare TXT strings. They’re in the ranking because they match the <token>=<value> shape and cleared the threshold, and the extraction doesn’t guess at intent. If you want vendors only, filter those rows out of the CSV yourself; the page leaves them in so the count stays reproducible.

What a token proves, and what it leaves open

Finding a token tells you that somebody completed a verification step for that domain at some point, and the record stays in the zone until somebody deletes it, however long ago that step was.

What the record leaves open is which property got verified. It also can’t tell you whether the integration behind it still runs, or whether the person who added it still holds the account. Something a marketing tool published years ago, for an account the organisation has since left, reads the same as a string added last week, and a domain that changed hands can carry the previous owner’s receipts indefinitely.

With that caveat in place, each row counts domains where a verification step happened, and because of the threshold it’s a floor on that count. It’s also a ceiling on the number of live integrations behind that token, because a live integration needs the record and a dead one often keeps it. The census measures footprints in DNS, so each row counts domains where the string is present today, and it doesn’t reach any further than that into market share.

How many tokens one domain carries

Of the 46,336,520 domains carrying any token, 39,484,093 carry exactly one, 85.21% of token_present. Another 5,338,222 carry two, 11.52% of token_present. The remaining 1,514,205 carry three or more, 3.27% of token_present and 0.87% of txt_present.

The most distinct tokens observed on a single domain, in any TLD, is 125. A zone like that looks like years of onboarding that nobody ever cleaned up, and some of those 125 strings probably still map to accounts somebody could log into.

Counting your own is one command: dig +short TXT <your-domain> prints the apex strings, and anything shaped <token>=<value> that isn’t v=spf1 is a token. Run the free scan on the same domain and you’ll get the state of the records around those tokens, which is where the answers that change your grade live.

Services you’d expect to see and don’t

shopify-verification appears on 74 domains in 5 TLDs, 0.00% of txt_present and 0.00% of token_present. hubspot-developer-verification appears on 12,380 domains in 125 TLDs, 0.01% of txt_present and 0.03% of token_present. wix-verification is on 3 domains, in 1 TLD. None of them is anywhere near the published 80, and all three have plenty of customers.

When a service verifies ownership through a meta tag, an uploaded file or a CNAME (Canonical Name), there’s no apex TXT string to count, and a domain pointed wholesale at a hosted platform doesn’t need a separate proof-of-ownership record at all. When it puts its token under a label below the apex, it’s outside this extraction for the same reason DMARC records, which live at _dmarc, are excluded from the pool entirely. So a small row, or no row, mostly reflects how a service chose to verify, and you can’t read customer numbers off it.

At the other end, the tokens near the top belong to services that push a string into the apex of a lot of zones, and the count reflects that habit as much as the size of the user base behind it.

If you’re auditing a zone you didn’t build, treat the apex TXT set as a lower bound on the services that have touched the domain. Where a business visibly uses a platform that has no token in the zone, read the CNAME and A records before you conclude anything.

The stripe-verification row

stripe-verification is rank 35 in the full table, on 95,908 domains publishing the record at the apex: 0.05% of the 174,990,877 domains with any apex TXT record and 0.21% of the 46,336,520 carrying any token, seen in 384 TLDs. That counts published DNS records, which is a different thing from counting websites that take payments through Stripe.

The gap runs both ways. A domain can take payments with no token at all, because an integration that never asked for a DNS record leaves nothing here. And a token can outlive the integration that created it, because DNS records are rarely tidied when a feature is switched off, so some of the 95,908 are stale. From outside you can’t tell which are which. Read the row as a firm floor on published records, since the string is either in the zone or it isn’t, and never as the install base of a product. “95,908 websites use Stripe” turns a record into a product install and domains into websites, when a domain can front several sites or none, so it overstates on both counts.

Citing the table

Cite a row with its denominator in the same sentence, the way this page does: the domain count, then “of the 174,990,877 domains with any apex TXT record” or “of the 46,336,520 domains carrying any token”. For the Stripe row that reads: “As of [as-of date], 95,908 domains published a stripe-verification TXT record at the apex, 0.05% of the 174,990,877 domains with at least one apex TXT record, according to the defaults.exposed census.” Those two pools are the only bases the shares were computed against, so keep the citation inside them. The percentages in the twins already use those bases, so copy them across as printed.

Cite the edition as well. The twins carry the same as-of date as the footnote below, and the values on this page are replaced when the next census runs, so a citation without a date will drift out from under whoever reads it. Load the CSV, drop the fragment rows if you only want vendors, and keep the denominators attached to whatever you publish.

The full ranked table, all 80 rows with the same columns: download the CSV or the JSON.

Figures from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.