A CNAME takes over the whole name, which is why mail breaks

A CNAME says: this name is another name for that one, go and ask about that one instead. The important word is name, not address. It is an alias at the level of the whole label, and that single property explains every surprising thing a CNAME does.

The rule that follows from it, and that trips people up on their first client migration: if a name has a CNAME, it can have nothing else. No A record, no MX, no TXT, no SPF, nothing. This is not a limitation of your DNS panel. It is in the specification, because a resolver that found both an alias and a real record at the same name would have no way to decide which one you meant.

Why this kills mail, and how it kills it

The apex, the bare domain with no subdomain, is where a domain's MX and TXT records live. So a CNAME at the apex would displace them. Which is why classic DNS forbids it, and why every hosting provider that offers "just point your domain here with a CNAME" has had to invent something.

The something is flattening, sold as ALIAS, ANAME, or CNAME flattening depending on the provider. Your DNS provider resolves the target for you and serves the resulting addresses as though they were ordinary A records. The apex keeps its MX and TXT. It works, and it is the right answer most of the time.

What nobody mentions is what you traded away. The address served to your visitors is now resolved by your DNS provider, from wherever their resolvers are, and cached with their TTL. If the target uses geographic routing to send visitors to a nearby edge, that routing now happens from your provider's location rather than from your visitor's, which is precisely the case where it matters. If the target fails over by changing its DNS answers, your provider's cache sits between the failover and your users.

None of that is a reason to avoid flattening. It is a reason to know that you have inserted a dependency into the request path, and to check it during an incident rather than assuming the target's own failover is protecting you.

The failure to watch for is simpler and more common: somebody adds a CNAME at the apex on a provider that allows it literally, or migrates a zone and the apex ends up aliased. The website works perfectly. The MX records are gone. Mail stops arriving and nobody notices for a fortnight, which is the shape of every mail outage: the site is up and the mail is gone.

The verification record that cannot be added

A smaller version of the same rule, and it produces a support conversation that goes nowhere.

A service asks you to prove you own help.client.com by adding a TXT record at that name. But help.client.com is already a CNAME pointing at their platform. You add the TXT, the panel accepts it, and the verification never passes, because resolvers follow the alias and never see it.

Depending on the panel you may get a warning, a silent refusal, or a record that exists in the interface and is never served. All three are the same situation. The way out is either to verify at a different name, which most services support, or to replace the CNAME with the A records it resolves to, which trades convenience for control and means you now own keeping them current.

Dangling aliases, which are a security problem

This is the one worth acting on today, and agencies accumulate it faster than anyone.

Over the years a client's zone collects aliases pointing at services: a marketing platform, a help desk, a status page, a landing page builder, a form tool, a shop that ran for one campaign. Each was set up as a CNAME to something like client.someplatform.io. Then the subscription lapses, or the project ends, and the platform releases the name. Nobody removes the CNAME, because nobody remembers it exists.

The alias now points at a name that anybody can claim on that platform. Whoever claims it controls a hostname under your client's domain: cookies scoped to the parent domain, a plausible address for a phishing page, and whatever reputation the domain carries. This is subdomain takeover, and it needs no exploit at all. It is a signup form.

Finding them is an afternoon's work once, and then a line in your handover checklist.

for h in www help support status shop blog mail app portal docs; do
  t=$(dig +short CNAME "$h.example.com")
  [ -n "$t" ] && printf '%-10s -> %-45s %s\n' "$h" "$t" "$(dig +short A "$t" | tr '\n' ' ')"
done

An alias with an empty right-hand column is a CNAME to a name that does not resolve. Some of those are harmless typos. Some are an open door. Either way the fix is the same: delete the record. A subdomain that nobody uses does not need to exist.

Chains, and why they cost more than they look

A CNAME may point at another CNAME. Each link is a separate lookup, with its own round trip and its own TTL, and the shortest link in the chain governs how often the whole thing has to be re-resolved. Resolvers also cap how many hops they will follow, and the cap is not the same everywhere.

dig +trace www.example.com

That shows the chain hop by hop, ending at the record that actually carries an address. Two hops is common and fine. Four is worth questioning, and usually means two migrations were done by aliasing to the previous answer rather than by changing the target.

One practical note while you are in there: the TTL you are subject to is the one on the record that resolved last, not the one you set on the alias. Lowering the TTL on a CNAME before a migration and leaving the target at a day accomplishes nothing, for the same reason lowering a TTL during a change accomplishes nothing: propagation is not a thing, TTL is.

And if you are looking at all of this from a client's locked-down laptop with no dig available, the same questions can be asked with the tool that is there, provided you know which three ways its output misleads: five nslookup invocations.