A saved CNAME is not proof that a verifier can read it. Compare the required name, type and target with the DNS answer before changing settings.
You save the CNAME supplied by a service, return to its setup page, and still see a verification failure. The DNS dashboard shows the record. Why can the service not see what you saved? A configured CNAME and the answer returned to a DNS query are not always the same thing. Cloudflare documents cases where proxying or CNAME flattening prevents a verification service from receiving the CNAME it expects.
A record can also be saved in a zone that is not authoritative for the relevant subdomain. Start by comparing three things: what the service requires, what the DNS provider stores, and what the authoritative DNS answer returns. This checklist is for a domain you control or are authorized to manage. It is not a reason to change nameservers or disable protection across a live website.
An address answer is not the same as a CNAME answer A CNAME identifies one DNS name as an alias of another. RFC 1034 describes how an ordinary lookup can follow that alias to obtain the requested information. A query specifically asking for the CNAME type is different: it asks for the alias record rather than restarting the query at its target.
That difference matters when a third-party service requires a particular CNAME name and target as verification evidence. Successfully resolving an IP address, or loading a web page, does not by itself prove that the required CNAME record is being returned. In its flattening overview , Cloudflare explains that it follows the target to an IP address and returns the final IP instead of the CNAME record.
It specifically warns that flattening all CNAMEs may break verification that needs the CNAME itself. That is documented provider behavior, not a diagnosis of every failed domain check. Keep the Cloudflare settings separate Zone apex: Cloudflare flattens CNAME records at the apex by default on all plans. An instruction for a verification subdomain should not be silently moved to the apex.
Proxied record: proxied CNAME records are flattened by default and return Cloudflare anycast IPs. Cloudflare identifies proxying as a possible cause of CNAME verification failure. DNS-only record: this setting alone does not rule out flattening. Paid zones can flatten all CNAMEs or specific records, and Cloudflare lists both as possible verification problems.
Delegated subdomain: an NS record can make another DNS provider authoritative for that subdomain. A record saved in the parent provider's dashboard may not control the answer. These distinctions come from Cloudflare's current setup and troubleshooting guides. Other DNS providers can implement different controls.
The right question is which behavior applies to the exact verification name, not whether every CNAME in a zone should use one setting. A fictional example: same label, different evidence Suppose a service asks for a CNAME at verify.example.com pointing to proof.service.example . These are illustrative names only, not a live configuration, valid verification token or instruction to publish a record.