toolhq.io

All posts
7 min readby Jameel Haider

Why you cannot put a CNAME at your apex domain

You want example.com to point at a platform that only gives you a hostname, something like myapp.herokudns.com. The documentation says to add a CNAME. Your DNS provider rejects it, or accepts it and your email stops working a week later. This is one of the oldest sharp edges in DNS, and it is not a provider limitation. It is a rule in the specification.

The rule

A CNAME record means "this name is an alias for another name, go look there instead". RFC 1034 is explicit about the consequence: if a CNAME exists at a name, no other record type may exist at that same name.

The reason is resolution logic, not bureaucracy. A CNAME tells a resolver that the real answer lives elsewhere. If the name also had its own MX record, the resolver would have two contradictory instructions for the same question, and no rule to decide between them. Forbidding the combination removes the ambiguity.

Now look at what lives at your apex. Every zone must have an SOA record and at least one NS record, and both sit at the apex by definition. That is what makes a zone a zone. So the apex always has other records, which means it can never hold a CNAME.

Subdomains have no such problem. www.example.com carries no SOA and no NS of its own, so a CNAME there is perfectly legal. That is why the documentation you are reading works fine for www and falls apart for the bare domain.

What breaks when you force it

Some DNS providers will let you save a CNAME at the apex anyway. The zone becomes invalid, and the failures are indirect enough to be hard to trace back:

  • Mail stops. A resolver looking up MX for example.com finds a CNAME and follows it to the target, which has no MX record of its own. Your mail is now being delivered based on the target's configuration, or not at all.
  • The zone may fail to load. Strict authoritative servers reject a zone with a CNAME alongside SOA and NS, so the change silently does nothing or takes the zone offline.
  • Verification records disappear. SPF, DMARC and domain verification TXT records at the apex become unreachable, because the CNAME says to look elsewhere. Deliverability degrades over the following days rather than immediately.

The delay is what makes this expensive. The web change appears to work, and the mail failure surfaces later with no obvious connection to the DNS edit.

ALIAS, ANAME and CNAME flattening

Providers solved this by inventing a record that behaves like a CNAME at lookup time but answers like an A record on the wire. The name differs by vendor. Route 53 calls it an alias record, DNSimple and easyDNS call it ANAME, Cloudflare calls it CNAME flattening, and Netlify and Vercel expose it as part of their domain setup.

The mechanism is the same in each case. You store a hostname as the target. When a resolver asks for the A record of example.com, the authoritative server resolves the target itself, right then, and returns the resulting IP addresses as a normal A response. The querying resolver never sees a CNAME, so nothing is violated. The apex keeps its SOA, NS, MX and TXT records because no CNAME was ever published.

This is a server side feature, not a DNS record type. There is no ALIAS in any RFC. It only works if your authoritative provider implements it, which is the real reason the answer to "can I CNAME my apex" is "no, but your provider may offer something that acts like it".

What to check before relying on it

  • TTL behaves differently. The provider caches the resolved target on its own schedule and hands out its own TTL. If the target changes IPs frequently, ask how quickly the provider re-resolves. A platform that fails over by changing DNS may fail over slower than you expect.
  • Geographic and latency routing can flatten badly. If the target returns different answers by region, your provider resolves from wherever its servers are, not from where your visitor is. You may pin every user to one region without noticing.
  • The target must be stable. Flattening resolves a name to addresses. If the platform expects to control routing through DNS, giving it a static set of addresses undermines that.
  • It usually costs a query. Some providers bill alias lookups differently from static records. Worth checking at volume.

The alternative that always works

If your provider offers nothing like this, use the arrangement the web has used for twenty years: make www the canonical hostname and redirect the apex to it.

  1. Point www.example.com at the platform with a normal CNAME, which is legal and supported everywhere.
  2. Put an A record at the apex pointing at any host that can issue an HTTP redirect, including redirect services most registrars provide at no cost.
  3. Redirect https://example.com to https://www.example.com with a 301, so the canonical form is unambiguous for both browsers and search engines. Our note on 301 versus 302 redirects covers why the permanent status matters here.

This keeps the apex free to hold MX, SPF, DMARC and verification records, which is the outcome you actually need.

Verifying the setup

After any apex change, confirm the zone still answers correctly for every type you depend on, not just A. Look up A, MX, TXT and NS for the apex with the DNS Lookup tool. If a CNAME slipped in, the other types will come back empty or point somewhere unexpected, which is the signature of this problem.

Then confirm the change has reached resolvers other than your own with the DNS propagation checker, and check that mail routing survived with the MX lookup. If mail records are involved, running the email health check afterwards catches an SPF or DMARC record that became unreachable when the apex changed.

For the wider picture on how these record types relate, see A record versus CNAME and DNS records explained.