Providers commonly ask you to add a TXT or CNAME record to demonstrate control of a domain. Verification records should come from the exact service account you intend to authorise. They do not automatically move the website or email unless the provider also instructs you to change routing records.
IN THIS ARTICLE
Check access and requirements
Sign in directly to the provider's authenticated account and confirm the requested domain. Identify the authoritative DNS operator and whether its record-name field expects a full name, a relative label or @ for the apex.
01 Add a provider's DNS verification record and remove it only when appropriate
- Copy the requested type, owner name and value exactly from the active setup screen. Use the current challenge for the intended account rather than an old email or another customer's token.
- Create the record at the authoritative DNS provider. Keep existing MX, SPF, DKIM and website records unless the service's separate migration plan requires changes.
- For CNAME verification, check for conflicts at the same name and ensure the public answer remains visible as the verifier expects. Proxying or flattening can change the answer a verifier sees.
- Query authoritative nameservers for that precise type and name. Correct duplicated domain suffixes, misplaced values or accidental spaces before repeatedly clicking Verify.
- Complete the provider's verification step. Record which account the record authorises and whether the provider requires it to remain for future checks.
02 Example: verify a provider ownership token at the exact name
When a provider gives you a DNS ownership challenge, copy its record name and value exactly. This illustration is a TXT record with a made-up token. Use the provider's real value and the authoritative DNS panel for your domain.
_verify.example.com. 300 IN TXT "provider-verification=REPLACE_WITH_ISSUED_TOKEN"
dig _verify.example.com TXT +noall +answerRead the result: The token must appear at the fully qualified name the provider checks. Some panels automatically append example.com, so typing the whole name into a relative Host field can accidentally create _verify.example.com.example.com. Compare the public answer with the original challenge before clicking Verify again.
Do not replace unrelated TXT records, including existing email authentication, to add a separate verification token. Keep the token while the service requires continuing verification. Ask the provider whether removal is supported after activation rather than assuming every challenge is temporary.
Confirm the expected result
Confirm the domain shows verified inside the correct provider account. Check that ordinary website and mail services still resolve to their intended destinations.
Resolve setup problems
If the authoritative answer is correct but the provider still sees an older value, consider its resolver cache and retry interval. If the record points to an unfamiliar account, pause onboarding and investigate who supplied it.
A common question
Can I delete every verification TXT record once initial setup succeeds?
No. Some providers require continued proof or use the record during later administration and recovery. Remove a record only after confirming its owner, purpose and retention requirement, especially when several services share the same domain.