Domain Verification with TXT Records: How It Works and Why It Fails

Beginner⏱ 3 min readUpdated October 13, 2026

Google, Microsoft, Meta, Apple and dozens of other services ask you to "add this TXT record to verify your domain". It is the simplest proof of control there is: only someone who can edit the domain's DNS can publish a random string they were given. When it works, it takes two minutes. When it does not, the reason is almost always one of five.

How it works

The service gives you a random token. You publish it as a TXT record, the service looks the record up through public DNS, and if it finds the token, the domain is yours as far as it is concerned. Most services use the domain itself (@); a few use a dedicated name.

Service	Name	Value
Google (Search Console, Workspace)	`@`	`google-site-verification=…`
Microsoft 365	`@`	`MS=ms…`
Meta (Facebook, Instagram)	`@`	`facebook-domain-verification=…`
Apple (iCloud+ Custom Email Domain)	`@`	`apple-domain=…`
Atlassian	`@`	`atlassian-domain-verification=…`
Let's Encrypt (DNS-01)	`_acme-challenge`	`<token>`

Step by step

0 of 6 done

Copy the token exactly, without spaces before or after.
Add a TXT record where the domain's DNS is actually hosted — that is the provider named in its NS records, not always the registrar.
In the name field, enter @ (or leave it empty) for the domain itself. Most panels append the domain automatically, so typing example.com creates example.com.example.com.
Paste the value without quotes, unless the panel asks for them.
Save, then check the record with a TXT lookup before you press "Verify".
Keep the record afterwards if the service says so: Google and Microsoft check it again later.

Several TXT records at the same name are fine

A domain can have any number of TXT records at @, and each service finds its own by its prefix. Add every token as a separate record:

example.com.  3600 IN TXT "google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ"
example.com.  3600 IN TXT "MS=ms48213307"
example.com.  3600 IN TXT "facebook-domain-verification=w7k2p9d4x1q8z3m6n5b0c2v7"
example.com.  3600 IN TXT "v=spf1 include:_spf.google.com ~all"     ; SPF stays a separate record

Watch out: Never paste a verification token into your SPF record, and never create a second record that starts with v=spf1. SPF is the one TXT record that must be unique; mixing them breaks your email authentication.

Why verification says "record not found"

Wrong place. The record was added at the registrar, but the domain's nameservers point to Cloudflare or a hosting company. Check NS first — this is the most common cause.
Wrong name. The panel appended the domain, giving example.com.example.com, or the record went to www instead of the domain.
Too early. The service looked before the record existed and its resolver cached "no such record" — for up to the negative-caching time in the zone's SOA, often an hour. Wait and retry.
Mangled value. Double quotes (""token""), a missing character, or a space copied with the token.
Long values split badly. TXT strings over 255 characters are split into several quoted parts; some panels do it wrongly. Verification tokens rarely hit this, DKIM keys do.

# what the world sees — is the token there, exactly once, without extra quotes?
dig +short example.com TXT
# where does the domain's DNS really live? Edit the records there.
dig +short example.com NS

Clean up old tokens

Tokens for services you no longer use do no technical harm, but they tell anyone who looks which tools you use — attackers read them when planning phishing — and they make the TXT answer larger. Remove a token when you leave a service, and keep the ones services check again.

Tip: The PixDNS TXT lookup lists every TXT record on a domain and labels the known verification tokens, so it is easy to see which ones belong to services you still use.

Look up a domain's TXT records →Next: TXT records explained →

Frequently asked questions

Can I delete the verification record after verifying?

Only if the service says it is a one-time check. Google Search Console, Google Workspace and Microsoft 365 re-check it, and removing it can undo the verification.

Does a verification TXT record affect my website or email?

No. It is only read by the service that asked for it. The only TXT records that change mail handling are SPF, DKIM and DMARC.

How many TXT records can a domain have?

There is no fixed limit. Dozens work; very large TXT answers are slower and may need TCP, which is one more reason to remove unused tokens.

Is a CNAME verification any different?

Some services offer a CNAME instead of a TXT record. It proves the same thing, but a CNAME cannot sit at the apex or share its name with other records, which is why TXT is the default.

Try it on your domain

See the theory in practice — run a TXT Lookup for your own domain.

Updated October 13, 2026

Sources