A service asks you to add a TXT record with a specific value, then checks for it. Because only somebody with access to the DNS could add it, finding it proves control of the domain.
The mechanism is simple. What causes trouble is what happens to those records afterwards.
Adding one
example.com. 3600 IN TXT "google-site-verification=abc123..."
Some services want the record at the domain itself; others at a specific name such as _something.example.com. Follow their instruction exactly. A record at the wrong name is not found, and the service reports only that verification failed.
Then confirm it is visible before clicking verify:
dig example.com TXT +short dig _something.example.com TXT +short
Verification failing because the record has not propagated yet is the most common reason people re-add it, ending up with two. For why waiting is the fix, see understanding TTL.
Which can be removed
Three categories, and the distinction matters.
Checked once. The service verified, recorded the result, and never looks again. The record is disposable.
Re-checked periodically. The service confirms ownership from time to time. Removing the record silently disconnects it, frequently weeks later, with no obvious connection to the change.
Not verification at all. SPF, DKIM and DMARC are TXT records and are ongoing configuration. Removing them breaks mail delivery rather than a service connection. Understanding SPF, DKIM and DMARC sets out what each does.
Since the first two are indistinguishable by looking at them, the safe assumption for any record whose service you still use is to leave it.
Write down what each one is for
At the moment of adding it: what service, who asked, and the date.
A zone containing a dozen unexplained strings is one nobody will ever be willing to tidy, because any of them might matter. Five minutes of notes prevents that permanently.
Keep it with the rest of the domain's record. For that, see managing a portfolio of domains.
Removing safely
When you genuinely need to clear one out and cannot tell which kind it is:
Identify which service it belongs to, from the prefix; most name themselves. If you no longer use that service, remove it. If you do, log in and check whether it still shows the domain as verified before touching anything.
Removing and watching for a failure is not a good test, because the failure appears weeks later and nobody connects it to the change.
SPF must remain a single record
The one hard rule in this area.
A domain may have many TXT records and only one SPF record. Two is an error, and the usual outcome is that neither is honoured, which is worse than having none, because mail that would have passed now fails.
This happens when a second service's setup instructions say to add an SPF record and somebody adds one rather than merging:
"v=spf1 include:_spf.provider-a.com include:_spf.provider-b.com -all"
One record, both services included. Splitting DNS between website and email providers goes into the common case where two senders both need authorising.
Verification is not authorisation
Worth stating because it causes real confusion.
A verification record proves you control the domain. It does not authorise that service to send mail as you, and it does not connect anything by itself.
So a service that is verified and still not working needs its actual configuration checked; the MX record, the SPF entry, the signing records: instead of the verification record re-added.
Checking what a domain currently publishes
dig example.com TXT +short dig _dmarc.example.com TXT +short dig default._domainkey.example.com TXT +short
Worth running on any domain you have inherited, because the answer usually includes services nobody mentioned. Inheriting a website nobody documented goes into the rest of that inventory.
Check the record is visible where the service looks
Verification fails most often because the record is correct and not yet visible, and the two look identical from the control panel.
dig example.com TXT +short dig example.com TXT @8.8.8.8 +short dig example.com TXT @1.1.1.1 +short
Query a public resolver rather than your own, since the service checking your domain is not on your network. A record your provider returns and a public resolver does not has not propagated.
Waiting is the correct action there. Re-entering the record or requesting a new value while the first is still propagating produces two strings and a check that fails against both.
Verification records accumulate and nobody removes them
Each service adds its own and none of them is ever cleaned up, so a mature domain publishes a list of everything it has ever been connected to.
dig example.com TXT +short | wc -l dig example.com TXT +short | cut -c1-60
That list is public. It names which analytics, mail, cloud and administrative services the organisation uses, which is more information than most people intend to publish.
Review it annually and remove the entries for services no longer in use. Keep a note of what each remaining one is for, since a record with no explanation will never be removed by anybody. Using the zone editor covers editing them safely.
Keep the record only as long as it is needed
Some services check the record once and never again; others check continuously and break if it disappears.
Removing a record that is still being checked silently disconnects the service, and reconnecting means going through the verification again. Removing one that was only checked at setup is safe and tidies the zone.
dig example.com TXT +short | grep -iE 'verification|site-verification|domain-verify'
The distinction is not visible from the record, which is why writing down what each one is for at the moment it is added is the only reliable approach. A comment in your own notes costs seconds and prevents an outage caused by tidying.
Long values have to be split correctly
A single text string has a maximum length, and values above it must be broken into several quoted parts that the resolver joins back together.
dig example.com TXT +short | awk '{ print length($0), substr($0,1,40) }' | sort -rn | head -3
dig default._domainkey.example.com TXT +short | head -c 120
Mail signing keys are the usual case, since they routinely exceed the limit. A panel that accepts a long value without splitting it produces a record that either fails to save or is returned in a form the checking service rejects.
Read the record back after adding it rather than trusting the interface. The value that resolvers return is the only one that matters, and it is the one the verifying service will read.