Confirm the authorized service account and domain scope, add the exact requested TXT value in the active zone without overwriting existing records, then verify public resolution and service ownership separately.
To verify a domain with a TXT record, confirm the receiving service account, identify the active DNS provider and publish the exact requested value at the exact requested name. Add it without replacing unrelated records. Then check the public response and complete verification in the same service account.
Verification can grant control or reporting access, so “a record was added” is not the whole result. This guide covers a deliberate TXT workflow, common naming mistakes and lifecycle cleanup. Official sources were checked on 13 October 2026; no account was verified and no DNS record was changed.
Confirm who will gain access and to what
Open the service through a known official address. Confirm the signed-in account, organization or workspace, requested domain and the purpose of verification. Do not publish a verification value forwarded by someone else without establishing that they are entitled to the resulting access.
Search Console’s permissions documentation distinguishes verified owners and other users. DNS verification can establish ownership for the corresponding service; it is more consequential than merely changing a visual website setting.
Confirm the intended scope. A whole-domain property can differ from a URL-prefix property or one subdomain. For a fictional publisher, verifying example.com for the owner’s account is a different decision from verifying an application subdomain for a contractor’s workspace. Record the legitimate owner and why the service needs the requested scope.
Find the active authoritative DNS provider
The registrar, web host and DNS operator may be different companies. A DNS editor at the registrar may still accept changes even when another provider’s nameservers are authoritative. A saved entry in that inactive zone will not establish that the public domain serves it.
Cloudflare’s nameserver explanation distinguishes authoritative DNS from other parts of domain management. Check the domain’s current delegation and the exact zone you are authorized to manage. Subdomains can also have separate delegated DNS.
Do not change nameservers simply to add one TXT record. That is a wider migration affecting the whole zone. If you cannot access the active DNS service, ask its authorized administrator to add the specific record while preserving the website, email and existing verification records.
Separate the name field from the value field
Obtain the record details from the intended service’s current verification screen. Keep the record type, owner/name, exact value and requested TTL together. Do not copy values from a tutorial or another account.
| Instruction | What to check | Typical mistake |
|---|---|---|
| TXT record type | The service explicitly requested TXT | Creating an A or CNAME record instead |
| Domain apex | Provider uses @, blank or a complete domain name | Assuming the same entry convention everywhere |
| Named verification label | The resulting full name is exactly the requested label under the domain | Appending the domain twice |
| Verification value | Exact string from the authorized service screen | Putting the hostname in the value or editing the token |
| TTL | Use the documented or appropriate provider default | Assuming a lower TTL clears previously cached responses |
For example, if instructions request _verify.example.com, check whether the dashboard expects _verify or the full name. The result must not become _verify.example.com.example.com. This is a naming illustration only; no real or invented verification token is supplied here.
Add the record without replacing existing TXT data
DNS TXT records contain text strings whose meaning depends on the application. Several unrelated TXT values can exist at the same owner name. A service-verification value is not a reason to overwrite the domain’s email policy or another active verification record.
The Cloudflare record-management guide provides one provider-specific add/edit workflow. Other dashboards may group same-name values into a record set. Determine whether a control adds a value or replaces the existing set before saving.
Preserve SPF, DKIM, DMARC and other service entries. The rule that TXT allows multiple values does not mean every application permits duplicate policies: SPF prohibits multiple selectable SPF records. Add a separate verification value as instructed; do not concatenate it into an SPF policy or create an extra SPF policy.
Handle quotes, long strings and CNAME conflicts correctly
Cloudflare’s TXT reference explains its quote handling. DNS tools may display quotes around strings, while a dashboard may add those automatically. Follow the provider’s input format rather than repeatedly adding literal quotation marks to the requested value.
A TXT record can contain several character strings; that is different from several independent TXT records. For a long value, follow the service and DNS provider’s supported representation. Do not split a verification token into unrelated records or add spaces because a lookup displayed separate quoted chunks.
DNS alias rules restrict ordinary CNAME records from sharing a name with other ordinary data. If the requested label is already a CNAME, do not delete a working website or mail integration to force TXT there. Check a supported alternative name or verification method with the service. Provider-specific alias/flattening features need their own documented handling.
Check the exact public record before retrying
- Confirm the saved full owner name, TXT type and exact intended value.
- Query that name on the domain’s authoritative DNS service.
- Compare a normal recursive-resolver response and note the observation time.
- Check whether the requested value appears among the returned TXT records.
- Distinguish an empty successful response from a failure or timeout.
- Return to the original service/account and use its verification action.
A screenshot of the DNS editor proves only what that interface displays. It does not show which zone the public domain uses or what the verifier can resolve. Inspect the precise name rather than querying only the apex when instructions requested a subdomain.
Do not publish passwords, API keys or private keys in TXT. Verification values are intentionally exposed in public DNS, but account sessions and management credentials remain private. Share a minimal status/name comparison with authorized support rather than a screenshot of an entire account or private console.
Distinguish a naming mistake from a cached old response
If the authoritative response does not contain the value, inspect the active zone, record name, save result and delegation. Waiting longer cannot repair a record entered under the wrong domain. If authority has the correct value but another resolver does not, examine caching and the service’s documented recheck behaviour.
DNS negative caching explains why an earlier not-found response can remain cached. A TTL change made now does not retroactively erase previously cached positive or negative answers.
Use our DNS propagation and cache guide for a focused investigation. Do not promise that every verifier updates within a fixed number of minutes, and do not delete/recreate the record repeatedly without an identified error.
Keep verification separate from connecting the service
Microsoft 365 domain setup separates proving ownership from adding the records needed to connect chosen services. A successful TXT check does not by itself move email, point the website to a new host or finish every account configuration step.
Review subsequent wizard actions separately. Automated domain connection may offer to change MX, address or other records. Confirm the intended migration and current dependencies before accepting those changes. A verified domain can still use its existing website and mail service when the setup supports that arrangement.
For a mail cutover, use our domain and email connection guide. For a failed certificate challenge, use the CA’s exact current instructions; a generic service-verification token is not interchangeable with an ACME challenge response.
Keep required records and remove obsolete access deliberately
Search Console’s verification guidance states that verification remains dependent on a valid token and can be checked again. Do not remove its record immediately after a successful screen on the assumption that every service needs verification only once.
Conversely, preserve no verification grant blindly forever. During handover, identify the departing person’s service access and verification methods, establish the remaining owner’s legitimate access and follow the service’s owner-removal instructions. Removing a user and removing their verification method can be separate tasks.
Before deleting a same-name TXT row, identify its service and owner. Several records can have similar prefixes, and an obsolete-looking value may still support active ownership. Keep a change record rather than clearing all verification data to make the DNS editor look tidy.
Record the verified result and remaining work
Keep the service/account owner, domain scope, record name/type, responsible DNS operator, verification date and current service status. Record whether the value must remain, and who will review it after a provider or personnel change. The operational inventory need not contain credentials or copied tokens.
Confirm the website and email still use their intended records and test any separately authorized connection step. Our account protection and recovery guide helps maintain the account that now has control.
A sound outcome is that the intended service account verifies the intended scope through the expected public record, existing services remain intact and ownership can be maintained or removed deliberately. It is not evidence that the service will index pages, deliver mail or issue a certificate automatically.
Sources and verification
Editorial review 2026-10-13. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- Google: Manage Search Console owners and permissionsChecked Verified-owner access is consequential and differs from ordinary user roles; owner-removal/verification-method lifecycle matters.
Limits: No access granted, property created or assertion that every service uses the same permissions model. - Cloudflare: NameserversChecked Authoritative DNS operator/delegation must be identified rather than assumed from registrar or web host.
Limits: No nameserver change or claim that adding one TXT requires DNS migration. - RFC 1035: DNS implementation and specificationChecked TXT consists of one or more character strings with application-dependent text, distinct from unrelated resource-record values.
Limits: No token copied or long value split into unrelated records; protocol text does not prescribe every dashboard’s input representation. - Cloudflare: Manage DNS recordsChecked Add/edit record workflows need the selected zone, owner/name, type and value; adding differs from replacing an existing entry.
Limits: Provider example only; no UI accessed or existing zone modified. - RFC 7208: SPFChecked Multiple unrelated TXT values are distinct from multiple selectable SPF policies, which are not permitted.
Limits: No replacement/concatenation of authentication policies or complete mail-authentication setup claimed. - Cloudflare: DNS record typesChecked TXT quote/string representation is provider-sensitive and can produce input errors if altered carelessly.
Limits: No universal quotation rule, proxy workaround or account-specific value supplied. - RFC 2181: Clarifications to DNSChecked Ordinary CNAME data has same-name coexistence restrictions, so a working alias should not be casually replaced to force TXT verification.
Limits: DNSSEC exceptions and provider alias/flattening behaviour are not generalized; supported alternative verification requires service-specific confirmation. - RFC 2308: DNS negative cachingChecked Previously absent records can remain negatively cached; current TTL changes do not erase already cached answers.
Limits: No universal propagation countdown, forced resolver flush or claim waiting repairs a wrong owner name. - Microsoft: Add a custom domain to Microsoft 365Checked Ownership verification is separate from subsequent service-connection DNS steps, which may change existing dependencies.
Limits: No MX-based fallback or automatic domain-connect operation performed/recommended as a harmless TXT substitute. - Google: Verify site ownershipChecked Exact service-supplied record/name, scope, public verification and continuing token validity need correct account and lifecycle handling.
Limits: No actual/invented verification token shown, fixed completion time, ranking/indexing promise or assumption every record can be removed after success.