What is a google-site-verification TXT record, and how many domains publish one?

The google-site-verification= string in your zone is an ownership proof. Someone who could edit your DNS at the time pasted it in so that a Google property (Search Console, Workspace, Merchant Center or Ads, among others) could look up the apex TXT records, find the value it had issued, and confirm that the person claiming the domain controlled it. Once written, the record is inert. Nothing in your mail or web traffic depends on it, and no signing or encryption happens with it. Google reads it when someone verifies and re-reads it from time to time to keep that ownership valid.

What the line looks like and what it proves

In most zones it sits at the apex, next to SPF and whatever else has collected there over the years. Pulled back through a resolver it looks like this:

@   300   IN   TXT   "google-site-verification=rXOxyZounnZasL8NQoNlN3w3B4JoR9Kx2v7bK3lE6nI"

The part before the equals sign is fixed, and it’s the part the census matches on. The 43 characters after it are the token Google issued to one account for one property. If the value matches what a property expects, it proves control of the domain to that property. If it matches nothing you can see, all it tells you is that a verification once happened here.

The record proves one thing: that the person who requested the token could write to this zone on the day they added it. It says nothing about who runs the website now or which Google product was involved, and the account that did the verifying may not exist any more. If you’re comparing the string against a value you’ve been sent, compare it character for character, because two tokens from two accounts differ only in that 43-character tail.

There’s a CNAME variant of the same proof, and an HTML-file variant and a meta-tag variant that never touch DNS. The TXT form is the one that ends up in zones handed from one administrator to the next, which is why it’s the one you’re looking at.

How many domains carry one

In the September 2026 census, google-site-verification appears on 29,145,803 domains. That is 17.38% of the 167,692,006 domains where at least one apex TXT record was observed, and 65.81% of the 44,285,266 domains carrying any verification-style token at all. The string was seen in 855 TLDs.

Two definitions sit behind those numbers. A verification-style token is any apex TXT string shaped <token>=<value> or <token>:<value> that isn’t an SPF, DMARC or DKIM record and doesn’t start with v=. And a token is counted only where at least three domains in the same TLD carry it, so the smaller per-TLD tails sit outside the sums on this page. A domain counts once however many copies of the string it holds.

What the count cannot tell you

The count is of domains where a Google verification token was written and has not been removed since. Which property was verified is not in there, because Search Console, Workspace, Merchant Center, Ads and the rest all issue tokens with the same prefix. Who verified it is missing too: the token belongs to a Google account, and that account may be an agency, a contractor, a colleague who left three years ago, or the previous owner of the domain before it changed hands.

Nothing in the record says whether the verification is still in use. Google eventually revokes ownership when a token disappears, and a token that stays put keeps the ownership alive however old it is, so a record added in 2016 for a Search Console property nobody has opened since is counted exactly like one added last week. Domains that were verified by the HTML file or the meta tag are absent from the count entirely.

So 29,145,803 is the number of registered domains where at least one Google ownership proof was sitting in the zone on the edition date. Anyone quoting it as Search Console usage, or as a share of anything Google sells, has read a DNS census as a usage survey.

Deleting it without breaking anything

The safe order is to establish who owns the token before you touch the record, because removing it drops that owner’s access and nobody notices until they next need it.

Start by listing each copy in the zone. On any machine:

nslookup -type=TXT yourdomain.tld

or, where you have it, dig TXT yourdomain.tld +short. Note each google-site-verification= value you get back. Zones that have passed through several hands often carry two or three.

Next, open the Google property you can reach and look at its verification page. In Search Console, that’s Settings, then Ownership verification, which lists every verified owner and the method and token value each one used. In the Workspace admin console, Domains, then Manage domains, shows whether the domain is verified and by what. Match each value in your zone against what the property shows.

A token that matches an owner who should keep access stays. Where the owner has left, remove the person at the Google end first, after which the record can go or stay as you like. If the value matches nothing you can see, it belongs to an account you can’t reach, and deleting it is how you find out, later and at a bad moment, whose access it was. Leave it until someone claims it or you’ve confirmed no property depends on it.

If you do remove one and something breaks, put the identical value back. Verification is a lookup, and Google will find the token again on its next check. A lapsed verification takes away the access and leaves the property’s data where it was.

Leaving the record costs you nothing. It’s a few dozen bytes in a TXT answer, and it grants no permissions in your DNS. The token confirms an owner who already holds the Google side of the pair, and it can’t be used to add one.

The other strings you didn’t add

While you’re in the apex TXT set, read the rest of it, because the same handover that left you this string usually left you more. MS= followed by a short ID is a Microsoft 365 tenant marker with the same character as the Google one: proof of a verification, harmless after the fact. Strings ending in -verification= or -verify= from mail platforms, certificate authorities and SaaS tools are the same class. They accumulate without expiring, and each one is a small record of a vendor that was connected once.

The two apex TXT records that still do something are the ones that start with v=spf1 and the v=DMARC1 record under _dmarc. Those decide whether a stranger can send mail carrying your domain name and whether receivers will believe it, and a zone full of verification tokens with a soft SPF and no DMARC is a common shape. SPF tells the world which servers may send as you, and DMARC tells receivers what to do when a message fails that test. The DNS piece walks the whole set.

The free scan below reads your apex TXT set and separates the ownership proofs from the mail policy, so you can see which of the records that matter are missing or weak.

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.