What Is a CNAME Record in DNS? Rules, Limits & Examples

What a CNAME Record Does

A CNAME (Canonical Name) record creates an alias from one domain name to another. Instead of pointing at an IP address, it points at a second hostname, and the resolver continues from there to find the actual address.

www.example.com    3600    IN    CNAME    example.com
blog.example.com   3600    IN    CNAME    sites.squarespace.com
shop.example.com   3600    IN    CNAME    stores.example.myshopify.com

The value of the indirection is that the target owns the address. When Squarespace or Shopify move their infrastructure to new IPs, your record keeps working — you aliased a name, not a number.

How Resolution Actually Works

When a resolver looks up www.example.com:

1. It queries www.example.com and receives a CNAME pointing to example.com.
2. It restarts the lookup for example.com and receives an A record — say 93.184.216.34.
3. It returns both records to the client: the CNAME and the final address.

The client connects to 93.184.216.34, but the HTTP Host header still carries www.example.com, and TLS still sends www.example.com in the SNI extension. This matters: the server sees the name the user typed, not the CNAME target. A CNAME does not redirect, rewrite, or change the URL in the address bar. It resolves a name to an address and nothing more.

That distinction causes a specific class of confusion. If you CNAME www.example.com to example.com expecting the browser to display example.com, it will not. The URL stays as typed. Changing the visible URL requires an HTTP redirect from the server.

The Rule That Causes Most CNAME Problems

RFC 1034 states that if a name has a CNAME record, it may have no other record types. This is not a provider limitation — it is fundamental to how DNS resolution works, and it produces two separate failures.

You Cannot Use a CNAME at the Zone Apex

The apex (example.com with no subdomain, sometimes called the root or naked domain) must carry SOA and NS records. Those cannot coexist with a CNAME, so the apex can never be a CNAME. Authoritative servers reject it; BIND reports it as CNAME and other data.

A CNAME Silently Disables MX and TXT on the Same Name

This is the version that breaks production. If example.com somehow carries a CNAME, its MX records are ignored and email stops being delivered. The same applies to the TXT records used for SPF, DKIM and domain verification. Nothing errors loudly; mail simply goes elsewhere or bounces.

The rule applies at every level, not just the apex. If mail.example.com has a CNAME, you cannot also put a TXT record on mail.example.com.

Apex Workarounds: ALIAS, ANAME and Flattening

Because pointing the apex at a SaaS host is such a common requirement, DNS providers built proprietary record types that behave like a CNAME at the apex while remaining legal. They resolve the target at the authoritative server and return a synthesised A/AAAA record, so the client never sees a CNAME at all.

Two caveats worth understanding before relying on one:

• The synthesis happens at your DNS provider, which means it resolves the target from wherever that provider's servers sit. If the target uses geographic or latency-based routing, the address returned reflects the provider's location, not the end user's. For a global CDN target this can route users suboptimally.
• These are not standardised. Behaviour, TTL handling and failure modes differ between providers, and migrating between them is not a straight copy.

Choosing Between CNAME, A and ALIAS

Chains, Loops and TTLs

A CNAME may point at another CNAME. Resolvers follow the chain, but each hop is a lookup, and each hop adds latency to the first uncached request. Resolvers cap chain depth — commonly around 8 to 16 hops — and a chain that loops back on itself (a → b → a) is detected and returns a failure rather than spinning.

Keep chains to one hop where you can. Two is occasionally unavoidable when a vendor's own hostname is itself a CNAME into their CDN; more than that is usually accumulated configuration debt.

On TTLs, both the CNAME's TTL and the target's TTL apply independently. If your CNAME has a 24-hour TTL and the target has a 60-second TTL, resolvers cache your alias for a day but re-resolve the target every minute. Before a planned migration, lower the CNAME's TTL well in advance so the change actually propagates when you make it — lowering it at cutover time is too late, because the old long TTL is already cached.

Verifying a CNAME

# The record itself, without following it
dig www.example.com CNAME +short

# The full chain, including the final address
dig www.example.com +noall +answer

# Confirm what the authoritative server returns, bypassing caches
dig @ns1.example-dns.com www.example.com +noall +answer

Querying the authoritative nameserver directly is the step that resolves most "I changed it and nothing happened" reports — it separates a wrong record from a cached one.

Troubleshooting

Frequently Asked Questions

Does a CNAME slow down my site? Marginally, and only on uncached lookups — each hop in the chain is an extra resolution. One hop is negligible. Long chains are worth flattening.

Does a CNAME affect SEO? No. DNS resolution is invisible to search engines, which see the hostname and the HTTP response. Duplicate content between www and the apex is an HTTP-level concern solved with redirects and canonical tags, not with DNS.

Can a CNAME point to an IP address? No. A CNAME's value must be a domain name. Pointing one at an IP is a configuration error that most providers reject outright.

Can I have two CNAMEs on the same name? No. A name may have exactly one CNAME. Multiple CNAMEs at one name is invalid.

Inspect CNAME records, follow the resolution chain, and confirm what an authoritative server returns with the DNS Lookup tool. If you are aliasing a subdomain to a vendor and TLS is failing, verify certificate coverage with the SSL Certificate Checker — and see What Is a Wildcard SSL Certificate? for why a wildcard may not cover the name you aliased.