What Is a CNAME Record?
A CNAME (Canonical Name) record is a DNS entry that points one domain name to another name rather than to an IP address, creating an alias. When a name has a CNAME, DNS follows it to the target name and then resolves that target's address. CNAMEs are commonly used to point subdomains like www or shop at a primary domain or a third-party service, so the underlying IP can change without editing your own records.
- Full name
- Canonical Name record
- Points to
- Another domain name (an alias)
- Root domain use
- Not allowed on the bare domain in classic DNS
- Defined in
- DNS standards (IETF RFC 1035)
What is a CNAME record? #
A CNAME, or Canonical Name record, is a DNS entry that makes one name an alias for another name. Instead of pointing to a numeric IP address the way an A record does, a CNAME points to a different domain name, and DNS then looks up that target to find the actual address, see /wiki/what-is-an-a-record. For example, www.yourbusiness.com might be a CNAME pointing to yourbusiness.com; anyone visiting the www version is transparently resolved to wherever the bare domain lives. The big advantage is indirection: if the destination's IP address changes, you do not have to update the CNAME, because it points to a name, not a number, and the name's own record handles the address. This makes CNAMEs ideal for connecting subdomains to services whose IPs you do not control. They are a core part of everyday DNS management, which we handle for clients through /services/domains-dns-email, and they fit into the broader lookup system explained on /wiki/what-is-dns.
How does a CNAME record work? #
When a resolver encounters a CNAME during a lookup, it does not stop there, it follows the alias. Suppose shop.yourbusiness.com is a CNAME pointing to stores.someplatform.com. The resolver sees the CNAME, then looks up stores.someplatform.com, finds that name's A record (its IP address), and returns that address to the browser. This chaining can even go through multiple aliases, though keeping chains short is best for speed. The key behavior is that a CNAME delegates address resolution to another name entirely. Because of this, a name that has a CNAME cannot also carry other record types, the CNAME takes over resolution for that name completely. That single rule explains many CNAME limitations and errors. Understanding this flow helps you place CNAMEs correctly: they belong on subdomains that should mirror another name, not on names that need their own separate records. We configure these correctly and verify the resulting chain resolves cleanly.
When should you use a CNAME record? #
CNAMEs shine whenever you want a subdomain to follow another name rather than a fixed IP. The classic case is pointing www at the bare domain so both load the same site. Another very common use is connecting a subdomain to a third-party service, pointing shop at an ecommerce platform, blog at a hosted blog, help at a support tool, or app at a hosted application, see /services/ecommerce-development. These providers often ask you to create a CNAME to their hostname so that when they change servers, your subdomain keeps working automatically. CNAMEs are also handy for verifying domain ownership with services that supply a unique CNAME target. In each case the benefit is the same: you delegate the address to someone else's name, and they manage the IP behind it. This is why so many SaaS onboarding guides say create a CNAME record. We set these up as part of connecting stores, apps, and marketing tools through /services/domains-dns-email.
CNAME vs A record: what's the difference? #
The core distinction is what each points to. An A record maps a name to a numeric IPv4 address, a fixed destination you control, see /wiki/what-is-an-a-record. A CNAME maps a name to another name, an alias that defers the actual address to the target. Use an A record when you know the IP and want to point a name straight at your own server, which is required for the root domain. Use a CNAME when you want a subdomain to track another name, especially a third-party service whose IP might change. There are important rules: you cannot put a CNAME on the bare root domain in classic DNS, and a name with a CNAME cannot have other records like MX or TXT. Getting this wrong causes email or verification failures. Choosing the right record type for each name is basic DNS hygiene, and mistakes here are a frequent cause of broken subdomains, which we prevent by setting records correctly the first time.
Why can't you use a CNAME on the root domain? #
In classic DNS, the root or bare domain, yourbusiness.com with no subdomain, cannot use a CNAME. The reason is technical but important: the root domain must carry certain mandatory records, notably the SOA and NS records that define the zone, and because a name with a CNAME cannot coexist with any other records, putting a CNAME on the root would conflict with those required entries. So the root domain almost always needs an A record pointing to an IP address instead. This creates a common headache when a third-party service asks you to point your root domain at their name via CNAME, which classic DNS forbids. Providers and DNS hosts solve it with workarounds like ALIAS, ANAME, or CNAME flattening records, which behave like a CNAME at the root while returning an IP address to comply with the rules. Knowing this prevents a very common setup error, and we use the correct root-level technique for whatever platform a client connects.
CNAME flattening, ALIAS, and ANAME records #
Because a true CNAME cannot sit on the root domain, DNS providers created alternatives that deliver the same convenience without breaking the rules. ALIAS and ANAME records (names vary by provider) let you point the root domain at another name; behind the scenes the DNS provider resolves the target name to its IP and returns that address, so the root gets a valid A-style answer while you still get the flexibility of pointing at a name. CNAME flattening, offered by providers like Cloudflare, does the same thing, resolving a root-level CNAME down to an IP automatically. These features are what make it possible to host a root domain on platforms that only give you a hostname to point at, such as many app and store services. They are provider-specific, so the exact name and behavior depend on where your DNS lives. We choose the right mechanism for each client's DNS provider and target platform, ensuring the root domain works reliably, as part of /services/domains-dns-email and store or app launches via /services/ecommerce-development.
Common CNAME mistakes and how to avoid them #
Several recurring errors cause CNAME trouble. Trying to add a CNAME on the root domain fails or breaks the zone, use an A record or an ALIAS/flattening feature instead. Placing a CNAME on a name that also needs MX or TXT records silently breaks email or verification, because a CNAME cannot coexist with other records; the fix is to point the CNAME at a subdomain that has no other records, or to use a different record type. Long CNAME chains, where an alias points to another alias and another, slow resolution and should be kept short. Forgetting that CNAME changes take time to propagate leads to confusion when a new subdomain does not work immediately, see /wiki/what-is-dns-propagation. Finally, editing the CNAME at a non-authoritative provider does nothing, see /wiki/what-is-a-nameserver. We avoid all of these by planning record layout carefully and verifying resolution after every change, so subdomains and connected services work on the first try.
How do you create a CNAME record? #
You add a CNAME wherever your domain's DNS is managed, at your registrar, host, or DNS provider, in the DNS or zone editor. You enter the name (the subdomain, such as www, shop, or app), select record type CNAME, and provide the target hostname you want it to alias, for example the bare domain or a service's provided hostname, then set a TTL. Make sure the name you are aliasing has no other records, and never place a CNAME on the root domain, use your provider's ALIAS or flattening feature there instead. After saving, allow time for propagation, then confirm the subdomain resolves to the intended target and loads correctly, including over HTTPS if a certificate is involved, see /wiki/what-is-an-ssl-certificate. Because a small slip can break a store connection or a subdomain, we set up and verify CNAMEs for clients as part of /services/domains-dns-email, and coordinate them during store, app, and marketing integrations.
CNAMEs, SSL, and connected services #
CNAMEs frequently sit at the junction between your domain and outside services, so they interact with SSL certificates and platform verification. When you point a subdomain at a third-party service via CNAME, that service usually needs to issue an SSL certificate for the subdomain so it loads securely over HTTPS, and it often validates ownership through DNS before doing so, sometimes using another CNAME you add temporarily, see /wiki/what-is-an-ssl-certificate. If the CNAME is wrong or missing, the certificate cannot be issued and visitors see security warnings. This is why store platforms, landing-page builders, and app hosts give precise CNAME instructions during onboarding, and why getting the record exactly right matters. We manage these connections end to end, adding verification and pointing records, confirming certificates issue, and testing the secure result, so linked services like /services/ecommerce-development stores and /services/ppc-landing-pages campaign pages come online cleanly under your own domain.
FAQ
What does a CNAME record do?
A CNAME record points one domain name to another name, creating an alias. DNS follows the CNAME to its target and resolves that name's address. It is commonly used to point subdomains like www or shop at a primary domain or a third-party service, so the underlying IP can change without editing your record.
What is the difference between a CNAME and an A record?
An A record points a name to a numeric IP address; a CNAME points a name to another name (an alias). Use an A record for the root domain and when you know the IP, and a CNAME for subdomains that should track another name, especially third-party services. See /wiki/what-is-an-a-record.
Why can't I put a CNAME on my root domain?
The root domain must carry required records (SOA and NS), but a name with a CNAME cannot have any other records, so a root CNAME would conflict. Instead, use an A record or your DNS provider's ALIAS, ANAME, or CNAME flattening feature, which behaves like a CNAME at the root while returning a valid IP.
Can a CNAME and an MX record exist on the same name?
No. A name that has a CNAME cannot also carry other records like MX or TXT, because the CNAME takes over resolution for that name entirely. Putting a CNAME on a name that needs mail records silently breaks email. Use the CNAME on a name with no other records, see /wiki/what-is-an-mx-record.
How long does a CNAME change take to work?
Like other DNS changes, a new or edited CNAME can take from a few minutes to 48 hours to take effect worldwide, depending on the TTL and caching. This is called DNS propagation. Lowering the TTL beforehand speeds up the change, see /wiki/what-is-dns-propagation.
Why do third-party services ask me to add a CNAME?
Because a CNAME lets your subdomain follow their hostname, so when they change servers, your subdomain keeps working without you editing records. Services also use CNAMEs to verify domain ownership and issue SSL certificates. We handle these setups when connecting stores, apps, and marketing tools through /services/domains-dns-email.
Was this helpful?