Can You Use a CNAME Record on the Root Domain?

It is one of the most common DNS questions there is. Your hosting platform says "add a CNAME pointing to myapp.example-cdn.net," it works perfectly for www.example.com, and then you try to do the same for example.com and your DNS panel throws an error, or worse, accepts it and your email quietly stops arriving. The short answer is no, a standards-compliant zone cannot have a CNAME record at the root domain. The longer answer explains exactly which rule forbids it, what actually breaks if you ignore that rule, and which options you have for getting a root domain onto a hostname-based platform. If you are unsure what a CNAME does in the first place, read What Is the Difference Between A Records and CNAME Records? first.

What "Root Domain" Means Here

In this context, the root domain (also called the apex, naked domain or bare domain) is the name at the top of your DNS zone: example.com itself, as opposed to www.example.com or shop.example.com. In a zone file it is usually written as @.

This is not the same as the DNS root (the single dot above every TLD). It is simply the topmost name in the zone you control. If the distinction between a zone and a domain is fuzzy, What Is the Difference Between a DNS Zone and a Domain? clears it up.

The Rule: A CNAME Cannot Coexist with Other Data

The restriction comes from RFC 1034, section 3.6.2, which says that if a CNAME record is present at a name, no other data should be present there. RFC 2181 (section 10.1) later tightened the language and made the intent unambiguous: a name with a CNAME is purely an alias and cannot also hold its own records. The only exceptions are DNSSEC records such as RRSIG and NSEC, which RFC 4035 allows alongside a CNAME so the alias itself can be signed.

The reason is logical rather than arbitrary. A CNAME says "example.com is another name for myapp.example-cdn.net; ask about that instead." If a resolver asks for the MX records of example.com and finds a CNAME, it must follow the alias and ask for the MX records of myapp.example-cdn.net. Any MX record you also put directly at example.com would contradict that instruction. The protocol avoids the ambiguity by forbidding the combination.

Why the Apex Always Has Other Data

Every zone apex must contain:

• An SOA record, which marks the start of the zone and holds its serial number and timers.
• NS records, which list the authoritative nameservers.

These are not optional. A zone without them is not a valid zone. Most apexes also hold MX records for email, TXT records for SPF and domain verification, and often CAA records. So the apex can never satisfy the "nothing else at this name" condition, and a CNAME there is always a violation.

Here is what a typical apex looks like in zone-file form:

$ORIGIN example.com.
$TTL 3600
@   IN  SOA   ns1.example-dns.net. hostmaster.example.com. (
        2026100101 ; serial
        7200       ; refresh
        900        ; retry
        1209600    ; expire
        300 )      ; negative caching TTL
@   IN  NS    ns1.example-dns.net.
@   IN  NS    ns2.example-dns.net.
@   IN  MX    10 mail.example.com.
@   IN  TXT   "v=spf1 include:_spf.example-mail.net -all"
@   IN  A     203.0.113.10
www IN  CNAME myapp.example-cdn.net.

The www CNAME is fine, because nothing else lives at www.example.com. The apex has SOA, NS, MX, TXT and A records, all legally coexisting.

Now try replacing the apex A record with a CNAME:

@   IN  CNAME myapp.example-cdn.net.

BIND's zone checker will reject it:

named-checkzone example.com db.example.com

dns_master_load: db.example.com:12: example.com: CNAME and other data
zone example.com/IN: loading from master file db.example.com failed: CNAME and other data

named-checkzone parses the zone file and validates it before you load it. "CNAME and other data" is the exact error for this situation. Most managed DNS dashboards enforce the same rule with a friendlier message.

What Breaks If a Provider Lets You Do It Anyway

Some lax DNS hosts and old control panels accept an apex CNAME. The record may even seem to work for the website. The damage shows up elsewhere, and inconsistently, because different resolvers handle the illegal combination differently.

1. Email delivery fails. A resolver that has cached the CNAME for example.com will follow it when asked for MX records, look for MX at myapp.example-cdn.net, find none, and fall back or fail. Mail to you@example.com starts bouncing intermittently. This is the most common real-world symptom, and it is covered more broadly in How Does Changing DNS Affect Email Services?
2. SPF, DMARC and verification TXT records disappear. The same logic applies to TXT lookups, so SPF checks fail and domain verification for services like Google Workspace stops validating.
3. Delegation becomes unreliable. NS and SOA lookups may be redirected to the CNAME target, confusing resolvers and secondary servers.
4. Behaviour depends on cache state. Whether a given query sees the CNAME or the other records can depend on which was cached first, so problems appear and vanish, which makes them painful to diagnose.
5. DNSSEC validation can fail because the signed data no longer matches what the protocol says should exist.

In short, "it loads my website" is not evidence that an apex CNAME is safe.

How to Check Whether a Domain Has an Apex CNAME

If you inherit a domain and suspect someone has put a CNAME at the root, ask its authoritative server directly:

dig example.com CNAME +short
dig example.com MX +short
dig example.com SOA +short

If the first command returns a hostname, the apex has a CNAME. The next two show whether MX and SOA answers come back correctly or are being redirected to the alias target. On Windows, the equivalent check is:

Resolve-DnsName -Name example.com -Type CNAME
Resolve-DnsName -Name example.com -Type MX

Resolve-DnsName returns any CNAME at the name, then the MX records, so you can see whether mail routing is intact.

Your Practical Options

You cannot change the rule, but you have several well-tested ways to get the result you actually want: a root domain served by a platform that identifies itself with a hostname.

Option 1: Use A and AAAA records

If your platform publishes stable IP addresses for apex domains, use them. Many platforms do exactly this, usually anycast addresses that do not change. It is the most portable option because every DNS provider supports A records and every resolver understands them.

@   IN  A     203.0.113.10
@   IN  AAAA  2001:db8::10

The downside is that if the platform ever changes those IPs, you must update them yourself. If the platform offers IPv6, add the AAAA record too.

Option 2: Use an ALIAS or ANAME record

Many DNS providers offer a pseudo-record that accepts a hostname target but answers with A and AAAA records. It looks like a CNAME in the dashboard and behaves like an A record on the wire. Route 53 calls it Alias, Azure DNS has alias record sets, and others call it ALIAS or ANAME. Details and provider-by-provider examples are in What Is an ALIAS or ANAME Record?

Option 3: Use CNAME flattening

Some providers, most prominently Cloudflare, let you enter a CNAME at the apex and then flatten it: the authoritative server resolves the target and returns plain addresses. You get the convenience of a CNAME without violating the rule, because no CNAME is ever served. The mechanism has trade-offs around CDN location accuracy and TTLs, explained in What Is CNAME Flattening?

Option 4: Redirect the apex to www

Put the real CNAME on www.example.com and make the apex do nothing but redirect. The apex needs an A record pointing at something that issues an HTTP 301 redirect, which can be your host, your CDN, or a registrar's forwarding service. Many large sites use www as their canonical hostname for exactly this reason. With nginx, the redirect server block looks like this:

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 301 https://www.example.com$request_uri;
}

This block answers for the bare domain on both HTTP and HTTPS and permanently redirects every request to the same path on www. You still need a valid certificate covering example.com so HTTPS visitors do not see a warning before the redirect.

Option 5: The HTTPS record (emerging)

RFC 9460 defines the HTTPS record type, whose AliasMode can point an apex at another hostname in a standards-compliant way. Browsers that query HTTPS records can use it, but support for AliasMode is not yet universal, so it is a complement to A/AAAA records rather than a replacement. See What Are HTTPS and SVCB Records in DNS?

Comparing the options

Option	Standards-compliant	Follows platform IP changes	Portable between providers	Notes
A / AAAA records	Yes	No	Yes	Best when platform IPs are stable
ALIAS / ANAME	Yes on the wire	Yes	No	Provider-specific feature
CNAME flattening	Yes on the wire	Yes	No	Watch TTLs and CDN steering
Redirect apex to www	Yes	Yes (on www)	Yes	Adds one HTTP redirect for apex visitors
HTTPS AliasMode	Yes	Yes	Yes	Client support still incomplete

Which Option Should You Choose?

A sensible decision process:

1. If your platform publishes stable apex IPs, use A and AAAA records. Simple, portable and universally supported.
2. If it only gives you a hostname and your DNS provider supports ALIAS or flattening, use that, and test from several regions.
3. If your DNS provider supports neither, either move DNS to one that does, or redirect the apex to www and use a normal CNAME there.
4. Optionally publish an HTTPS record as well, for clients that can use it.

Platform-specific instructions for two of the most popular hosts are in How to Point a Domain to Vercel or Netlify Using DNS.

---

CNAME on the Root Domain FAQ

Conclusion

A CNAME on the root domain is not allowed, and the reason is structural: a CNAME turns a name into a pure alias, while the zone apex must always carry its own SOA and NS records, and usually MX and TXT records too. Providers that appear to allow it are either flattening the record behind the scenes, which is safe, or storing an illegal combination that will eventually cause intermittent email and verification failures, which is not.

The good news is that you have plenty of options. Use stable A and AAAA records when your platform provides them, an ALIAS or flattened CNAME when it does not, or a redirect to www when your DNS provider supports neither. Pick the one that fits your platform and provider, verify it with dig, and your root domain will resolve correctly without putting the rest of your DNS at risk.

Here are some useful references for going deeper on apex CNAME rules and alternatives:

1. RFC 1034: Domain Names - Concepts and Facilities — section 3.6.2 defines CNAME behaviour and the no-other-data rule.
2. RFC 2181: Clarifications to the DNS Specification — section 10.1 clarifies that a CNAME cannot coexist with other data.
3. RFC 4035: Protocol Modifications for the DNS Security Extensions — allows DNSSEC records alongside a CNAME.
4. Cloudflare Docs: CNAME flattening — Cloudflare's approach to apex CNAMEs.
5. BIND 9 Documentation: BIND 9 Administrator Reference Manual — includes named-checkzone and zone-file syntax.