If you have ever been asked to “point a subdomain” at an external service, or wondered why both www.yoursite.com and yoursite.com lead to the same place, the answer is usually a CNAME record. It is one of the most useful DNS records for connecting names to services — and one of the most misunderstood, thanks to a few important rules about where it can and cannot be used.

This guide explains what a CNAME record is in plain terms, how it differs from an A record, the crucial limitation that trips people up (you cannot use it on your root domain), its most common real-world uses, and exactly how to set one up. By the end, aliasing a subdomain or connecting a third-party service will feel simple rather than mysterious.

What a CNAME record is

A CNAME (Canonical Name) record maps an alias name — a domain or, more often, a subdomain — to another, “canonical” domain name. Rather than pointing to an IP address the way an A record does, it points to a name, essentially saying “this name is a nickname for that name; go look there for the real answer.”

When a browser requests the alias, DNS sees the CNAME, follows the pointer to the target name, and then resolves that target’s records to find the final IP address. So a CNAME adds a layer of indirection: the alias inherits whatever address the canonical name currently resolves to.

This makes CNAMEs powerful for keeping things in sync. Because the alias always follows the target, you can change where the target points and every CNAME aimed at it automatically follows — no need to update each alias individually with a new IP.

CNAME vs A record: the key difference

The core distinction is simple: an A record points to an IP address, while a CNAME points to another domain name. An A record is the final answer (“this name lives at this number”); a CNAME is a redirect within DNS (“this name is really that name — resolve that instead”).

This difference drives when you use each. If you have a numeric IP address to point to — your web server, say — you use an A record. If you want a name to mirror another name, following it wherever it goes, you use a CNAME. The CNAME’s value must always be a domain name; putting an IP address in a CNAME is invalid.

There is also a performance nuance: because a CNAME requires an extra lookup to resolve the target, chaining many CNAMEs together (one pointing to another pointing to another) adds delay. A single CNAME is fine; long chains are best avoided for speed.

The big limitation: no CNAME on the root domain

Here is the rule that catches almost everyone: you cannot use a CNAME on your root (apex) domain — example.com itself. The root domain must have certain records (like SOA and NS records) that a CNAME would conflict with, so DNS standards do not allow a CNAME there.

This means www.example.com can be a CNAME (pointing to example.com or to a service), but example.com at the root cannot. To point a root domain at a server you use an A record, and to point it at a service that only gives you a hostname, you either use the provider’s workaround or an A record with an IP.

In practice, this is why the common setup is an A record on the root domain and a CNAME on the www subdomain pointing back to it. Knowing this limitation up front saves you from the frustrating error of trying to add a CNAME where it is not permitted.

Common uses for CNAME records

CNAME records shine in a handful of everyday scenarios, most involving subdomains or external services:

• Pointing www to your root domain: a CNAME on www that aliases to example.com so both addresses lead to the same site.
• Connecting subdomains to external services: aliasing shop.yourdomain.com or app.yourdomain.com to a hostname provided by a SaaS platform, store builder, or CDN.
• Verifying or configuring services: many platforms ask you to add a CNAME to prove control of a subdomain or to route it to their infrastructure.
• Keeping aliases in sync: pointing several subdomains at one canonical name so they all follow it automatically if the target changes.

In each case, the CNAME’s job is the same: make one name behave like another. This is exactly what you want when a service gives you a hostname (not an IP) to point at, or when you want multiple names to track a single destination.

How to set up a CNAME record

Adding a CNAME follows the familiar DNS pattern. Log in to your DNS provider — your registrar or host — and open the DNS or zone editor for your domain. Choose to add a new record and select the type CNAME.

In the host/name field, enter the subdomain you want to alias — for example, www, or shop, or app. In the value/target field, enter the canonical domain name it should point to, exactly as provided (such as your root domain or a hostname from a service). Remember: this must be a name, never an IP address, and it cannot be the root domain in the host field.

Set the TTL or leave the default, then save. As with any DNS change, allow time for propagation before expecting the alias to resolve. Once it does, requests to your subdomain will follow the CNAME to its target and reach the right destination.

CNAME vs A record: which to use when

Because CNAME and A records both “point” a name somewhere, it helps to have a clear rule for choosing between them. The deciding question is simple: are you pointing to a numeric IP address, or to another name?

The pattern is easy to remember: if you have an IP address, use an A record; if you have a domain name to point to (and it is not the root), use a CNAME. This single distinction covers almost every pointing decision you will face, and keeps you from hitting the root-domain limitation or the no-IP rule.

CNAME gotchas to avoid

A few pitfalls account for most CNAME problems. First and most common is trying to put a CNAME on the root domain — remember it is only for subdomains and aliases, and the root needs an A record instead. If your DNS panel rejects a CNAME, this is usually why.

Second, never enter an IP address as a CNAME’s value; it must be a domain name. If you have an IP, use an A record. Third, avoid conflicting records: a name that has a CNAME generally should not also have other record types, because the CNAME is meant to be the sole, authoritative alias for that name.

Finally, watch out for long CNAME chains, which add lookups and slow resolution. A single, clean alias is efficient and reliable. Keep these rules in mind, and CNAME records become one of the most dependable tools for connecting names to the right destinations.

FAQs

What is a CNAME record?

A CNAME (Canonical Name) record maps an alias name — usually a subdomain — to another domain name rather than to an IP address. It acts as a nickname: when a browser requests the alias, DNS follows the pointer to the target name and resolves that to find the final address. It is ideal for pointing subdomains at other names or external services.

What is the difference between a CNAME and an A record?

An A record points a name to a numeric IPv4 address (a server), giving the final answer. A CNAME points a name to another domain name (an alias), adding a layer of indirection so the alias follows the target. Use an A record for IPs and the root domain; use a CNAME for subdomains and aliases. A CNAME’s value must be a name, never an IP.

Can I use a CNAME on my root domain?

No. DNS standards do not allow a CNAME on the root (apex) domain like example.com, because the root must hold records a CNAME would conflict with. Use an A record for the root domain instead, and reserve CNAMEs for subdomains such as www, shop, or app. This limitation is the most common source of CNAME errors.

What can I point a CNAME to?

Always another domain name — such as your root domain or a hostname provided by a service — never an IP address. Common targets include your own root domain (for a www alias) or a SaaS platform, store builder, or CDN hostname you have been asked to point a subdomain at. If you have an IP address, use an A record instead.

How do I set up a CNAME record?

Log in to your DNS provider, open the DNS or zone editor, add a record of type CNAME, put the subdomain in the host field (like www or shop), enter the target domain name in the value field exactly as given, set or keep the TTL, and save. Allow time for propagation, and remember the target must be a name and cannot be the root domain.

Why can’t a CNAME and other records coexist?

A CNAME is meant to be the single, authoritative alias for a name, so DNS standards say a name with a CNAME generally should not also have other record types (like A or MX). Mixing them causes conflicts and errors. If you need other records on a name, use an A record for it rather than a CNAME.

The bottom line

A CNAME (Canonical Name) record is a DNS alias: instead of pointing to a numeric IP address like an A record, it points one name to another name, telling DNS to follow the pointer to the real destination. That indirection makes it perfect for pointing www at your root domain, connecting subdomains to external services that give you a hostname, and keeping several aliases in sync with a single canonical name — because they all automatically follow the target wherever it goes.

The rules are what matter most. A CNAME’s value must always be a domain name, never an IP; it cannot be used on the root domain (which needs an A record instead); a name with a CNAME should not carry other record types; and long CNAME chains slow resolution. Keep those in mind — root domain gets an A record, subdomains and aliases get CNAMEs — and this record becomes one of the simplest, most reliable ways to connect names to the services and destinations you want.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. A CNAME aliases one name to another name (not an IP) — great for www and subdomains pointing to services. It can’t sit on the root domain (use an A record there), and its value must be a name.