Why You Can't CNAME Your Root Domain (and What to Do)

The One Record You Can't Put at the Root

You want example.com to point at your CDN, which gives you a hostname like d3k7x.cloudfront.net rather than an IP address. The obvious solution is a CNAME.

Your DNS provider rejects it. Or accepts it and breaks your email. Or offers something called ALIAS or ANAME that isn't in any RFC you can find.

This is one of DNS's oldest structural limitations, and it's worth understanding properly because the workarounds all have different tradeoffs.

Why CNAMEs Are Exclusive

The rule comes from RFC 1034 and is unambiguous: if a name has a CNAME record, it can have no other records of any type.

The reason is how resolution works. A CNAME means "this name is an alias for that name — go look there instead." It's a redirection at the name level, not the record level.

If www.example.com has a CNAME to target.example.net, then every query for www.example.com — A, AAAA, MX, TXT, anything — gets redirected to target.example.net. The alias covers the whole name.

So a name can't have both a CNAME and an MX record, because the CNAME already claims all queries for that name. There's no coherent way to say "redirect queries for this name, except MX queries."

Why This Hits the Root Especially Hard

The apex of a zone — example.com with no subdomain label — is required to have certain records:

• SOA (start of authority): mandatory, defines the zone
• NS (name server): mandatory, delegates the zone

Both live at the apex. Both are required for the zone to function at all. And since a CNAME excludes all other records at the same name, a CNAME at the apex is structurally impossible.

Not discouraged. Not a bad practice. Impossible within the protocol.

Subdomains don't have this problem. www.example.com has no mandatory SOA or NS, so it can be a CNAME freely — provided it has nothing else.

What Actually Breaks

The failure mode when someone forces a CNAME at the apex is instructive:

Email disappears. Your MX records at the apex become unreachable, because the CNAME redirects MX queries elsewhere. Mail to @example.com goes to whatever the CNAME target's MX says, which is usually nothing.

Domain verification fails. TXT records at the apex — SPF, DMARC, Google or Microsoft verification tokens — stop resolving.

Behaviour varies by resolver. Some resolvers follow the CNAME strictly. Some return SERVFAIL. Some ignore it. Inconsistent breakage across the internet is worse than uniform breakage, because it's harder to diagnose.

If your DNS provider allows an apex CNAME without warning, that's a provider problem, not a signal that it's safe.

The Workarounds

ALIAS / ANAME / CNAME flattening

Several DNS providers offer a proprietary record type, variously called ALIAS, ANAME, or "CNAME flattening" depending on the vendor.

Mechanically: the authoritative nameserver resolves the target hostname itself, then returns the resulting A or AAAA records in response to queries for the apex. From the resolver's perspective it's an ordinary A record — no CNAME is ever sent over the wire, so no exclusivity rule is violated.

This lets you keep MX, TXT and NS records at the apex alongside the alias behaviour.

Tradeoffs worth knowing:

• It's not standardised. Implementations differ between providers, and behaviour isn't guaranteed to be identical.
• Geographic resolution can degrade. If the target uses geo-based DNS to return a nearby edge server, the answer depends on where your DNS provider's resolver is, not where your visitor is. Some providers handle this well by forwarding client subnet information; some don't.
• Caching adds a layer. Your provider caches the resolved addresses, so changes at the target propagate with an extra delay.
• It ties you to that provider. Migrating DNS means finding equivalent functionality elsewhere.

Redirect the apex to www

The traditional approach: put an A record at the apex pointing to a small redirect service or your own server, and have it issue a 301 to https://www.example.com.

Simple, standard, fully compatible. Costs one extra round trip on the first request. Many CDNs and registrars offer this as a managed feature.

Use www as the canonical hostname

Set www.example.com as your primary hostname with a CNAME to the CDN, and redirect the apex to it. This is a perfectly reasonable architecture — the aesthetic preference for a bare domain is the main argument against it, and there are real technical arguments in favour of www (cookie scoping, easier CDN configuration).

A records with the target's IPs

Look up the CDN's IP addresses and publish them as A records at the apex. Works, standard, and fragile — the whole point of a CNAME to a CDN is that the CDN can change its addresses. Only viable when the provider guarantees static anycast IPs, which some do specifically for this purpose.

Inspecting the Records

The DNS Lookup tool lets you see exactly what's published:

1. Enter the domain name.
2. Select the record type you want to query.
3. Read the returned records.

Useful checks when diagnosing apex problems:

• Query the apex for MX and TXT. If those come back empty on a domain that should have them, an apex CNAME or misconfiguration is the likely cause.
• Query the apex for A. If a provider is using ALIAS flattening, you'll see A records here even though the control panel shows an alias — that's the expected behaviour and confirms it's working.
• Query for CNAME at the apex. A response here on a domain that also needs MX is a red flag.
• Compare a subdomain to the apex. If www resolves and the bare domain doesn't, you've localised the problem immediately.

Checking from a public resolver rather than your local network also rules out internal DNS overrides, which are a common source of "it works for me" confusion.

The Chain Rule

Related and worth knowing: a CNAME target should not itself be a CNAME, at least not in a long chain.

Chains work — resolvers follow them — but every hop is another lookup, adding latency. Resolvers also impose limits on chain length to prevent loops, typically somewhere around 8 to 16 hops depending on implementation.

A CNAME loop (A points to B, B points back to A) is detected and returns an error, but it's an easy configuration mistake when two teams manage different parts of a zone.

Keep chains short. If your CNAME points at a vendor hostname that itself CNAMEs twice more before reaching an A record, you're paying for that on every uncached lookup.

Practical Tips

Decide apex-or-www early. Changing your canonical hostname later means redirects, SEO consolidation work, and cookie scope changes.

Never put a CNAME on a name that needs MX. This includes the apex and any subdomain you receive mail on.

Check whether your provider's ALIAS forwards client subnet. If your CDN uses geographic routing, this determines whether users get their nearest edge.

Lower TTLs before a migration. Drop to 300 seconds a day ahead, make the change, verify, then raise them back.

Verify from multiple resolvers after any apex change. Apex misconfiguration frequently produces inconsistent results across resolvers, so a single check isn't sufficient.

Watch for CNAME on a name with TXT verification. Adding a vendor's verification TXT record to a name that's already a CNAME will silently fail.

FAQ

Why can't I put a CNAME at my root domain? Because a CNAME excludes all other records at that name, and the zone apex must have SOA and NS records. The two requirements are incompatible.

Is ALIAS the same as CNAME? No. ALIAS is resolved by your authoritative nameserver, which returns A/AAAA records. A CNAME is returned as-is and resolved by the client's resolver.

Can a subdomain have both a CNAME and a TXT record? No. The exclusivity rule applies to any name, not just the apex.

Does an apex CNAME break email? Yes, in most cases — MX queries for the apex get redirected to the CNAME target, which almost certainly doesn't have your mail servers.

How many CNAMEs can chain together? Resolvers vary but typically allow somewhere between 8 and 16 hops before giving up. Long chains add latency regardless.

Should I use the bare domain or www? Both are valid. www is technically simpler because it can be a CNAME; the bare domain needs ALIAS support or a redirect. Pick one, redirect the other, and be consistent.

The Takeaway

The CNAME exclusivity rule isn't an arbitrary restriction — it falls directly out of what a CNAME means. Once that's clear, the apex problem and its workarounds stop being confusing, and choosing between ALIAS, a redirect, or making www canonical becomes a straightforward tradeoff rather than a mystery.

Query any DNS record type for any domain free with the DNS Lookup tool at sadiqbd.com — no sign-up, instant results.