What Is CNAME Flattening in Cloudflare?

Every other DNS provider makes you choose between a root domain and a hostname target. Cloudflare does not, and the mechanism behind that is worth understanding — because the same mechanism quietly removes records that some services need to read.

Why a root domain cannot hold a CNAME

The restriction is older than any CDN. RFC 1034 states that if a CNAME record is present at a node, no other data should be present, so that an alias and its canonical name can never disagree. Your zone apex — the domain itself, the record you write as @ — always carries other data, because that is where the SOA record and the nameserver records live. A literal CNAME there would be a standards violation, and resolvers are entitled to behave badly when they meet one.

That is a problem, because plenty of things you might want your bare domain to point at do not have a stable IP address: a load balancer, an object storage endpoint, a platform that reassigns addresses whenever it likes. Other providers invented non-standard record types for this — ALIAS and ANAME. Cloudflare has neither. Its documentation tells you to recreate ALIAS or ANAME records as ordinary CNAME records, and lets flattening do the work.

What Cloudflare puts on the wire

When a query arrives for a name whose CNAME is flattened, Cloudflare follows the target itself — one lookup, or several if the target is another CNAME — and returns the final IP address under your own name. The CNAME never leaves the network. Two details of that answer are documented in Cloudflare’s flattening example and catch people out:

• If the record is proxied, the answer is made of Cloudflare anycast IPs with a TTL of 300 — the target’s address is never disclosed, and the TTL of a proxied record cannot be edited.
• If the record is DNS only, the answer is the target’s own IP address, and its TTL is the lowerof the target’s TTL and your CNAME’s TTL. Setting a long TTL on your record does not raise it; the target’s cache lifetime caps yours.

Because what leaves Cloudflare is an address record rather than an alias, the apex can still carry the MX and TXT records your mail and verification depend on. The conflict RFC 1034 forbids never appears on the wire, which is exactly the point. The same trick is what allows a bare domain to be used as a root custom domain on Cloudflare Pages.

When flattening happens, and when you choose

Three of the five cases below are not settings at all — they happen whether you want them or not. Only the last two are yours to configure, and both are limited to paid zones.

The zone-wide switch lives on the DNS Settings page and maps to flatten_all_cnames on the zone DNS settings endpoint. The per-record option appears as a Flatten toggle when you edit a record, and it is hidden in the cases where it would mean nothing: at the apex, on a proxied record, or when the zone-wide switch is already on. Records flattened individually are marked with a cf-flatten-cname tag so the setting survives a zone-file export and import.

Three ways flattening bites

Turning it on for every CNAME in a zone sounds tidy — faster resolution, one less thing to think about. It is the setting most likely to cause an outage you cannot see in the dashboard, because your records still look exactly right there.

1. Services that need to read the CNAME itself.DKIM keys, autodiscover endpoints and domain-verification records are frequently published as CNAMEs pointing into a provider’s zone. Flatten them and the provider gets an address record instead, so the check fails even though the underlying value is correct. Cloudflare’s own guidance is to turn flattening off when a provider requires the CNAME.
2. Targets with nothing to flatten to. If the final target has no A or AAAA record, there is no address to return, and Cloudflare answers with NODATA — an empty answer, not an error. It looks precisely like a record that never propagated, which sends people hunting in the wrong place for hours.
3. Targets in someone else’s Cloudflare account. Flattening does not get you around this: a CNAME pointing at a hostname in a different Cloudflare account returns Error 1014: CNAME Cross-User Banned. Within one account, or across zones you own, it is fine; otherwise the target’s owner has to onboard you through Cloudflare for SaaS.

Checking what your zone actually returns

Ask the nameservers rather than the dashboard. At an apex that is working normally:

dig +noall +answer example.com A
dig +noall +answer example.com CNAME

The first command returns an address record even though you configured a CNAME — that is flattening working. The second returns nothing at all, which is not a bug and not a missing record: at a flattened name there is no CNAME to hand out. A TTL of 300in the first answer tells you the record is proxied; anything else means it is DNS only and you are looking at the target’s address.

If you are auditing a whole zone, read the records back from the API instead of clicking through them. Each CNAME record carries its own settings.flatten_cname value, and the zone-level flatten_all_cnames flag sits on the DNS settings endpoint — worth checking before you blame a provider for a verification failure.

A reasonable default

At the apex you have no decision to make. For everything else, the ordering that causes the fewest surprises is: leave the zone-wide switch off, flatten individual DNS-only records when you have a specific reason to — a slow multi-hop chain, a target that resolves through two or three intermediaries — and never flatten a record a third party is going to read. If a provider ever tells you your DNS record is missing while the dashboard shows it plainly, flattening is the first thing to check.

FAQ