CNAME Records Explained: How to Set Up Subdomains Correctly

Someone on your team wants "blog.yourdomain.com" pointed at a hosted Ghost blog, or you're setting up "app.yourdomain.com" for a SaaS tool, and the setup instructions just say "add a CNAME record." If you've only ever dealt with A records for your main domain, that one line can be more confusing than it should be. Here's what a CNAME actually does, when to use it instead of an A record, and the mistakes that cause "domain not verified" errors even after you've added the record correctly.

What a CNAME Record Actually Does

A CNAME (Canonical Name) record is an alias. Instead of pointing a hostname directly at an IP address like an A record does, it points that hostname at another hostname, and lets DNS resolve the rest of the chain from there.

So if blog.yourdomain.com has a CNAME pointing to hosted.ghost.io, a visitor's browser does two lookups behind the scenes: first it resolves blog.yourdomain.com to hosted.ghost.io, then it resolves that hostname to whatever IP address Ghost is currently using. The advantage is obvious once you say it out loud — if Ghost changes their server IPs tomorrow, your CNAME keeps working with zero changes on your end, because you were never pointing at an IP in the first place.

An A record, by contrast, points straight at a fixed IPv4 address. If that server's IP ever changes, every A record pointing to it breaks until someone updates them manually.

CNAME vs A Record: When to Use Which

The Rule That Trips Everyone Up: No CNAME at the Root

You cannot put a CNAME record on your bare root domain (yourdomain.com, no subdomain prefix). This isn't a cPanel limitation — it's a DNS protocol rule (RFC 1034). The root of a zone has to carry other record types too — the SOA record, NS records, and often MX for email — and a CNAME at that name would conflict with all of them, since a CNAME can't coexist with any other record type at the same hostname.

This is why services like Shopify or Ghost that want you to "CNAME your root domain" usually give you a second option: either use "www" as your storefront and 301-redirect the root to it, or point the root at their service using an A record (sometimes called an "ALIAS" or "ANAME" record, which some DNS providers offer as a workaround that behaves like a CNAME but is legal at the apex).

Symptom: "Domain Verification Failed" After Adding the CNAME

You added the record exactly as instructed, waited an hour, and the third-party service still says it can't find your CNAME. Before assuming DNS is broken, check for these:

• A duplicate A record or another CNAME already exists at that same subdomain name — only one record (of any single type) is allowed per hostname for CNAMEs, and it can't share the name with anything else.
• You typed the destination with a trailing dot missing or extra, or included http:// in the value field — CNAME values should be a bare hostname, no protocol, no path.
• You're checking too soon. DNS changes take time to propagate, see below.
• Your domain's nameservers point somewhere other than where you're editing the zone — a very common mix-up if you bought the domain at one registrar but manage DNS through cPanel's Zone Editor at SkyServer, or vice versa.

Fix: Adding a CNAME Record in cPanel

1. Log in to cPanel and open Zone Editor under the Domains section.
2. Select the domain you want to edit and click Manage (or + CNAME Record if your version of cPanel shows the buttons directly).
3. In the Name field, enter just the subdomain part — for example blog, not blog.yourdomain.com. cPanel appends the domain automatically.
4. In the Record Type dropdown, choose CNAME.
5. In the Record (destination) field, paste the exact hostname the third-party service gave you — something like shops.myshopify.com or ghost.io. Don't add https:// and don't add a trailing slash.
6. Save, then give it time before testing — see the propagation note below.

If you're on a VPS running your own DNS (or using an external DNS provider like Cloudflare), the fields are the same conceptually: hostname, type CNAME, target. Just make sure the actual authoritative nameservers for the domain are the ones you're editing — run whois yourdomain.com or check the registrar's nameserver settings if you're not sure.

Verifying It Actually Resolved

Don't rely on your browser — local and ISP-level DNS caching will happily show you a stale answer for hours. Use a lookup tool instead:

dig blog.yourdomain.com CNAME +short

On Windows, the equivalent is:

nslookup -type=CNAME blog.yourdomain.com

You should see the exact destination hostname you entered come back. If it returns nothing, the record either hasn't propagated yet or wasn't saved correctly — go back into Zone Editor and double-check it's there.

How Long Propagation Actually Takes

New CNAME records typically show up within 15–30 minutes on most resolvers, but full global propagation (every ISP's cache, everywhere) can take up to 24–48 hours in the worst case, mostly because DNS resolvers cache answers for the record's TTL (Time To Live) value. If you're planning a subdomain launch, set the TTL low — 300 seconds (5 minutes) is common — a day or two before you actually change the record, so the old cached answer expires quickly once you do make the change. You can raise the TTL back to a normal value (3600 or higher) once everything's confirmed working.

Prevention: Keep Your Zone File Clean

• Before adding a new CNAME, check whether an A record or another CNAME already exists at that exact name — delete the old one first rather than leaving both.
• Keep a simple record of every CNAME you've added and why (which third-party service, added on what date) — six months later, nobody remembers what "crm.yourdomain.com" was pointing at or whether it's safe to delete.
• When a third-party service's setup wizard gives you a CNAME target with a trailing dot (like ghs.googlehosted.com.), cPanel's Zone Editor handles that automatically — you generally don't need to add the dot yourself.
• Never point a CNAME at another CNAME unless the provider specifically tells you to — chained CNAMEs add lookup latency and occasionally break with strict resolvers.

Frequently Asked Questions

Can I use a CNAME for my root domain (yourdomain.com without www)?

No. DNS rules don't allow a CNAME at the zone apex because it would conflict with required records like SOA, NS, and MX. Use an A record for the root, or check if your DNS provider offers an ALIAS/ANAME record, which behaves like a CNAME but is permitted at the root.

Why does my CNAME still show the old value after I changed it?

This is almost always caching. Your ISP, your router, or your own computer cached the previous answer for the record's TTL duration. Flush your local DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS) or just check with dig from a different network to confirm the record itself is correct.

Can I point a CNAME and an MX record at the same subdomain?

No. A CNAME record cannot share a hostname with any other record type, including MX. If you need mail on a subdomain that also needs a CNAME for something else, that's not possible under standard DNS — you'd need to restructure which hostname does what.

Is there a difference between www as a CNAME versus www as an A record?

Functionally, visitors won't notice a difference. A CNAME is easier to maintain because if your server's IP changes, you only update the root's A record and www follows automatically. An A record for www is one less DNS lookup, which is a negligible speed difference in practice.

How do I remove a CNAME record safely?

In cPanel's Zone Editor, find the record and click Delete. Before you do, confirm nothing (an email client, an app, a third-party integration) is still actively relying on that subdomain resolving — deleting a live CNAME breaks access to whatever it was pointing at immediately once caches expire.