A CNAME record makes a name an alias for another name and, under the DNS rules, no other data should exist at that name. A zone apex must hold SOA and NS records, so a CNAME there conflicts. Use A or AAAA records, a provider alias feature, or a redirect from the bare domain instead.
What the rule says
RFC 1034 describes the CNAME this way: it marks its owner name as an alias for a canonical name. If a CNAME exists at a node, no other data should be present there. When a server finds a CNAME for a name it was asked about, and the query type is not CNAME, it includes the CNAME in the response and restarts the query at the canonical name. Loops are signaled as errors. Records that point at other names should reference the canonical name, not an alias.
Why the apex is special
The apex of a zone, such as example.com, holds the SOA record and the NS records that define the zone. It often also needs MX and TXT records for mail and verification. A CNAME there would exclude all of that, because the resolver would follow the alias and ignore everything else. Some DNS software refuses to load such a zone. Other software accepts it and then behaves unpredictably, with mail or validation records seeming to vanish.
Ways around it
- Use address records. Point the apex to the IP addresses your host gives you with A and AAAA records. The drawback is that you must update them if the target changes.
- Use a provider alias feature. Some DNS providers offer an ALIAS or flattening record that looks like an address record to the outside world while following another name internally. This is a provider feature, not part of RFC 1034, so check how it behaves with TTLs and failover.
- Redirect the bare domain. Serve a redirect from example.com to www.example.com, and put the CNAME on www. See choosing the right redirect status code.
- Use a different subdomain for the service. Many platforms ask you to use a subdomain for this reason.
Security angle
Aliases create trust. A CNAME that still points to a deprovisioned service is a takeover risk, which we cover in dangling DNS and subdomain takeover. Review every CNAME when you retire a service. Also remember TTL interplay: a change at the target is visible only after caches of the alias expire. See planning DNS TTLs.
A checklist before adding a CNAME
- Is the name a zone apex? If yes, do not use a CNAME.
- Does the name already hold other records, such as MX or TXT? If yes, a CNAME will conflict.
- Does the target belong to you or to a vendor that could release it?
- Is there an owner and a removal date for this alias?
Where Safeguard fits
Safeguard does not manage DNS zones. It scans dependencies and SBOMs for known vulnerabilities and offers asset discovery and policy gates for your software estate. A free scan is available at gold.safeguard.sh/scan.
Quick check
Can a CNAME coexist with an MX record?
Not under the RFC 1034 rule, which says no other data should be present at a node that holds a CNAME.
Is an ALIAS record part of the DNS standard?
No. It is a provider feature that imitates an address record, so check its behavior with your provider.
Sources
Last reviewed: 19 October 2026.
