Custom domain verification fails? Check the DNS record name first

Your website works at its platform address, but your custom domain stays unverified. Before adding another record, compare the exact hostname your host expects with the name public DNS actually returns. A custom domain is optional; you can keep sharing the working platform URL while diagnosing it.

Start with the record type, name and value shown by your hosting platform. Verification tokens belong to that specific site or account. A generic example cannot supply them.

1. Find the DNS provider that serves the domain

These commands read public DNS; they do not change your account. Replace the example domain and verification label with your own:

dig NS example.com
dig TXT _verify.example.com
dig CNAME www.example.com

Check which provider operates the authoritative nameservers, then edit its DNS zone. If the domain uses Cloudflare nameservers, adding records to a separate registrar DNS zone will not update the active zone. Check for a separately delegated subdomain if you are connecting one.

Read the response status and authority section, rather than relying only on an empty answer. A timeout or SERVFAIL does not establish that your record is missing. NOERROR alone does not prove the requested record exists either; distinguish a no-data response from a referral. RFC 2308 explains those differences.

2. Check whether the panel appended the domain twice

Namecheap documents that its DNS editor appends the domain to the Host field. A host asking for _verify.example.com may therefore require just _verify in that field.

Query both names to spot the mistake:

dig TXT _verify.example.com
dig TXT _verify.example.com.example.com

If the token appears only under the doubled name, correct the owner name in the active zone. Keep the token value supplied by the host. Apply this conversion according to your DNS provider's instructions; different editors handle full names differently.

3. Separate verification records from web traffic

Cloudflare permits proxying A, AAAA and CNAME records. TXT records are always DNS-only. There is no orange-cloud setting to fix on a TXT record.

A CNAME used to prove ownership should be DNS-only so the verifier can observe the required target. For records serving the website itself, follow the hosting platform's Cloudflare instructions. Do not turn off proxying across the whole zone as a general troubleshooting step.

4. Treat the root and www as separate names

A working www.example.com does not establish that example.com is configured. Compare the exact hostname entered in your host's domain settings.

Use the root records supplied by that host. Namecheap warns against a conventional CNAME at the root because it can conflict with other records, including mail. ALIAS or CNAME flattening depends on the DNS provider. Preserve unrelated MX and verification records.

5. Verify the website after DNS

Compare recursive resolvers if you recently changed a record:

dig @1.1.1.1 TXT _verify.example.com
dig @8.8.8.8 TXT _verify.example.com

Different answers can reflect caching or another resolution problem. Check the authoritative response before adding duplicates.

Correct DNS is one checkpoint. Confirm that your hosting platform has attached the hostname and issued its certificate, then open HTTPS and test the site's main action.

For ChatGPT Sites, the Add Domain connection helper formats host-supplied values and checks public DNS without writing records. For agents building and launching a site, the complete website workflow includes the wider launch checks.

Prepared by Add Domain with AI assistance; technical details reviewed against the official sources linked above.