CNAME Restrictions: Every Rule DNS Actually Enforces

Four Rules, One Root Cause

Every CNAME restriction that trips people up traces back to a single idea baked into the DNS specification: a CNAME asserts that a name is purely an alias, and nothing else. Once that premise is clear, every specific rule that follows from it — apex conflicts, coexistence errors, MX and NS interactions — stops feeling arbitrary and starts feeling like a direct, logical consequence of that one design decision.

Rule 1: The Apex Restriction

A domain's apex — example.com, with no subdomain — must carry NS records (delegating the zone to its nameservers) and an SOA record (zone metadata) at minimum. Both are mandatory for the zone to function. Since a CNAME forbids any other record from coexisting at its name, and the apex's own required records directly conflict with that, standard DNS simply disallows a CNAME at the apex outright. This is the single most-hit CNAME restriction in practice, especially for anyone trying to point a bare domain at a CDN or hosting platform that expects a CNAME-style setup.

Rule 2: The Coexistence Rule

This is the general form of Rule 1, and it applies everywhere, not just the apex: a name that has a CNAME record cannot have any other record type at that exact same name. Not a second CNAME, not a TXT record, not an MX record — nothing. If a subdomain needs both a CNAME and, say, a TXT record for verification purposes, that TXT record needs to live at a different name (often achieved with an underscore-prefixed subdomain convention many services use specifically to avoid this collision).

Rule 3: MX Records Should Not Target a CNAME

Per long-standing RFC guidance, an MX record's target should point directly at a name holding an A/AAAA record, not at a further CNAME alias. Many modern mail systems tolerate it in practice, but it's explicitly discouraged and some strict implementations reject it outright — the safe, portable approach is always pointing MX directly at a canonical, address-holding name.

Rule 4: NS Records and CNAME Don't Mix

Similarly, a name that's serving as a nameserver reference (via an NS record, particularly at a delegation point) shouldn't simultaneously hold a CNAME — this collides with the same coexistence principle and can cause inconsistent, resolver-dependent behavior if attempted.

Restriction Reference Table

How Providers Work Around the Apex Rule

Because the apex restriction is so commonly hit, most managed DNS providers built a workaround: Cloudflare's CNAME flattening, and various providers' ALIAS or ANAME record types, let you configure apex behavior that looks and acts like a CNAME to you, while the provider resolves the real target internally and serves a standards-compliant A/AAAA record externally. It's not a change to the DNS specification itself — it's a provider-side trick that satisfies both the letter of the restriction and the practical need it was blocking.

Common Mistakes

Best Practices

Before adding any CNAME, check what already exists at that exact name — the coexistence rule is absolute, and catching a conflict before attempting to save avoids a confusing validation error. Reserve the apex for a direct A/AAAA record or your provider's flattening feature, never a plain CNAME. And when a service asks for both a CNAME and a verification TXT record at the same place, expect to need a workaround subdomain — it's a routine, well-understood pattern, not a sign something's broken.

Related Tools

Check what's currently published at any hostname with DNS Lookup before adding a new CNAME. Trace an existing chain with CNAME Lookup, or check the address a chain resolves to with A Record Lookup and AAAA Record Lookup. Hit the apex restriction specifically? See Apex Domain Issues next.