A CNAME (Canonical Name) record maps one hostname to another hostname, rather than directly to an IP address. When a resolver looks up a subdomain that has a CNAME, it doesn’t get an address back immediately — it gets told “look at this other name instead,” and then has to resolve that name in turn. This indirection is what makes CNAME the standard way to point a subdomain at infrastructure you don’t control the IP address of: a CDN edge, a SaaS platform, a mail provider’s hosted service.
Two DNS rules govern where a CNAME can and can’t be used, and most of the practical confusion around CNAME setups — failed domain verification, broken email, subdomains that suddenly stop resolving — traces back to one of those two rules being violated, sometimes without the person configuring DNS realizing it.
What a CNAME record actually does
Consider a subdomain app.example.com that needs to point at a hosting platform’s infrastructure. Instead of hard-coding an IP address, the zone file contains:
app.example.com. CNAME hosting-platform.net.
When a client asks for app.example.com, the resolver receives this CNAME, then performs a second lookup for hosting-platform.net, which resolves to an A or AAAA record with an actual IP address. The client follows both steps transparently. The practical benefit is that if the hosting platform changes its underlying IP addresses — which large CDNs and SaaS providers do routinely, sometimes many times a day — nothing in your own zone file needs to change. The alias stays valid because it’s the target’s name, not its address, that you’ve recorded.
This extra lookup step adds a small amount of resolution latency compared to a direct A record, though in practice this is usually negligible next to network round-trip time and is generally not a meaningful factor in choosing between the two record types.
CNAME vs. A vs. ALIAS: choosing the right record for a subdomain
The decision usually comes down to whether you control a stable IP address at that name, and whether the name is a subdomain or the bare (apex) domain:
| Situation | Recommended record | Why |
|---|---|---|
| Subdomain pointing at a third-party service (CDN, SaaS platform, hosted email) whose IP can change | CNAME | The target manages its own IP addresses; you only need to track its hostname |
| Subdomain pointing at a server whose IP address you control and rarely change | A/AAAA | Removes an extra lookup step; no dependency on a third party’s DNS |
| Apex/root domain (example.com, not www.example.com) needing to point at third-party infrastructure | ALIAS/ANAME (provider-specific) or A record to a static IP | A true CNAME is not valid at the apex — see below |
| Subdomain that also needs to send or receive mail, or hold TXT/SPF/DKIM records | A/AAAA (not CNAME) | A CNAME can’t coexist with MX, TXT, or other record types at the same name |
Two hard rules every CNAME setup has to respect
Rule 1: No CNAME at the zone apex
You cannot place a CNAME record at your zone’s apex — the bare domain itself (example.com, not www.example.com). This is documented in RFC 1034, Section 3.6.2: if a CNAME is present at a name, no other record type may exist at that same name. The apex is required to carry SOA (Start of Authority) and NS (name server) records for the zone to function at all, and typically MX records as well if the bare domain sends or receives mail. Since a CNAME can’t share a name with those records, it structurally cannot sit at the apex. ISC’s BIND documentation notes that most authoritative DNS software will refuse to load a zone that tries this, precisely because it would produce undefined behavior.
This is why www.example.com can be a CNAME pointing at a hosting provider, but example.com itself generally can’t — it needs an A/AAAA record, or a provider-specific ALIAS/ANAME feature that behaves like a CNAME without violating the rule (explained further below).
Rule 2: A CNAME can’t coexist with any other record type at the same name
The apex restriction is really a special case of a broader rule: wherever a CNAME exists, it must be the only record at that name. This has a concrete, easy-to-miss consequence for subdomains: if mail.example.com has a CNAME record, you cannot also add an MX record, a TXT record for SPF, or a DKIM record at that same hostname — the presence of the CNAME forbids any other data there. Anyone setting up email authentication for a subdomain that’s already CNAMEd to something else will hit this wall, and the fix is usually to move the mail-related records to a different hostname or restructure the DNS rather than trying to force coexistence.
Wildcard CNAMEs: why “*.example.com → target.com” doesn’t work
A natural question once you’re managing several subdomains through CNAME is whether you can shortcut the process with a wildcard: one record covering every subdomain at once. A wildcard CNAME record — something like *.example.com CNAME target.com — is not a valid DNS configuration, for essentially the same reason a CNAME can’t sit at the apex. As explained in a DNS community reference, a wildcard matches any name under that suffix, including names that are required to carry other record types — so the same no-coexistence rule that blocks an apex CNAME blocks a wildcard CNAME from being generally reliable.
The practical workaround is a wildcard A or AAAA record pointing at a static IP, or a provider-specific wildcard-ALIAS feature where the DNS host resolves the target at query time and returns ordinary address records. Neither is a drop-in replacement for “CNAME every subdomain to a service that manages its own changing IPs” — if you genuinely need many subdomains pointed at a service with rotating IPs, you generally still need individual CNAME records per subdomain, or a provider integration designed for that pattern, rather than a single wildcard entry.
Setting up and verifying a CNAME record
The general procedure is consistent across DNS providers, even though the control-panel details differ:
- In your DNS zone editor, create a new record with type CNAME.
- Set the name/host field to the subdomain (e.g.,
appforapp.example.com) — never the apex. - Set the value/target field to the exact hostname the target service provides, including the trailing dot if your provider’s interface expects one.
- Save, and allow time for propagation (see below) before expecting it to resolve everywhere.
To verify, query the record directly rather than just refreshing a browser tab:
dig app.example.com CNAME +short nslookup -type=cname app.example.com
A correct setup returns the target hostname. If nothing comes back, or the old value still appears, the most common causes, roughly in order of likelihood, are: the record hasn’t propagated yet (see TTL below), a typo in the subdomain or target name, a duplicate/conflicting record already existing at that name, or a caching resolver still holding the previous answer. Checking against a public resolver directly (for example, by querying 8.8.8.8 or 1.1.1.1 with dig) can rule out local DNS caching as the cause.
Propagation timing is governed by the record’s TTL (time to live) — the number of seconds a resolver is allowed to cache the answer before checking again. If you’re planning a cutover, lowering the TTL to a short value (e.g., 300 seconds) a day or so in advance, then restoring it afterward, reduces how long stale answers can linger during the change.
CNAME chains, flattening, and ALIAS/ANAME workarounds
A CNAME chain occurs when a CNAME’s target is itself a CNAME (a → b → c → A record). This is technically valid but adds one DNS round-trip per hop and increases the number of things that can break the chain. There’s no single number written into the DNS specification for how many hops are allowed — it’s resolver-dependent. BIND, for instance, has followed chains up to 16 deep since 1999 as a loop-prevention measure; other recursive resolvers cut off anywhere from around 8 to 30. In practice, keeping chains to one hop in zones you control avoids the question entirely.
Several DNS providers offer a proprietary feature — commonly branded CNAME flattening, ALIAS, or ANAME — that lets you configure something that looks like a CNAME at the apex. Internally, the provider’s authoritative server resolves the target’s A/AAAA records at query time (or on a refresh schedule) and returns ordinary address records to the client, so the zone stays spec-compliant while you still get the convenience of pointing at a hostname rather than a fixed IP. This isn’t a standardized DNS record type — an IETF draft (draft-ietf-dnsop-aname) has proposed formalizing it, but implementations still vary by provider, and behavior at the edges (refresh timing, handling of the target going down) can differ.
Dangling CNAMEs and subdomain takeover
A dangling CNAME is a record that still points at a hostname whose underlying resource has since been deleted — a decommissioned cloud storage bucket, a shut-down hosting app, a SaaS trial that expired. The DNS record itself keeps working exactly as configured; the CNAME still resolves to the target hostname. The problem is what happens next: on many cloud and hosting platforms, hostnames are assigned to customers on a first-come basis. If the original resource is gone but the hostname is now unclaimed, someone else can potentially register a new resource under that same hostname, and your still-active CNAME will then point straight at content they control — served under your own subdomain.
This risk grows in proportion to how many CNAME-based subdomains an organization accumulates over time, since each one is a standing pointer to infrastructure outside the organization’s direct control, and it’s easy for a CNAME to outlive the service it was set up for. The practical hygiene step is straightforward even if it’s often skipped: remove the CNAME record at the same time you decommission or cancel the underlying service, and periodically audit existing CNAME targets to confirm the resources they point to still belong to you.
What breaks silently: email, TLS, and other easy-to-miss side effects
The coexistence rule described earlier has a specific, recurring consequence: a subdomain that has a CNAME record cannot simultaneously have MX, SPF (TXT), or DKIM (TXT) records for mail at that same name. If you CNAME a subdomain to a third-party service and later try to also send mail “from” that exact hostname, the mail configuration will fail to validate — not because of anything wrong with the mail settings themselves, but because the CNAME structurally excludes the other records.
A related, less obvious effect involves TLS certificates. When a subdomain is CNAMEd to a CDN or SaaS platform, that provider commonly also handles TLS certificate issuance and renewal for the subdomain, often using the same CNAME as part of how it validates that you control the name. Removing the CNAME — even if some origin server behind it still exists — can therefore break HTTPS for that subdomain, because the certificate validation path that depended on the CNAME no longer resolves the way the certificate authority expects. The exact validation mechanics vary by provider and certificate authority, but the general pattern — the CNAME isn’t just routing traffic, it’s also part of how the subdomain proves ownership for TLS — is worth keeping in mind before removing one.
FAQ
Can a CNAME and an MX record point at the same subdomain?
No. The coexistence rule forbids any other record type, including MX, at a name that already has a CNAME. If a subdomain needs both a CNAME to a third-party host and its own mail handling, one of the two typically needs to move to a different hostname.
Why does my CNAME still show the old value after I changed it?
Almost always TTL-related caching: resolvers hold the previous answer until it expires. Querying a fresh, uncached resolver directly with dig will confirm whether the authoritative record has actually changed, independent of what a browser or a heavily cached local resolver currently shows.
Is a wildcard CNAME ever valid?
Not as a general-purpose “cover every subdomain” configuration — a wildcard CNAME runs into the same coexistence conflict that blocks apex CNAMEs. Wildcard A/AAAA records, or a provider’s wildcard-ALIAS feature, are the usual substitutes when many subdomains need to resolve the same way.
