How many TXT verification records does one domain carry?

Most domains that carry a third-party verification record in DNS carry one. Of the domains in the September 2026 census with at least one verification-style token in their apex TXT set, 37,793,144 carry exactly one, which is 85.34% of token_present. A small band carries three or more, and if you’re looking at a zone file full of strings you can’t place, yours is probably in that band.

What is being counted

The census counts a TXT string as a verification-style token when it is shaped <token>=<value> or <token>:<value> and is not an SPF, DMARC, DKIM or v= record. That’s the sheet’s own definition, and it matters for your clean-up because it draws a line through your zone.

On one side sit the records that do a job on each message you send: the v=spf1 string, the v=DMARC1 record at _dmarc, and the DKIM public keys under _domainkey. Those aren’t in this count and they aren’t candidates for tidying. Remove one and you’ll find out which mailbox providers were relying on it by about lunchtime; the DMARC page explains what that record is doing for you while it sits there looking idle.

On the other side sit the strings a vendor asked you to paste in once so it could prove you own the domain: a website analytics tool, a marketing platform, a document-signing service, a single sign-on provider. They look like something-verification=8f3a... or something-site-verification: 4kq9.... The value is an opaque string the vendor generated. The token name, the part before the = or the :, is what tells you who asked for it, and it’s the part you’ll be searching on later.

The denominator before the distribution

Across the September 2026 census, 44,285,266 domains carry at least one such token, which is 26.41% of the domains with an apex TXT record set at all (basis txt_present). Those are the domains that have proved ownership to at least one outside service and left the receipt in DNS.

That figure is the pool for everything below. When this page says “of token_present”, it means of those 44,285,266 domains, and the shares are of that pool rather than of the registered internet. A domain with no TXT records at all isn’t in the denominator, and a domain whose only TXT record is SPF isn’t either.

One token is the normal case

Within that pool, 37,793,144 domains carry exactly one verification token (85.34% of token_present). For most domains, then, one service asked for one string and that was the end of it. If your zone has a single unfamiliar = string sitting next to your SPF record, you’re in the majority and the clean-up is a five-minute job.

One token tells you less than it seems, though. It means one moment when somebody with DNS access proved the domain to one vendor. It doesn’t tell you when that happened or whether the account still exists.

Three or more is the band to read

Of that pool, 1,415,503 domains carry three or more distinct tokens, which is 3.20% of token_present and 0.84% of txt_present. At three or more you’ve got a list to work through, and the rest of this page is about how.

Why three rather than two? With one token, the question is “which vendor” and the answer is in the name. With two, it’s commonly a website tool plus a mail platform, and both are still in use. Three or more is where the third one is the marketing tool from a campaign in a previous financial year, added by a contractor whose access ended with the invoice. Nobody remembers buying it because the person who bought it isn’t on the payroll any more.

Three tokens also tell you something about the tidy-up ahead. A zone with three tokens has been touched by at least three separate onboarding flows, each of which sent an “add this record to your DNS” email to whoever had the login at the time. The records stay behind after those flows finish; the mailboxes that received the instructions often don’t, which is why the zone is the better inventory of the two even though it’s the one you understand less.

What a token proves and what it doesn’t

A verification token in DNS proves that, at some point, someone with write access to the zone proved the domain to that vendor. It doesn’t prove the service is still in use, and it doesn’t say whose account it was. Most vendors check the record once during setup and don’t look at it again, so a token can outlive the subscription by years.

So the counts above list declarations, and a declaration is no evidence the integration is still live. When you read “three or more”, read it as “three or more services this domain has been proved to at some point”. Some of those are live and some are ghosts; DNS can’t tell the difference, and neither can the census.

None of this says anything about security either way. Verification tokens are opaque strings that grant nothing to anyone who reads them, and a domain carrying five of them is neither better nor worse off than a domain carrying one. The count tells you how much of your zone you can account for, and you fix that with a spreadsheet and an afternoon.

The counts are floors

The census counts a token only where at least three domains in the same top-level domain carry it. Where a token appears on one or two domains in a TLD, the census leaves it out of the sums, because at that size it can’t tell a real token from a typo or a private naming convention. The consequence is that the smaller per-TLD tails sit outside these figures, and your own zone may carry a token the census didn’t count.

So treat 44,285,266, 37,793,144 and 1,415,503 as floors. The real number of domains carrying verification strings is at least that high, and the same goes for the band carrying three or more. The shape holds, most domains with one token and a thin band with several, even if the last digit of each count would move under a looser rule.

There’s no TXT record limit you’ll hit

The second question people arrive with is whether there’s a cap on TXT records, because a zone with a dozen of them looks wrong. The protocol doesn’t set one. A name can hold as many TXT records as your DNS host will let you enter, and each record can hold several strings of up to 255 bytes, which is why long SPF and DKIM records appear split into quoted chunks when you list them.

The limit people have bumped into is a different one. SPF has a ceiling of ten DNS lookups during evaluation, and that ceiling belongs to the v=spf1 record on its own; the SPF page walks through it. Verification tokens don’t count towards it. They’re separate strings in the same record set, and a mail receiver evaluating SPF skips over anything that doesn’t start with v=spf1.

The other practical ceiling is response size. A very large TXT set makes the DNS answer bigger, and an answer that won’t fit in a single UDP packet falls back to TCP, which resolvers handle without complaint. You’d need a great many records before that shows up as anything you notice. The reason to trim a zone is accountability. If you can’t explain a record, nobody will notice when it changes either, and it’s better to learn that now than while you’re chasing a problem.

What to do with a token you can’t explain

Start with the name. The token name is the vendor’s own label, and searching for it finds the vendor’s setup guide in seconds. That guide tells you what the token verified and, in most cases, whether the vendor re-checks it after setup. Then search your organisation’s mail archive and card statements for the vendor’s name. One of those will turn up the person who set it up, or the month the last invoice stopped.

If you find the account and it’s live, leave the record where it is and write the owner’s name and the date next to it in whatever you use as a zone inventory, even if that’s a spreadsheet. If you find the account and it’s closed, remove the record; a token for a subscription that ended can’t be doing any work for you.

If you can’t find the account at all, don’t delete the record on the spot. Vendors that re-verify periodically will fail their next check, and the colleague who still uses the service will be the one who finds out. Take a copy of the full TXT set before you change anything, remove the one token, and put a note in your calendar to look for fallout in a fortnight. Nothing you remove from DNS is lost; you have the copy and can paste it back in under a minute.

Work token by token rather than in one sweep, because a sweep hides which removal broke what. And keep the records that carry v= out of the exercise entirely; those are the ones the DNS page walks through, and they have owners you can find.

Run the free scan on your domain first and you’ll get the apex TXT set read back to you as the scanner sees it, which is the list you’ll be working from.

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.