Verify a Cloudflare CNAME proof at the authoritative provider, not only in the dashboard

Proxying, flattening, or a child delegation can hide the exact alias a third party expects.

Source facts

Cloudflare lists several causes of failed CNAME domain verification: a proxied record, all-record or per-record flattening, and an NS delegation making another provider authoritative. Its remedy includes keeping the proof DNS-only with flattening off and ensuring the record exists at the nameservers that actually serve the subdomain.

Source: Cloudflare — Cannot verify a domain with CNAME.

Applicability

This concerns third-party verification that requires seeing a CNAME answer.

DSE recommendation

DSE recommends copying the exact requested owner name and target into the change record before editing. Check delegation first, then proxy and flattening settings. Do not remove an NS record casually to make one proof visible; inventory the child services and coordinate any authority change. Preserve existing mail authentication records and verify that a new proof does not collide with another record at the same name. Keep the third party’s requested CNAME value beside the authoritative answer, without substituting an address lookup for the alias check. If the child-zone owner differs, assign the request there before changing proxy settings in the parent. Record provider verification as a separate completion step.

Verification

Query the proof’s authoritative nameservers for the CNAME itself and compare the returned target with the provider’s instructions. Repeat from a representative recursive resolver after cache expiry, then run the provider’s verification. Record the visible alias and authority path rather than treating a saved dashboard row as successful validation.

Official reference

Cloudflare — Cannot verify a domain with CNAME. Reviewed October 20, 2026.