Problem

A platform told you to “create a CNAME record pointing to something.theirservice.com,” and you opened your DNS panel to a Type dropdown, a Name box, and a Value box that explain nothing. Pick the wrong type or put the wrong thing in the wrong box and the connection silently fails — the platform’s dashboard keeps saying “waiting for DNS,” and you have no idea why.

A CNAME is the simplest record type to describe and the easiest to get subtly wrong. It does exactly one thing: it makes a name an alias for another name. www.example.com is a CNAME for example.com. shop.example.com is a CNAME for mystore.myplatform.com. When a resolver hits a CNAME, it stops, reads the target, and starts the lookup over at that target — following the alias until it lands on real address records.

That “start over at the target” behavior is the whole point, and it’s also where the two rules that trip everyone up come from.

The one thing a CNAME points at

A CNAME’s value is a hostname, never an IP address. This is the first place people go wrong. They have a server at 203.0.113.10, they see a CNAME option, and they try to paste the IP in. It doesn’t work, because a CNAME means “go ask about this other name,” and an IP isn’t a name to ask about.

The rule of thumb is short:

  • You have a hostname a platform gave you (cname.vercel-dns.com, yourname.github.io, d1a2b3.cloudfront.net, a load balancer’s DNS name): use a CNAME, value = that hostname.
  • You have a raw IP address: use an A record (IPv4) or AAAA record (IPv6), value = the address.

The reason platforms hand you a CNAME target instead of an IP is deliberate: their underlying addresses change without notice, and a CNAME re-resolves on every lookup, so it follows them automatically. Hard-code their IP in an A record and the day they renumber, your site breaks and nothing tells you.

The rule that surprises everyone: a CNAME can’t share its name

Here’s the constraint that causes most “it won’t save” and “it half-works” reports. RFC 1034 §3.6.2 says a name that has a CNAME has no other data. No second record of any kind can live on the same name as a CNAME — not an A, not an MX, not a TXT, not another CNAME.

This bites in real, ordinary ways:

  • You have example.com set up for email with an MX record, and you try to CNAME it to your website host. Can’t — the MX and the CNAME can’t coexist on the same name.
  • A service asks you to add a verification TXT record on a subdomain that’s already a CNAME. Can’t — the CNAME owns that name exclusively.
  • You want both a CNAME and an A record on www “just in case.” Can’t — pick one.

When you genuinely need mail, a TXT, or anything else on the same name as your web target, the answer is to use an A record there instead of a CNAME, since A records don’t have this exclusivity, or move the CNAME’d service to a different label.

Why the root domain is different

You cannot put a CNAME on the apex — the bare example.com with nothing in front. The apex is required to carry SOA and NS records (they’re what make it a zone at all), and by the rule above, a CNAME can’t share a name with them. This is a real limitation, not a provider quirk.

If a platform tells you to “CNAME your root domain to us,” what you actually want is your DNS provider’s ALIAS, ANAME, or CNAME flattening feature — a synthetic record that acts like a CNAME at the apex but resolves to real A/AAAA records behind the scenes so the apex still holds address records, not an alias. Cloudflare does this flattening automatically; Route 53 calls it an alias record; others call it ANAME. On any normal subdomain, none of this applies — a plain CNAME is correct.

What goes in the name box

Every DNS panel auto-appends your domain to whatever you type in the Name/Host field. So for www.example.com you enter just:

www

Not www.example.com. Type the full name and the provider appends the zone again, giving you a record for www.example.com.example.com that resolves for nobody. It’s invisible until you do a lookup and see the doubled name. A few panels want a trailing dot to mean “this is complete, don’t append,” and Cloudflare lets you paste the full name and strips the zone for you — but the safe habit everywhere is: type only the label.

Chains and loops

A CNAME can point to another CNAME, which points to another — resolvers follow the chain. It’s legal, but every hop is another lookup and another thing that can break, so keep chains short. What you must never create is a loop: a.example.com → b.example.com → a.example.com. Resolvers detect the cycle and return a failure (SERVFAIL), and nothing under either name will load. If a name mysteriously stops resolving after you “cleaned up” some records, check that you didn’t point two aliases at each other.

Check it with DechoNet

  • DNS Lookup resolves the name and shows the actual CNAME chain it follows — the fastest way to confirm the alias points where you meant, catch the doubled-name trap (www.example.com.example.com shows up right in the answer), or see the NXDOMAIN that means the target itself doesn’t exist.
  • DNS Propagation checks the name from resolvers worldwide at once, so you can tell “I just need to wait out the old TTL” (some resolvers see it, others don’t yet) apart from “the record is wrong” (nobody sees it).

Resolution Checklist

  • Confirm you actually want a CNAME: you were given a hostname to point at, not an IP. (IP → A/AAAA instead.)
  • In the Name/Host box, enter only the label (www, shop), never the full www.example.com.
  • Make sure that name has no other records — no A, MX, or TXT sharing it. If it needs them, use an A record instead.
  • Not on the apex: the bare root domain needs ALIAS/ANAME/flattening, not a CNAME.
  • Save, then look it up with DNS Lookup and confirm the answer is your target, not a doubled name or NXDOMAIN.
  • If some resolvers see it and others don’t, wait out the old TTL and check propagation instead of re-editing a correct record.

When to Escalate

  • The target returns NXDOMAIN or has no address records. Your CNAME is correct but points at a name that doesn’t resolve — the fix is on the platform’s side, not yours. Confirm the exact target string they gave you.
  • You need mail and a web alias on the same name. You can’t have an MX and a CNAME on one name. Use an A record for the web target, or move the aliased service to a different label.
  • The apex won’t accept the record. If your provider has no ALIAS/ANAME/flattening option, you can’t alias the root at all — move to a DNS provider that offers it, or point the apex at an A record and CNAME only www.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.