One verification string, many domains: the portfolio census

A verification token is a TXT (Text) string at the apex of a domain, shaped <token>=<value>, that a service asked the owner to publish to prove control. The verification-token census counted the tokens by name. This page reads the values. When the same google-site-verification string sits on thousands of domains, one Search Console account verified all of them, because Google issues the string to the account and the account publishes it on every domain it adds. Group every token by its exact value across the September 2026 census and the portfolios appear: how many domains sit under one login, how big the largest holdings are, and how many published records are placeholders that verify nothing.

The denominator and the unit

The pool is token_present: 44,285,266 domains carried at least one verification-style token in the September 2026 census, 26.41% of the 167,692,006 with any apex TXT record. That is the same population, counted the same way, as the token census, across 1,065 TLDs (Top-Level Domains) with at least one token. Split by IANA (Internet Assigned Numbers Authority) type, 28,820,250 of those domains (65.08%) sit under generic TLDs and 15,465,016 (34.92%) under country codes. Of the pool, 44,247,853 domains (99.92%) carry a token with something after the equals sign. Empty values are left out of everything below.

The unit is a domain-token pair: one domain carrying one value of one token. A domain with two different google-site-verification strings counts as two pairs, because two accounts verified it. Across every token there are 58,942,577 pairs and 54,430,137 distinct values. A pair is unique when its value appears on no other domain and shared when it appears on two or more. The number of domains sharing a value is the size of the portfolio.

Only some tokens mean one owner when shared. Five are issued per account and stay the same on every domain that account verifies: google-site-verification, facebook-domain-verification, apple-domain-verification, atlassian-domain-verification and openai-domain-verification. Those five form the account-scoped family and carry the portfolio reading. The Microsoft 365 marker MS= is issued per tenant and is reported on its own. Every other token is vendor-scoped, per order or per domain, and a shared value there says as much about the vendor’s template as about any owner, so those are reported by category.

How often a value is shared

How often a value turns up on more than one domain depends on the kind of token. 2.43% of account-scoped pairs share their value, against 10.44% of MS= pairs and 25.86% of everything else.

Figure 1. How often a verification value is shared, by token family and TLD type. Each bar stops at the shared share; the rest of the family is unique values.

The account-scoped tokens

The five account-scoped tokens account for 35,634,921 pairs and 34,975,374 distinct values.

97.57% of account-scoped pairs carry a value nobody else publishes: one account, one domain. The remaining 865,421 pairs (2.43%) share their value with at least one other domain, and the rate is almost identical on both sides of the TLD split, 2.45% under gTLDs and 2.39% under ccTLDs. Most of that sharing is small. 201,388 values are held by between two and ten domains, the size you’d expect from a business with a handful of brands or an agency with a short client list. 4,476 values reach between 11 and 1,000 domains. Only 10 values sit on more than 1,000 domains each, and together they hold 225,933 pairs.

Per token, the sharing rate is low and level for four of the five and very different for one.

Atlassian’s token is the outlier, and what it verifies fits that. An organisation verifies each domain its staff sign in with, and every one of those domains carries the organisation’s one string. Nearly half of all Atlassian pairs (47.45%) sit in a shared value, and the two largest reach 2,587 and 2,204 domains, across 122 and 100 TLDs. Google has 53,606 values that appear under at least one generic and at least one country-code TLD, each one account holding names under both kinds of ending.

Figure 2 sets the five beside MS= and seven common vendor tokens.

Figure 2. Share of each token’s pairs whose value sits on two or more domains: the five account-scoped tokens, MS= and seven vendor tokens.

The 25 most-reused account-scoped values

Values are never printed in full. Each row shows the first six characters and the length, or the length alone for short strings. The CSV and JSON twins of this page add an eight-character md5 stub, so an analyst can match a row without seeing the string. The operator column names the nameserver operator serving the largest share of the domains that carry the value, with that share. Large infrastructure operators are named, and smaller ones appear as “other DNS operator”. The token column uses short names: google for google-site-verification, facebook, apple, atlassian and openai for the other four.

Figure 3. The 25 most-reused account-scoped values. Grey rows are placeholders that verify nothing; row 1 runs off the scale.

The 25 rows hold 237,681 pairs, 0.67% of the account-scoped family.

The largest portfolio isn’t one. Row 1 is a 32-character placeholder that tells the reader to insert their own code, published unchanged on 203,363 domains in 188 TLDs, 89.97% of them on one registrar’s default nameservers. Rows 7 and 8 are the same mistake on a smaller scale: a 20-character dummy string on 1,342 domains and three dots on 1,122. The record verifies none of the 205,827 domains in those three rows with Google. Set them aside and the largest real holding is row 2, one account on 5,739 domains across 180 TLDs, followed by rows 3 and 4 at 4,512 and 2,825.

Portfolios come in stacks. Rows 11 to 16 are six different Google strings with the same footprint: 931 domains each, in 14 TLDs, 714 of them under .cfd and 99.36% on Cloudflare nameservers, with the same breakdown by TLD and by nameserver at every level the extract keeps. Two MS= strings carry that footprint too. Counts that match at every level point to one zone template with eight verification records in it, copied onto every name in one portfolio. Rows 9 and 10, a Google string and a Facebook string, are a near-identical pair of the same kind, and so are rows 21 and 22.

By nameserver operator, the leading operator is Cloudflare for eleven of the 25 rows and UltraDNS for one, a registrar’s default DNS for seven, a site builder for one and another operator for four; one row has no nameserver captured. Across all 58,942,577 pairs, Cloudflare’s nameservers serve 14,991,029 (25.43%) and GoDaddy’s 9,015,085 (15.29%), the two largest operators by pairs.

MS=, reported on its own

MS= is the string Microsoft 365 gives an admin to attach a custom domain to a tenant. It is issued per tenant, so a shared value is one tenant with several domains. The tenant can be a company, a school or a managed service provider, and the census can’t tell which, which is why MS= stays out of the account-scoped table.

Of 8,730,138 MS= pairs, 89.56% are unique. 911,374 pairs (10.44%) share their value, more than four times the account-scoped rate, and almost all of that is small: 409,037 values sit on between two and ten domains, 862,116 pairs (9.88%). Only 5 values pass 1,000 domains. The two largest sit on almost the same footprint, 2,581 and 2,580 domains across 265 and 264 TLDs, both on NS1’s nameservers. The census can’t tell whether two strings on one footprint belong to one tenant or two. Two of the ten most-shared values are placeholder strings: eight Xs on 2,362 domains, and the digits 1 to 8 in order on 1,654.

Everything else: vendor tokens, templates and parking

The remaining 14,577,518 pairs belong to tokens whose values aren’t account identifiers, or whose meaning the census can’t confirm. 3,770,441 of them (25.86%) share a value, and here the TLD split opens up: 21.16% under gTLDs against 32.83% under country codes.

Across all tokens together, 140 values sit on more than 1,000 domains each and hold 2,313,639 pairs, 3.93% of every pair in the pool; 1,325,044 of those pairs are under ccTLDs. The 25 most-reused values of any token hold 2,016,850 pairs (3.42%), and the top of that list is a long way from verification in the usual sense.

Figure 4. The ten most-reused values of any token, by what the string is.

The rest of the 25 are more of the same: parking account ids, registrar verification constants, mx=managed and caa=managed mostly under .it on one hosting provider’s nameservers, a debug string, and a URL fragment published as a bare TXT string.

Among the vendor tokens, sharing runs from under 2% to over 99%. dan-ownership-verification has 1,625 values spread over 400,221 pairs, 99.79% of them shared. knowbe4-site-verification is 83.76% shared over 116,402 pairs, adobe-idp-site-verification 50.79% over 76,618, brevo-code 35.07% over 1,333,319 and mscid 34.33% over 506,715. The likeliest reading is a vendor that issues one string per customer account, and customers who hold many domains. The census doesn’t see who the customers are.

Why a shared value matters

For the five account-scoped tokens, the number of domains sharing a value is the reach of one login. The Search Console account behind row 2 can read search data and request removals for 5,739 domains. The Meta business account behind row 10 controls link previews and conversion-event settings for 1,119. If either account is phished, everything in its row is exposed at once, which is why the distribution matters before the ranking. Against that, 97.57% of account-scoped pairs are one account for one domain, and the vast majority of shared values sit on fewer than eleven domains.

The placeholders are a different problem with a simpler fix. A domain publishing one of these strings under google-site-verification is verified with nothing, so any process that reads the record as evidence of Google verification is wrong on 205,827 domains. Where a registrar’s or host’s zone template ships one of these strings, fixing the template stops it reaching new zones, and the records already published can be removed in bulk.

Reading your own zone

dig +short TXT <your-domain> prints the apex strings. If you manage several domains, compare the values across them: the same google-site-verification string on two of your domains is one account, which is what you’d expect. A string you don’t recognise belongs to an account you don’t control, perhaps an agency’s or a previous owner’s, and is worth a conversation about who holds that login. The free scan reads the same records live and reports the state of the DNS, SPF and DMARC (Domain-based Message Authentication, Reporting and Conformance) records around them, which is where the checks that change a grade live.

Citing the table

Cite a pair count with its denominator in the same sentence: “of the 44,285,266 domains carrying any token”, “of the 35,634,921 account-scoped pairs”, or “of the 58,942,577 pairs over all tokens”. Cite a row by its rank, length and md5 stub, which the CSV and JSON twins carry, and never by the value. Keep the account-scoped and vendor-scoped tables apart, because only the first supports “one account, many domains”. Even there, a shared value proves one account and says nothing about the company behind it. The twins carry the same edition date as the footnote below, and the values change when the next census runs.

The three ranked tables as data, all 60 rows, with each value's length and md5 stub in place of the value (the JSON adds the reuse bands and per-token totals): download the CSV or the JSON.

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.