What Is a CNAME Record? (And When to Use One)

A CNAME record is one of the most useful and most misunderstood entries in DNS. It lets one hostname act as an alias for another, so that instead of memorizing or maintaining an IP address, you point a name at another name and let DNS follow the trail. That sounds simple, but CNAME records come with a handful of strict rules that trip people up constantly, especially around root domains and email. This guide explains exactly what a CNAME does, when to reach for one, when not to, and how to verify it. You can look up any record discussed here for a real domain with the DNS Lookup lookup tool.

CNAME stands for Canonical Name. A CNAME record says "this name is just another name for that name." When a resolver asks for the address of an alias, it sees the CNAME, then restarts the lookup against the target (the canonical name) to find the real answer. The syntax in a zone file looks like this: blog.example.com. 3600 IN CNAME hosting.example.net. The left side is the alias you are defining, and the right side is the canonical target it points to.

The benefit is indirection. If hosting.example.net later changes its IP address, every name that is a CNAME to it automatically follows along with no edits on your side. You manage one address in one place, and all the aliases inherit it. That single property is the reason CNAMEs exist and the reason CDNs and SaaS providers love them.

The cleanest way to understand a CNAME is to contrast it with an A record. An A record maps a hostname directly to an IPv4 address, for example www.example.com pointing to 93.184.216.34 (an AAAA record does the same for IPv6). The answer is the final address itself. A CNAME, by contrast, maps a hostname to another hostname, and the resolver must do a second lookup to reach an address.

So the rule of thumb is: use an A or AAAA record when you control the IP and want to point straight at it, and use a CNAME when you want a name to track wherever another name goes. If you only ever see one of them in your provider's panel, an A record is the more fundamental building block; a CNAME is a convenience layered on top of it.

Here is the rule that catches almost everyone: you cannot put a CNAME on your apex (root) domain, the bare example.com with no subdomain in front. The reason is technical but firm. A CNAME must be the only record that exists for a given name, but the apex of every zone is required to have SOA and NS records. A CNAME at the apex would conflict with those mandatory records, so the DNS standards forbid it. Subdomains like www.example.com have no such requirement, which is why CNAMEs on subdomains are perfectly legal.

This is a problem when a host tells you to point your bare domain at something like myapp.platform.com, because you literally cannot create that CNAME at the apex. The workaround is ALIAS or ANAME records, a provider-specific feature offered by DNS hosts such as Cloudflare, Route 53, DNSimple, and others. An ALIAS/ANAME behaves like a CNAME but is allowed at the apex because the provider resolves the target behind the scenes and returns plain A records to the world.

CNAME flattening is the mechanism that makes apex aliasing work. Instead of returning a CNAME to resolvers, the DNS provider follows the chain itself, looks up the final IP addresses of the target, and serves those as ordinary A and AAAA records. From the outside world's perspective there is no CNAME at all, just normal address records, which keeps everything standards-compliant at the apex.

Cloudflare popularized the term, and ALIAS/ANAME records elsewhere do essentially the same thing. The practical upside is that you get the maintenance benefit of a CNAME (the target manages its own IPs) without breaking the apex rules. The trade-off is that flattening happens at your provider, so the target's changes are only as fresh as your provider's caching of it, and you depend on that provider supporting the feature.

The classic use is www. Many sites set www.example.com as a CNAME to example.com (or vice versa) so the two stay in sync. The second big use is SaaS and platform hosting: services like GitHub Pages, Shopify, Heroku, Netlify, and Vercel ask you to add a CNAME from your subdomain to their hostname so traffic reaches their infrastructure and so they can issue an SSL certificate for you.

CDNs are another major case. Pointing assets.example.com or your whole site at a CDN's hostname via CNAME means the CDN can reroute you across its edge network without you ever touching an IP. Finally, CNAMEs are widely used for domain verification: a provider asks you to create a uniquely named CNAME (for example _acme-challenge or a long random subdomain) pointing to one of their hostnames to prove you control the domain, common for certificate validation and email-sending services.

The cardinal rule is that a CNAME must stand alone. No other record may coexist with a CNAME on the same name, no A record, no TXT, no MX. If you CNAME mail.example.com and then try to add an MX or TXT to that same name, your DNS will be invalid or your provider will reject it. The well-known MX/CNAME conflict comes from this: never CNAME a hostname that also needs MX records, because mail delivery for a CNAMEd name behaves unpredictably and is discouraged by the standards.

Two more traps. Chaining CNAMEs (an alias pointing to an alias pointing to an alias) adds a DNS round trip at each hop and slows resolution, so keep chains short. And dangling CNAMEs, aliases pointing at a target that no longer exists, are a real security risk: if you decommission a cloud resource but leave the CNAME, an attacker may be able to claim the abandoned target and hijack your subdomain. Audit and remove CNAMEs you no longer use.

To inspect a CNAME, query the specific hostname and look for a record of type CNAME and the canonical target it returns. The fastest way is the DNS Lookup lookup tool, which shows the alias, its target, and the addresses the target ultimately resolves to. On the command line, dig www.example.com CNAME or nslookup -type=cname www.example.com does the same job. If you query through a provider that flattens, remember you may see A records instead of a CNAME, which is expected behavior at an apex.

After you create or change a CNAME, it will not take effect everywhere instantly, because resolvers cache records until the TTL expires. Confirm the new value has spread across global resolvers with the DNS Propagation tool, which compares the answer from many locations at once. If results disagree, you are simply waiting out the old TTL rather than facing a broken configuration.

Can I use a CNAME on my root domain? No. The apex requires SOA and NS records, and a CNAME must be alone, so it is not allowed at the root. Use your provider's ALIAS or ANAME record instead, which achieves the same result through CNAME flattening.

Why does my provider reject the MX record I'm adding? Because the name already has a CNAME, and no other record may share a name with a CNAME. Remove the CNAME and use an A record, or place the alias on a different hostname.

I added a CNAME but the site still doesn't load. Why? The old value is cached until the previous TTL expires. Verify the change with the DNS Lookup tool and watch global rollout with the DNS Propagation tool before assuming something is wrong.

Is a CNAME slower than an A record? Slightly, because it requires the resolver to do an extra lookup to follow the alias to an address. The difference is usually negligible, but avoid long chains of CNAMEs pointing at other CNAMEs.