What is a CNAME record?

A CNAME record (Canonical Name record) is a type of DNS record that allows one hostname to act as an alias for another hostname. Instead of pointing directly to an IP address, a CNAME points to a different domain name, which is then resolved to an IP address through additional DNS lookups.

CNAME records are commonly used to connect subdomains to services that are managed elsewhere, such as CDNs, SaaS platforms or hosted applications. They provide flexibility by allowing the destination infrastructure to change without requiring updates to the original domain’s DNS configuration.

It’s important to understand that a CNAME operates entirely at the DNS layer. It does not redirect users, change URLs or influence how browsers or search engines interpret a request after it reaches a server.

What is a CNAME record?

A CNAME (canonical name) record declares that one hostname is an alias for another. When DNS is queried for the alias, it does not return an IP address directly. Instead, it returns the canonical hostname, which is then resolved to its underlying A or AAAA record. This allows one domain to point to another hostname rather than to a fixed IP address.

Example 1: Using a CNAME with a third-party platform

Large brands often use CNAME records when hosting parts of their websites on external platforms. For example, if Nike wanted to host its blog on HubSpot while keeping the branded URL blog.nike.com, it would create a CNAME record that points blog.nike.com to a hostname provided by HubSpot, such as nike.hubspot.net.

When a user visits blog.nike.com, DNS responds that the subdomain is an alias for nike.hubspot.net and then resolves nike.hubspot.net to its corresponding IP address. The browser then connects to HubSpot’s infrastructure. Importantly, HubSpot is configured to serve content specifically for blog.nike.com. The HTTP request includes blog.nike.com as the requested host and the SSL certificate is issued for that branded subdomain.

This setup allows the brand to maintain full control over its domain while delegating hosting and scaling responsibilities to a third-party platform.

Example 2: www vs. apex domain configuration

Another common use case involves the www subdomain and the apex (root) domain. DNS standards do not allow a traditional CNAME at the apex (for example, urllo.com), so the root must use A or AAAA records that point directly to an IP address. However, the www version can use a CNAME. A typical setup might look like this:

• urllo.com → A record → CDN IP address
• www.urllo.com → CNAME → urllo.com

When a user visits www.urllo.com, DNS resolves the CNAME to urllo.com and then returns the IP address from the A record. This configuration keeps the apex DNS-compliant while allowing flexibility for the www subdomain. Companies often pair this with an HTTP redirect so that one version becomes the canonical domain for SEO and consistency.

This approach allows organizations to centralize traffic handling while ensuring both versions of the domain resolve reliably. Ultimately, the goal is to enforce a single authoritative hostname for branding, analytics and search engine visibility while maintaining DNS compliance and operational flexibility.

CNAME vs A record

The difference between a CNAME record and an A record lies in what each record ultimately resolves to and how much control you retain over the destination.

An A record maps a hostname directly to an IP address. When a DNS resolver looks up a hostname with an A record, it immediately receives the IP address to connect to. This makes A records straightforward and predictable, but it also means the IP address must be updated manually if it changes. A records are most commonly used for root domains and infrastructure you control directly.

A CNAME record maps a hostname to another hostname rather than to an IP address. When a resolver encounters a CNAME, it performs an additional lookup for the target hostname, which then resolves to an A or AAAA record. This extra step allows the destination’s IP addresses to change without requiring updates to the original DNS configuration, shifting IP management responsibility to the canonical destination.

In practical terms, A records provide direct control, while CNAME records provide flexibility. A records are best suited for domains where stability and ownership of infrastructure matter, whereas CNAME records are ideal for subdomains that depend on external services, CDNs or platform-managed endpoints.

How CNAME records work in DNS

When a browser, crawler or application requests a hostname that uses a CNAME record, the DNS resolution process follows a chain rather than returning an IP address immediately.

The resolver first asks DNS for the requested hostname. Instead of receiving an IP address, it receives a response indicating that the hostname is an alias for another hostname. The resolver then repeats the lookup for that new hostname. This continues until a record that resolves directly to an IP address is reached.

All of this happens before any HTTP request is sent. By the time the browser connects to a server, DNS resolution has already completed and the CNAME is no longer visible. This distinction is critical because it explains why CNAMEs influence routing but not application behavior.

CNAME lookup: how to check if a hostname uses a CNAME

A CNAME lookup is the process of querying DNS to determine whether a hostname is configured as a CNAME and, if so, what it resolves to. This is commonly done when troubleshooting DNS issues, validating SaaS integrations or confirming where traffic is being routed.

Because CNAMEs operate entirely at the DNS layer, they can’t be seen from the browser alone. Instead, they must be inspected using DNS lookup tools that query authoritative DNS records.

Most DNS lookup tools allow you to enter a hostname and view its record types. If a CNAME exists, the response will show the canonical hostname that the alias points to. In many cases, that canonical hostname will then resolve to additional CNAMEs before ultimately resolving to an A or AAAA record.

This chained resolution is normal, but long or unexpected CNAME chains can indicate misconfiguration. Performing a CNAME lookup helps confirm whether a hostname is behaving as intended and whether traffic is being routed through the expected services or platforms.

It’s also worth noting that a successful CNAME lookup does not mean a redirect is occurring. Even if a hostname resolves through multiple CNAMEs, the browser will still request the original URL and any visible redirect behavior must still be handled by HTTP responses at the destination server.

What a CNAME is not

A CNAME record is often misunderstood as a form of redirect, but the two concepts are fundamentally different.

CNAME records are handled at the DNS layer and don’t interact with HTTP. A CNAME does not instruct a browser to request a new URL. It does not send an HTTP status code and it does not change what appears in the address bar. From the user’s perspective, the original hostname never changes.

Redirects, by contrast, are handled at the HTTP layer. They occur after a request reaches a server and explicitly tells the client, such as a web browser or search engine, to make a new request to a different URL. Because CNAMEs operate before HTTP even begins, they cannot perform any of these functions.

This is why CNAMEs cannot be used to consolidate URLs for SEO, force HTTPS or move traffic from one page to another.

When should you use a CNAME?

CNAME records are particularly useful when the destination hostname is expected to change over time or is managed by another system. Many SaaS providers require customers to point a subdomain to a platform-controlled hostname using a CNAME so they can scale, migrate or rebalance infrastructure without customer involvement.

They are also widely used with CDNs, edge platforms and load-balanced services where IP addresses are abstracted away from the user. In these scenarios, CNAMEs reduce operational overhead and simplify long-term maintenance.

When you should not use a CNAME

Despite their flexibility, CNAME records are not appropriate in every situation.

Traditional DNS standards do not allow CNAMEs at the apex (root) domain because the root must also support other record types such as SOA and NS. While some DNS providers offer workarounds like ALIAS or ANAME records, these are not true CNAMEs and behave differently behind the scenes.

CNAMEs are also a poor fit for email-related configurations, since mail records have strict requirements that conflict with CNAME usage. Most importantly, CNAMEs should not be used when the goal is to redirect users, merge content or control SEO behavior.

CNAMEs and redirects

The confusion between CNAMEs and redirects usually comes from the idea that both involve “pointing” one name to another. However, they solve entirely different problems.

A CNAME determines where traffic is routed at the DNS level. A redirect determines how a request is handled after it reaches a server. If the goal is to move users or crawlers from one URL to another, only an HTTP redirect can accomplish that.

This distinction matters for SEO. Search engines rely on HTTP status codes, not DNS aliases, to understand content movement, canonical URLs and ranking signal transfer.

Common CNAME mistakes

Treating a CNAME like a redirect:

One of the most common mistakes is assuming a CNAME behaves like an HTTP redirect. Because a CNAME points one hostname to another, it’s easy to think it will move users or search engines to a new URL. In reality, a CNAME only affects DNS resolution. The browser never changes URLs and no redirect response is sent.

Using CNAMEs where direct control is required:

CNAMEs are sometimes applied to critical or high-value hostnames where direct control would be safer. Because the final destination is abstracted, troubleshooting becomes harder when something breaks and ownership can become unclear across teams or vendors.

Creating long CNAME chains:

While DNS resolvers can follow multiple CNAMEs, long chains increase lookup time and introduce unnecessary complexity. Each additional hop adds latency and makes configurations more fragile, especially when different systems control different parts of the chain.

Email-related misconfigurations:

CNAMEs are frequently misused in email setups, where strict DNS requirements apply. Introducing a CNAME where mail-related records are expected can break delivery or authentication, often without obvious errors. Web and email hostnames should be planned separately to avoid conflicts.

Leaving CNAMEs in place indefinitely:

CNAMEs are sometimes used as a quick fix and then forgotten. Over time, unused or undocumented CNAMEs accumulate, creating hidden dependencies that surface only when platforms change or services are decommissioned.

Understanding these mistakes reinforces the core role of CNAMEs: they are a DNS routing convenience, not a traffic management or SEO tool. Used intentionally and kept simple, they are reliable and low maintenance.

What does “CNAME cross-user banned” mean?

A CNAME cross-user banned error indicates that a CNAME record is pointing to a hostname owned or controlled by another customer on a shared platform and that platform has blocked the association for security reasons.

This commonly occurs with SaaS providers, CDNs or multi-tenant services that allow custom domains. To prevent domain hijacking or accidental traffic takeover, these platforms enforce ownership checks. If a CNAME points to a destination that is already claimed by another user or has not been explicitly authorized for your account, the platform may reject the configuration and surface a “cross-user banned” or similar error.

In practice, this means the DNS record itself may be technically valid, but the destination service refuses to serve traffic for that hostname because it cannot verify ownership.

Resolving this issue usually requires one of the following actions: properly claiming or verifying the domain within the destination platform, removing or correcting the CNAME to point to the correct tenant-specific hostname or working with the service provider to release or reassign the target if it was previously used elsewhere.

This error is not related to redirects, HTTP status codes or browser behavior. It is a platform-level protection mechanism designed to prevent unauthorized domain mappings in shared infrastructure environments.

SEO implications of CNAME records

From an SEO standpoint, CNAME records are largely neutral. Search engines follow DNS resolution transparently and do not treat CNAMEs as signals of content movement or consolidation.

All SEO-relevant behavior happens at the HTTP layer. Indexing, ranking, canonicalization and redirects are governed by response codes, headers and page content, not DNS aliases. As a result, CNAMEs should be viewed as an infrastructure convenience rather than an SEO tool.

Understanding where CNAMEs fit

CNAME records are a foundational DNS tool, but they solve a very specific problem: aliasing one hostname to another at the DNS level. They are designed to simplify infrastructure management, not to move users, consolidate URLs or influence SEO behavior.

Understanding where CNAMEs fit and where they do not, is essential for building reliable DNS configurations and avoiding misapplied redirects or broken setups. When used intentionally, CNAMEs provide flexibility and resilience; when misunderstood, they often create confusion that only becomes visible much later in production.

Frequently asked questions about CNAME records

Is a CNAME the same as a redirect?

No. A CNAME is a DNS alias that operates before an HTTP request is made. Redirects happen at the HTTP layer and explicitly instruct browsers and crawlers to request a different URL.

Can a CNAME affect SEO rankings?

Not directly. Search engines base ranking and indexing decisions on HTTP responses, not DNS aliases.

Can a CNAME point to another CNAME?

Yes, but long chains should be avoided because they increase DNS lookup time and complexity.

Why can’t I use a CNAME at the root domain?

Because the root domain must support other DNS records. Some providers offer alternatives, but they are not true CNAMEs.

By Shannon Young

Customer Success Manager

Shannon is a seasoned professional in the customer success space. She has years of experience in a wide variety of customer-facing roles in various sectors.

Always ready to take on the next challenge, whether it be a new offensive cross stitch pattern or making her dogs sit still for another themed photo, she is prepared for anything.