How to Verify Domain Ownership with a TXT Record

Sooner or later almost every online service asks you to "verify your domain." Google Search Console, Microsoft 365, Facebook Business Manager, email-sending platforms, SSL issuers, and dozens of SaaS tools all want proof that you actually control a domain before they hand over access to its data or let you send mail in its name. By far the most common way they ask for that proof is a DNS TXT record: a short snippet of text you add to your zone that the service then reads back. This guide walks through exactly why TXT verification works, how to add the record correctly, real examples from the big providers, the mistakes that cause most failures, the CNAME alternative, and how to confirm and later remove the record. You can read back any record discussed here for a live domain with the DNS Lookup lookup tool.

The logic is simple: only the person who controls a domain's DNS can change its records. DNS for a domain is managed through the registrar or DNS host, behind a login that, in principle, only the rightful owner has. So if a service generates a unique, unguessable string and you manage to publish that exact string as a TXT record at your domain, you have demonstrated administrative control. Nobody else can add records to your zone, which is what makes the proof meaningful.

TXT records are chosen for this job because they are designed to hold arbitrary text and they do not affect how your site, mail, or anything else behaves. Adding a verification TXT record will not break your website or your email; it is inert metadata that only the verifying service cares about. That safety, combined with the fact that every DNS host supports TXT records, is why it has become the near-universal standard for proving domain ownership.

First, get the token. In the service's setup flow, choose the DNS or TXT verification method (some default to uploading an HTML file instead, but DNS verification is more durable). The service will display a value to copy, usually a long string with a recognizable prefix such as google-site-verification=, MS=, or facebook-domain-verification=.

Second, log in to wherever your DNS is hosted. This is your DNS host, which is often but not always your registrar. If you are unsure who that is, the WHOIS Lookup lookup will show the registrar and the authoritative name servers, which tells you where the records actually live.

Third, create a new record of type TXT. For a domain-wide verification you almost always want the host (also called Name or Hostname) set to the root of the domain, entered as @ or simply left blank, depending on the provider. Paste the token into the Value or Content field exactly as given. Leave the TTL at the default, or set it to a low value like 300 or 600 seconds if you expect to change it soon.

Fourth, save the record. Then wait for propagation: DNS changes are not instant because resolvers around the world cache answers until the previous TTL expires. New records usually appear within a few minutes, but allowing up to an hour (occasionally longer) avoids a false failure. Finally, return to the service and click Verify. If it cannot see the record yet, wait a little longer and try again rather than re-adding the record.

Google Search Console and Google Workspace use a TXT value that begins with google-site-verification= followed by a long random string. You add it as a TXT record at the root of the domain (@). The same google-site-verification token format is reused across Google products, so one record can satisfy several of them.

Microsoft 365 and Azure use a value that begins with MS= followed by a short identifier, for example MS=ms12345678. Like Google, it goes at the root host as a TXT record. Microsoft's admin center shows the exact value during the domain setup wizard.

Facebook and Meta Business use a TXT value beginning with facebook-domain-verification= followed by a random string, again placed at the root. Other common examples you will encounter include stripe-verification=, atlassian-domain-verification=, and the _acme-challenge TXT records that Let's Encrypt and other certificate authorities use for DNS-based certificate issuance. The pattern is always the same: a prefixed string published as TXT at a host the provider specifies.

The single most common error is the wrong host. If the service wants the record at the root and you enter www, or you type the full domain into a panel that automatically appends the domain (turning example.com into example.com.example.com), the record ends up on the wrong name and the service never finds it. Many providers auto-append your domain to whatever you type in the host field, so for a root record you usually enter @ or leave it blank rather than typing the domain itself.

The second classic mistake is quotes. Some control panels expect the raw value and add the surrounding quotation marks for you, while others want you to include them. If you paste "google-site-verification=abc" with literal quotes into a panel that also adds its own, you end up with doubled quotes inside the value and verification fails. Paste exactly what the service gives you, and check the saved record to see how the panel stored it.

Other frequent culprits: a stray trailing space or a copied newline inside the value; editing or deleting an existing important TXT record (such as your SPF record) instead of adding a new, separate one; and simply not waiting long enough, then assuming the configuration is broken when it is really just propagation delay. A high TTL on a previously cached negative response can also slow things down, which is why setting a low TTL beforehand helps.

A point of confusion worth its own note: the root of your domain can hold many TXT records at the same time, and that is completely normal. You might have your SPF record, a Google verification token, a Microsoft token, and a DMARC-adjacent value all coexisting. Adding a new verification TXT does not overwrite the others as long as you create a separate record rather than editing an existing one.

The one record type where this matters most is SPF, because a domain must have only a single SPF TXT record (one starting with v=spf1). Verification tokens are different strings entirely and never conflict with SPF, but if your panel makes you edit a combined TXT field, be careful not to merge a verification token into your SPF string. You can confirm your SPF stays valid and stands on its own with the SPF Check checker after making changes.

Some services offer CNAME verification instead of, or in addition to, TXT. Here the provider asks you to create a CNAME record at a unique subdomain they specify, for example a long random label like abc123._domainkey or a vendor-specific token host, pointing to one of their hostnames. When their system resolves that subdomain and sees it aliasing to the expected target, ownership is proven the same way a TXT token proves it. DKIM keys for email and many certificate validations use this CNAME style.

The trade-offs are minor. CNAME verification is often preferred when the provider wants to keep rotating the underlying value on their side, since you point at their hostname once and they manage what it resolves to. The catch is the standard CNAME rule: a CNAME must be the only record on its name, so use a dedicated subdomain for it and never place a CNAME on a host that already has other records. Whichever method you use, the verification step and the propagation wait are essentially identical.

Before you click Verify, confirm the record is actually live and correct. The fastest check is the DNS Lookup lookup tool: query your domain for TXT records and look for the exact token you added. On the command line, dig example.com TXT or nslookup -type=txt example.com does the same job. Make sure the value matches character for character, with no doubled quotes or stray whitespace.

If the tool shows the record but the service still cannot see it, the cause is almost always propagation: your DNS host has it, but the resolver the service uses is still serving a cached older answer. Compare what resolvers worldwide are returning with the DNS Propagation tool; once they agree, the verification will succeed.

After verification completes, you usually should not delete the record. Most services re-check the token periodically and will revoke verified status (and the access that came with it) if the record disappears. Keep the verification TXT in place for as long as you use the service. Only remove it when you are sure you no longer need the integration, and when you do, delete just that one record and leave your SPF, DMARC, and other TXT records untouched. A final DNS Lookup lookup afterward confirms you removed the right entry and nothing else.

Will a verification TXT record affect my website or email? No. TXT verification records are inert metadata read only by the verifying service. They do not change how your site loads or how mail is delivered, which is exactly why this method is safe and universal.

Where do I put the host or name field? For domain-wide verification, almost always the root, entered as @ or left blank. Watch for panels that auto-append your domain to whatever you type, which is the number-one cause of records landing on the wrong name.

Can I have more than one TXT record at the root? Yes. The root can hold many TXT records at once, so adding a verification token alongside SPF and other tokens is normal. Just add a new record instead of editing an existing one, and keep your single SPF record intact.

It is not verifying even though I added the record. Why? Either the value or host is slightly off, or DNS has not propagated yet. Confirm the exact value with the DNS Lookup tool, watch global rollout with the DNS Propagation tool, and only re-add the record if the lookup shows it is genuinely missing.