Why can't I put a CNAME on my root domain?

Because DNS rules (RFC 1034/2181) say a CNAME cannot coexist with any other record on the same name, and the zone apex must always carry SOA and NS records. A CNAME at the apex would conflict with those, so authoritative DNS providers reject it.

What is the difference between ALIAS, ANAME and CNAME flattening?

They are different vendor names for the same idea: a record that behaves like a CNAME at the apex but is resolved on the provider's side into A/AAAA records, so what is actually served is valid apex A records. Route 53 calls it an alias, Cloudflare calls it CNAME flattening, DNSimple and others call it ANAME.

Is it better to use www or the apex?

Technically www is easier because it is a normal subdomain and takes a CNAME cleanly. Many teams put the app on www and 301-redirect the apex to it. If you need the bare domain to serve directly, use ALIAS/ANAME where available or apex A records to stable anycast IPs.

The CNAME-at-Apex Problem, and How to Solve It

You cannot put a CNAME on a root domain. Here is why, what breaks when you try, and the five real fixes: ALIAS/ANAME, apex A records, redirects, and more.

You try to point a bare domain at your SaaS, reach for the obvious record, and your DNS provider rejects it:

acme.com.  CNAME  proxy.yourapp.com.   # ❌ not allowed at the apex

This is the CNAME-at-apex problem. It is not a bug in your provider — it is DNS working as specified. Here is exactly why, and the five real ways out.

Why it is forbidden

The apex (or root, or zone apex) is the bare domain: acme.com, not www.acme.com. Two rules collide there:

The apex must always carry an SOA record and its NS records. That is what makes it a zone.
RFC 1034 (reinforced by RFC 2181) says a name with a CNAME can have no other records. A CNAME means “this name is just an alias — look everything up over there.”

A CNAME at the apex would therefore have to coexist with the mandatory SOA/NS records, which the spec forbids. So authoritative DNS refuses it. Subdomains like www have no such obligation, which is why www.acme.com CNAME …is fine.

The five ways to solve it

1. ALIAS / ANAME / CNAME flattening (best, if supported)

Several providers offer a special record that acts like a CNAME at the apex but is resolved on their side into real A/AAAA records before answering the query. The client only ever sees valid apex A records, so the spec is satisfied.

Route 53: Alias record
Cloudflare: CNAME flattening (automatic at the apex)
DNSimple, NS1, others: ANAME

You keep the indirection benefit — the provider follows the target and picks up IP changes. The catch: not every registrar supports it, so you cannot assume customers have it.

2. Apex A/AAAA records to anycast IPs

Universally supported. The customer sets:

acme.com.  A     203.0.113.10
acme.com.  AAAA  2001:db8::10

The downside is that you have now hard-coded your IPs into a zone you do not control. Only publish addresses that are stable anycast IPs you will keep indefinitely — renumbering later means chasing every customer to update DNS.

3. Redirect the apex to www

Put the app on www (a clean CNAME) and 301-redirect the apex to it. The apex only needs a minimal record pointing at something that issues the redirect. Simple and robust; some customers just dislike a visible www.

4. Provider-specific forwarding

Many registrars offer built-in “domain forwarding” that redirects the apex. Fine as a stopgap, but behavior (status codes, HTTPS on the redirect hop) varies by provider and you do not control it — verify it actually serves HTTPS correctly.

5. Move DNS to a provider that flattens

If the customer is willing, moving the zone to Cloudflare or Route 53 gets them apex flattening for free. Bigger ask, but it removes the problem permanently.

What we recommend

For customer-onboarding flows, offer www + CNAME as the happy path, ALIAS/ANAME where the provider supports it, and apex A records to anycast IPs as the universal fallback. Then verify — the record being set is not the same as it resolving everywhere. Check the chain with our free CNAME checkerand confirm global resolution with the DNS propagation checker.

On supported registrars, Domain Connect can set the correct apex record in one click. And the full picture of how custom domains fit together — issuance, SNI, routing — is in the complete guide. cnames.dev handles all of these apex cases for you per domain.

The CNAME-at-apex problem, and every way to solve it