Use an A record (plus AAAA) for the bare domain, because the zone apex also holds SOA, NS and usually MX records, and a CNAME can't coexist with other records. Use a CNAME for subdomains that should follow another name, such as www pointing at the apex or a subdomain pointing at a SaaS provider whose IP addresses may change.
The question usually shows up in one of two situations. A service tells you to “add a CNAME pointing to xyz.service.net” and your DNS panel won’t let you do it on the bare domain. Or you’re planning a server move and wondering how many records you’ll have to touch. Both have the same answer once you’re clear on what each type does.
CNAME vs A record in one sentence each
An A record says: “This name has this IPv4 address.” A CNAME says: “This name is an alias, go and ask about that other name instead.”
$ORIGIN example.com.
@ 3600 IN A 192.0.2.10
@ 3600 IN AAAA 2001:db8:10::1
www 3600 IN CNAME example.com.
shop 3600 IN CNAME stores.example-saas.net.Ask for www.example.com and you get the CNAME, followed by the address of example.com:
dig www.example.com A +noall +answerwww.example.com. 3600 IN CNAME example.com.
example.com. 3600 IN A 192.0.2.10Four rules that settle it
1. No CNAME at the zone apex. The apex always carries SOA and NS records, and a CNAME may not share its name with anything (RFC 1034, section 3.6.2). So example.com gets A and AAAA. Providers that offer ALIAS, ANAME or CNAME flattening work around this by resolving the target themselves and serving the result as A records. That’s a provider feature, not a standard record type, and it won’t move with you if you change DNS hosts.
2. A name with a CNAME has nothing else. No MX, no TXT, no second CNAME. If mail.example.com needs a TXT record, mail can’t be a CNAME.
3. MX and NS never point at a CNAME. RFC 2181, section 10.3. The MX target mail.example.com needs its own A record.
4. Third-party services with changing IPs get a CNAME. When a SaaS platform, CDN or status page gives you a hostname, point a CNAME at it. They can renumber their infrastructure without you doing anything.
Decision table
| Case | Use | Why |
|---|---|---|
example.com on your own VPS | A + AAAA | CNAME at the apex isn’t allowed |
www on the same VPS | CNAME to example.com. or A | Preference, CNAME means less upkeep |
app on a second server you own | A + AAAA | Its own address, no alias needed |
shop on a hosted platform | CNAME to the provider’s host | Their IPs can change |
mail as the MX target | A + AAAA | MX can’t point at a CNAME |
_acme-challenge delegation | CNAME | Standard acme-dns pattern |
The last row is explained in the wildcard certificate guide: you delegate only the challenge name to a zone a script is allowed to write.
Is a CNAME for www worth it?
On a single server, a www CNAME buys you one thing. When you move, you update A and AAAA on the apex and www follows automatically. With two names that’s a small win. With twenty subdomains on one box it’s a big one.
The cost is theoretical. On a cold cache the resolver needs the target too, but when alias and target live in the same zone, the authoritative server includes both in one response, as in the dig output above.
Conflicts your DNS panel will show
“Record conflicts with existing CNAME” or similar almost always means rule 2. The classic case: www is a CNAME, and now a verification service wants a TXT record on www. You can’t have both. Put the TXT on the apex if the service allows it, or turn www into A/AAAA records.
Some panels accept the conflict and store both records anyway. Nameserver software then behaves inconsistently and you end up chasing an error that only appears through some resolvers. Query each type separately after saving rather than using ANY, which many servers now answer only in a minimal form (RFC 8482).
Avoid CNAME chains
A CNAME may point at a name that is itself a CNAME. It’s legal, but every hop is another thing that can break, and resolvers follow chains only to a limited depth. Chains appear without anyone planning them: shop points at the platform, which points at its CDN, which points at a regional edge name. Three hops, two of them outside your control.
dig shop.example.com A +noall +answerEach hop shows as its own line. For names you control, keep it to one hop: www points at example.com, not at web, which then points at example.com.
CNAMEs, certificates and the reverse proxy
Let’s Encrypt doesn’t care whether www reaches your server through a CNAME or an A record. HTTP-01 follows resolution and ends up at the same IP. What matters is that the name is on the certificate: certbot -d example.com -d www.example.com.
On the server, a CNAME changes nothing. The browser still sends www.example.com in SNI and the Host header, never the CNAME target, so nginx or Caddy needs the original name configured. Multi-domain setups are covered in reverse proxy for multiple domains.
What CNAMEs save you in a migration
When you move to a new server, only records that contain an IP need editing. With CNAMEs for every subdomain, that’s two: A and AAAA on the apex. The full cutover is in server migration without downtime, and the basics of the address record are in set an A record.
At betadomain you edit these records in the customer area for the domain. If you’re starting something new, the betadomain domain search shows availability and the yearly price, an .app domain runs €22.99 a year, and the price list for all extensions is on a single page.
Found your domain? You can check and register it directly at check your domain – yearly price from €2.99.
FAQ
Why can't I put a CNAME on my root domain?
RFC 1034 and RFC 2181 say a name with a CNAME can't have any other records, and the zone apex always has SOA and NS records. Some DNS providers offer ALIAS, ANAME or CNAME flattening, which resolve the target on the server and return plain A records.
Is a CNAME slower than an A record?
Marginally. On a cold cache the resolver may need an extra lookup for the target. After that both answers are cached, and for page load times the difference is negligible.
Can an MX record point to a CNAME?
Not according to RFC 2181. The target of an MX or NS record has to be a name with its own A or AAAA records. Some mail servers tolerate it, but you shouldn't rely on that.
Should www be a CNAME or an A record?
If www lives on the same server as the bare domain, a CNAME to the apex means one fewer record to update when you move. A separate A record works just as well and saves a resolution step.