Do I put the record at the root or on a subdomain?

For whole-domain verification the record name is the root — entered as `@`, or left blank, depending on your DNS host. The trap is that many registrars automatically append your domain to whatever you type in the name field, so typing `example.com` produces `example.com.example.com` and the check never finds the token. Use `@` or an empty name. A few services verify a specific hostname instead (for example a `_something` label they give you); in that case paste their name verbatim and don't add `@`.

Can I delete the TXT record once it's verified?

It depends on which system asked for it, and getting this wrong is the most common way people silently lose access. Google Search Console re-checks the token on a schedule and un-verifies you the moment it disappears — you'll get a 'we can no longer verify your site' email weeks later. Leave that one in place forever. A one-time domain setup token, like the record Google Workspace or Microsoft 365 uses to confirm you own a domain before provisioning mail, is only read once and can be removed after setup completes. When in doubt, leave it — a short TXT record costs nothing.

The record is published but verification still fails. Why?

Three usual reasons. You checked before the record propagated — a fresh record plus your zone's negative-caching TTL means a resolver can keep returning 'no such record' for minutes to hours after you save it. The name is wrong because the registrar appended your domain to it. Or the token got pasted inside your existing SPF record instead of as its own separate TXT record. Verification tokens are independent TXT records; several TXT records can share the same name, so add a new one rather than editing SPF.

Views: 4

TXT Record for Domain Ownership Verification

TXT record for domain ownership verification: where the token goes, root vs host, and the deletion trap that unverifies you. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

The most common way to lose Google Search Console access isn’t getting hacked. It’s cleaning up your DNS.

Someone finishes a migration, sees a cryptic google-site-verification=… string sitting in the zone file, decides it’s leftover junk, and deletes it. A few weeks later an email arrives: Search Console can no longer verify the site. The dashboard is gone, the sitemaps stopped submitting, and nobody connects the outage to the “cleanup” from a month ago. That single misunderstanding — that a verification token is a one-time thing you can throw away afterward — is worth getting straight before you touch anything.

What a verification TXT record actually is

When a service needs proof that you control a domain — Google Search Console, Google Workspace, Microsoft 365, Naver Webmaster Tools, and dozens of others — it hands you a random string and asks you to publish it as a DNS TXT record. The logic is simple and sound: only someone with access to the domain’s DNS can add a record to it, so a record containing the service’s secret string is proof of control. No file upload, no meta tag, no dependence on your web host being up.

The string looks different per service, and the prefix tells you who it’s for:

google-site-verification=rXhT8s...        (Google)
MS=ms12345678                             (Microsoft 365)
naver-site-verification=8a3f...           (Naver)

They’re all just TXT records. There is nothing magic about them.

Where the record goes

For verifying an entire domain, the record name is the root of the zone. Every DNS host has its own way of spelling “the root”: most want @, some want the field left blank, a few want the bare domain. What they all agree on is that you are naming the apex, not a subdomain.

Here’s where people lose an afternoon. A lot of registrar control panels silently append your domain to whatever you type in the name field. So if you type example.com into the name box, the record you actually created is example.com.example.com — a subdomain that doesn’t exist as far as the verifier is concerned. It’ll look correct in the panel and fail every check. The fix is to enter @ or leave the name empty and let the panel supply the domain.

Some verifications deliberately want a specific hostname rather than the root — they’ll give you a full label like _someprefix.example.com. When that happens, paste exactly what they give you and resist the urge to “helpfully” add @ or trim it.

The propagation wait is real, and it lies both ways

DNS doesn’t update the instant you click save. Your new record has to propagate, and — this is the part that trips people — resolvers may have already cached the absence of that name. That’s negative caching: a resolver that looked up your token a minute before you created it can keep answering “no such record” for as long as your zone’s negative-cache TTL says to, which is often an hour and sometimes longer.

So a verification that fails thirty seconds after you save the record tells you almost nothing. Wait, confirm the record is actually visible from an outside resolver, and only then retry. Checking too early and assuming the record is wrong sends people into an editing spiral where they “fix” a record that was correct all along.

You can have more than one

A domain can hold many TXT records at the same name, and normal setups do: an SPF record, a Google token, a Microsoft token, a domain-verification string for some SaaS tool — all living at the root together, and a resolver returns the whole set. That’s expected and fine.

The mistake is treating them as one field. Do not paste a verification token into your SPF record to “keep the TXT records tidy.” SPF has its own syntax (v=spf1 …) and a verifier scanning for its token won’t parse it out of an SPF string — meanwhile you risk breaking SPF. Add each token as its own separate TXT record.

One length note: verification tokens are short, usually well under the 255-character limit for a single DNS TXT string, so the chunk-splitting problem that plagues long DKIM keys almost never bites here. If your DNS host ever does complain about length on a TXT record, that’s a different issue — see the TXT record 255-character split guide.

Check it before you blame the verifier

DNS Lookup queries the exact record name for TXT and shows you what a public resolver actually returns — the fastest way to catch the example.com.example.com name mistake or a token that never propagated.
DNS Propagation checks the record across multiple resolvers at once, so you can tell “not propagated yet” apart from “genuinely wrong.”

The short version

Publish the token as a TXT record at the root (@ or blank), not at a subdomain — unless the service explicitly gives you a hostname.
Watch for the registrar appending your domain to the name field.
Wait for propagation and confirm the record resolves from outside before retrying verification.
Add it as its own TXT record; don’t fold it into SPF.
Leave a Search Console token in place permanently — it’s re-checked, and removing it un-verifies you. Only a one-time setup token is safe to delete afterward.