TXT Verification Records: Prove Domain Ownership Without Breaking Anything

A TXT verification record is a short, unique string a service asks you to add to your domain's DNS so it can confirm you actually control that domain. Google, Microsoft 365, AWS, Facebook, Atlassian, and hundreds of others use the same pattern: they generate a token, you publish it as a TXT record, and their system queries DNS to see it. Once verified, the service unlocks the domain for your account. This guide explains exactly where to place the record, how several verification records coexist on one name, the mistakes that cause verification to fail, and how to decide whether to keep or remove the record afterward.

How verification works

The logic is simple and relies on a basic assumption: only the person who controls a domain can change its DNS. The service hands you a token like google-site-verification=rXsP...9f2 or MS=ms12345678, you add it as a TXT record, and the service performs a DNS lookup. If the token is present, ownership is proven. No file upload, no login to your registrar on their part, just a public DNS query anyone could run with dig.

Where to put the record

Most services want the verification TXT record on the domain apex (the root, written as @ in a zone file, which represents example.com itself). Some services ask for it on a specific subdomain, and some offer a CNAME alternative instead of a TXT record. Always follow the exact host the service shows you. The table below lists common examples.

Multiple verification records coexist

You do not need to delete one verification record to add another. DNS allows many TXT records on the same name, and each service only looks for its own prefix (google-site-verification=, MS=, and so on). It ignores everything else. So the apex of an active domain commonly holds a stack of TXT records at once:

example.com.  IN TXT "v=spf1 include:_spf.google.com ~all"
example.com.  IN TXT "google-site-verification=rXsP3k...9f2"
example.com.  IN TXT "MS=ms12345678"
example.com.  IN TXT "facebook-domain-verification=abc...xyz"
example.com.  IN TXT "atlassian-domain-verification=9a8b...c7"

One important exception: you may have only one SPF record (one TXT value beginning v=spf1) per name. Verification tokens are not SPF, so they never conflict with it, but do not try to merge a verification token into your SPF string.

Verification records versus SPF and DKIM

This is a frequent source of confusion, because SPF, DKIM, and verification tokens are all TXT records. They are not the same thing and serve different jobs:

• Verification token: a one-time proof of ownership, read once (or occasionally re-checked) by one service. Harmless to leave in place; meaningless to anyone else.
• SPF: a mail-authentication record at the apex, starting with v=spf1, listing who may send mail for your domain. Only one allowed.
• DKIM: a public key published at a selector host like selector._domainkey.example.com, used to validate message signatures. Not on the apex.

Deleting an SPF or DKIM record to "clean up" after verification can quietly break your email. Know which record you are touching before you remove anything.

Common failure modes

1. Removing the record too soon. Many services re-check ownership periodically, not just once. If you delete the token after initial success, the domain can later revert to unverified and features can switch off. Keep it unless the service explicitly says it is safe to remove.
2. Wrong host. Adding the token to www or a random subdomain when the service wants the apex. Also watch for your DNS panel appending the domain automatically: typing example.com in the host field can create example.com.example.com.
3. Quoting problems. A long token should be a single quoted string. Some panels add quotes for you and some do not; double quoting or a stray space inside the value makes it fail to match.
4. Propagation delay. The record is correct but you checked too soon. New TXT records need time to publish across resolvers, bounded by the zone's negative-cache TTL for the name. Wait, then re-check.
5. Editing the wrong record type. Pasting a verification token into an SPF or DKIM value instead of creating a new standalone TXT record.
6. Trailing or hidden characters. A newline or non-breaking space copied along with the token from a web console.

Verifying it resolves

Query the name directly and look for your exact token in the output. A clean apex lookup returns every TXT record on the name.

$ dig +short TXT example.com
"v=spf1 include:_spf.google.com ~all"
"google-site-verification=rXsP3k...9f2"
"MS=ms12345678"

# Service-specific host (Amazon SES example)
$ dig +short TXT _amazonses.example.com
"pmBGN3Kd...k="

# Check from a specific public resolver to rule out local caching
$ dig +short TXT example.com @1.1.1.1

If dig shows the token but the service still reports failure, the issue is almost always timing (caches have not expired) or a host-name mismatch rather than the value itself.

Keep or remove: a short checklist

• Does the service say it re-verifies periodically? If yes, or if you are unsure, keep the record.
• Is the token still tied to an active product (Workspace mail, SES sending, an ad account)? Keep it.
• Have you fully offboarded from the service and confirmed removal is safe in their docs? Only then remove it.
• When removing, delete only the single TXT value that carries that service's prefix. Leave SPF, DKIM, DMARC, and other verification tokens untouched.
• After any change, re-query with dig from an external resolver to confirm the intended state.

A safe default

Because verification tokens are tiny, harmless, and sometimes re-checked, the safest default is to leave them in place. A short list of old tokens does no damage, while an aggressive cleanup can silently drop ownership of a mail or ad platform weeks later. Clean up only when you have decommissioned the service and confirmed it is safe.

Added a verification record and waiting for it to show up? Run the name through the Valla DNS propagation checker to see whether the TXT value has published across resolvers before you click verify, and browse our /learn/ guides on SPF, DKIM, and DMARC so you can tell your email records apart from your ownership tokens.