Zoho, Meta, Atlassian, Canva, Klaviyo: the long tail of domain verification, counted
If you’re about to audit a DNS zone you didn’t build, the TXT records at the apex are the quickest inventory of which outside services someone once proved ownership to. This page lists the exact verification strings, in the form they sit in a zone file, with the number of domains carrying each one in the September 2026 census. Of the 167,692,006 domains with at least one apex TXT record (txt_present), 44,285,266 carry at least one verification-style token, 26.41% of txt_present. Four strings have a page of their own here, google-site-verification, ms, stripe-verification and openai-domain-verification, so they’re left out of the table below and the tail is what remains.
How the census counts a token
A verification token, for this count, is a TXT string shaped <token>=<value> or <token>:<value> that isn’t an SPF, DMARC or DKIM record and doesn’t begin v=. The census reads the apex of each scanned domain, so a record published at _dmarc or under a DKIM selector is out of scope. Those families are counted on their own pages, SPF and DMARC, and you’ll be reading them in the same zone anyway.
Two denominators run through the table. txt_present is the 167,692,006 domains with at least one apex TXT record. token_present is the 44,285,266 domains carrying at least one verification-style token, which is 26.41% of txt_present. A share of txt_present tells you how often you’ll meet a string in a zone that has any TXT record at all, and a share of token_present tells you what slice of the verified population that one string accounts for.
A token is counted only where at least three domains in the same TLD carry it, so smaller per-TLD tails are not in these sums. A string sitting on two domains in a small country-code TLD adds nothing to its total. The TLD column is the number of TLDs where the string cleared that floor, and it’s a fair proxy for how widely a service is used outside its home market.
The rows are alphabetical, ignoring a leading _, so you can find the string you’re holding. Nothing about a domain’s security follows from which vendor’s token it carries; the census doesn’t score these records, and the counts here are adoption and nothing more.
The long tail, string by string
| token | domains | share of txt_present | share of token_present | TLDs |
|---|---|---|---|---|
adobe-idp-site-verification | 75,223 | 0.04% | 0.17% | 224 |
apple-domain-verification | 556,091 | 0.33% | 1.26% | 579 |
atlassian-domain-verification | 210,679 | 0.13% | 0.48% | 440 |
brevo-code | 1,286,721 | 0.77% | 2.91% | 696 |
canva-domain-verify | 259,638 | 0.15% | 0.59% | 426 |
canva-site-verification | 28,516 | 0.02% | 0.06% | 189 |
docusign | 56,684 | 0.03% | 0.13% | 209 |
facebook-domain-verification | 1,155,312 | 0.69% | 2.61% | 661 |
_globalsign-domain-verification | 491,631 | 0.29% | 1.11% | 546 |
globalsign-domain-verification | 112,074 | 0.07% | 0.25% | 367 |
klaviyo-site-verification | 295,763 | 0.18% | 0.67% | 346 |
knowbe4-site-verification | 114,873 | 0.07% | 0.26% | 285 |
linkedin-site-verification | 54,757 | 0.03% | 0.12% | 263 |
mailerlite-domain-verification | 280,646 | 0.17% | 0.63% | 438 |
mailru-domain | 119,162 | 0.07% | 0.27% | 288 |
mailru-verification | 55,932 | 0.03% | 0.13% | 207 |
pinterest-site-verification | 190,066 | 0.11% | 0.43% | 409 |
protonmail-verification | 585,717 | 0.35% | 1.32% | 654 |
sendinblue-code | 142,132 | 0.08% | 0.32% | 403 |
yahoo-verification-key | 72,303 | 0.04% | 0.16% | 235 |
yandex-verification | 604,935 | 0.36% | 1.37% | 552 |
zoho-verification | 1,547,320 | 0.92% | 3.49% | 693 |
Each string is printed in the code form the census matched on, which is the form you’ll see in a zone export and the form you searched for. The value after the = or : is unique per domain and is deliberately not shown; the name is the part that identifies the vendor.
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 491,631 domains and as globalsign-domain-verification on 112,074. Canva appears as canva-domain-verify on 259,638 domains and as canva-site-verification on 28,516. Mail.ru appears as mailru-domain on 119,162 and as mailru-verification on 55,932. Brevo, which used to trade as Sendinblue, is on 1,286,721 domains as brevo-code and is still on 142,132 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. 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.
Platforms that leave no trace at volume
Some large services barely appear at the apex, so absence from the table tells you nothing about absence from the market. HubSpot’s hubspot-developer-verification is on 12,101 domains, 0.01% of txt_present, seen in 127 TLDs. Shopify’s shopify-verification is on 80 domains, in 6 TLDs. Wix’s wix-verification is on 3 domains, in 1 TLD.
These services have plenty of customers. Their footprint at the apex is small because ownership can be proved another way, with an HTML meta tag or a CNAME, and because a domain pointed wholesale at a hosted platform doesn’t need a separate proof-of-ownership record at all. If a zone you’re auditing has no TXT token for a platform the business visibly uses, read the CNAME and A records before you conclude anything.
The same logic runs the other way. An inventory built from TXT alone will miss the vendors that verify by other means, so treat any list you build from the apex as a lower bound on the services that have touched the domain.
What a published token proves
A token in the zone proves that someone completed a vendor’s ownership check at some point. Whether the service is still in use is a separate question, and the record won’t answer it, because almost nobody removes a verification string once the check has passed. For an audit, treat each token as a lead: a former marketing platform, a mail relay that was trialled and dropped, a certificate authority nobody remembers ordering from.
Most token-carrying domains carry one. Of the 44,285,266 domains in token_present, 37,793,144 (85.34%) carry a single distinct token, 5,076,619 (11.46%) carry two, and 1,415,503 (3.20%) carry three or more. The largest number of distinct tokens on one domain in the September 2026 census, in any TLD, is 125. A zone with four or five is unusual and worth a slower read, since each string is a service that at some point had a reason to be there.
Reading your own zone against the table
Pull the apex TXT set and compare it line by line with dig +short TXT yourdomain.tld. Anything beginning v=spf1 or v=DMARC1 belongs to the email families and stays out of this count. What’s left, in name=value or name:value form, is the verification set. Match each string against the table, remembering the two-string vendors. A string you can’t find here is one of the four with their own page, or one that didn’t reach three domains in your TLD, or a private format the census doesn’t recognise as a token. How the apex is read, and why a TXT record at the apex behaves differently from one on a subdomain, is covered on the DNS page.
The free scan reads the same apex the census read and puts the SPF and DMARC state beside it, which is the quickest way to separate an inherited zone’s vendor history from its current email posture. Run it on the domain you’re about to audit, then work down the TXT set with this table open.
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.