The verification-token census: every third-party token in the internet's DNS, ranked

A verification token is a TXT string at the apex of a domain, shaped <token>=<value> or <token>:<value>, that isn’t an SPF, DMARC, DKIM 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 September 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: 167,692,006 domains published at least one apex TXT record in the September 2026 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: 44,285,266 domains carried at least one verification-style token, which is 26.41% 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 1285 TLD 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 29,145,803 domains, 17.38% of the 167,692,006 that publish any apex TXT record and 65.81% of the 44,285,266 that carry any token, and it cleared the threshold in 855 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,218,984 domains, 4.90% of txt_present and 18.56% of token_present, across 822 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 smartsheet-site-validation is on 19,779 domains, 0.01% of txt_present and 0.04% of token_present, in 120 TLDs. The published table stops at row 80, and the twins carry those same 80 rows.

Some rows don’t name a vendor at all. Strings like include, ip4, mx, https and caa in the full table look like fragments of SPF records or DNS 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 44,285,266 domains carrying any token, 37,793,144 carry exactly one, 85.34% of token_present. Another 5,076,619 carry two, 11.46% of token_present. The remaining 1,415,503 carry three or more, 3.20% of token_present and 0.84% 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 80 domains in 6 TLDs, 0.00% of txt_present and 0.00% of token_present. hubspot-developer-verification appears on 12,101 domains in 127 TLDs, 0.01% of txt_present and 0.03% of token_present. Neither is anywhere near the published 80.

When a service verifies ownership through a meta tag or an uploaded file, there’s no apex TXT string to count, and 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.

The same logic runs the other way: 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.

Citing the table

Cite a row with its denominator in the same sentence, the way this page does: the domain count, then “of the 167,692,006 domains with any apex TXT record” or “of the 44,285,266 domains carrying any token”. 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.

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