What is a CNAME record and when should you avoid it?

Sajjad
DNS
10 Oct, 2026

A CNAME record (canonical name record) is a DNS record that makes one hostname an alias of another. Instead of holding an IP address, it says "this name is really that name", and the resolver then looks up the target name to find the actual address. CNAMEs are ideal for pointing subdomains such as shop.example.com or docs.example.com at a hosted service whose IP addresses you don't control. You should avoid a CNAME at the bare domain (example.com), on any name that needs other records such as MX or TXT, as the target of MX or NS records, in long chains of aliases, and when pointing at services you might stop using without cleaning up the record.

CNAMEs are one of the most useful record types and also one of the most misunderstood. A single misplaced CNAME can stop email from arriving or make a dashboard refuse to save records. This article explains how a CNAME works, what happens during resolution, when it's the right tool, the rules that limit where it can be used, the situations where you should avoid it, and how to create and check CNAME records correctly.

How a CNAME Record Works

A CNAME record maps a name, called the alias, to another name, called the canonical name or target:

shop.example.com.   3600   IN   CNAME   shops.example.net.

This says that shop.example.com is an alias for shops.example.net. Nothing else about shop.example.com lives in your zone. Every record type a client might ask for, whether A, AAAA, TXT or anything else, is looked up at the target instead.

What Happens During Resolution

When a browser asks for the address of shop.example.com, the resolver:

Queries the nameservers for example.com and gets back the CNAME, pointing to shops.example.net.
Restarts the lookup for shops.example.net, querying the nameservers for example.net if the answer isn't cached.
Gets the A and AAAA records for shops.example.net.
Returns the whole chain to the client: the CNAME plus the final addresses.

dig shows the full chain in the answer section:

dig shop.example.com A +noall +answer

shop.example.com.	3600	IN	CNAME	shops.example.net.
shops.example.net.	300	IN	A	203.0.113.80
shops.example.net.	300	IN	A	203.0.113.81

Notice that each part of the chain has its own TTL. Your CNAME is cached for an hour, while the provider's A records are cached for five minutes, so the provider can move traffic quickly without you doing anything.

If you only want to see where the alias points, ask for the CNAME type directly:

dig shop.example.com CNAME +short

shops.example.net.

A CNAME Aliases the Whole Name

A common misconception is that a CNAME redirects only web traffic, or only A record lookups. It doesn't. It aliases the name for every record type. If someone looks up the TXT or MX records for shop.example.com, they get the TXT or MX records of shops.example.net. This is the reason for most of the restrictions below.

It also means a CNAME is not an HTTP redirect. Visitors' browsers still show shop.example.com in the address bar, and the server at the target must be configured to accept requests for that hostname, including having a valid TLS certificate for it.

When a CNAME Is the Right Choice

Pointing Subdomains at Hosted Services

The classic use for a CNAME is connecting a subdomain to a third-party platform: an online store, a help desk, a status page, a documentation host, a marketing landing page builder, or a website platform. The provider gives you a hostname to point at:

help.example.com.    3600  IN  CNAME  example.helpdesk.example.net.
status.example.com.  3600  IN  CNAME  statuspage.example.net.

The provider can now change servers, add capacity or move data centres by changing its own records, and your subdomain follows automatically.

Connecting to a CDN

CDNs typically give you a hostname, such as d111111abcdef8.cloudfront.net for Amazon CloudFront, and ask you to point your subdomain at it with a CNAME. The CDN then returns different addresses depending on where the visitor is.

cdn.example.com.  3600  IN  CNAME  d111111abcdef8.cloudfront.net.

Giving One Server Several Names

If several hostnames run on the same server, you can give the server one A record and point the other names at it. When the server's address changes, you update one record instead of many:

web1.example.com.     3600  IN  A      192.0.2.10
blog.example.com.     3600  IN  CNAME  web1.example.com.
intranet.example.com. 3600  IN  CNAME  web1.example.com.

Delegating Verification and DKIM Keys

Some services ask you to create a CNAME so they can manage a record on your behalf, for example DKIM keys for Microsoft 365 or many email marketing platforms, or certificate validation records for AWS Certificate Manager. The CNAME points to a record the provider controls, so it can rotate keys without asking you to change DNS.

selector1._domainkey.example.com.  3600  IN  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com.

The Rules That Limit CNAMEs

The DNS standards place firm restrictions on CNAMEs. These aren't recommendations; breaking them causes real failures.

A CNAME Can't Coexist With Other Records

RFC 1034 states that if a name has a CNAME record, it can't have any other data. That means no A, AAAA, MX, TXT, or anything else at the same name. The only exceptions are the DNSSEC records that sign the CNAME itself.

This zone is invalid:

; Invalid: a CNAME and a TXT record at the same name
shop.example.com.  3600  IN  CNAME  shops.example.net.
shop.example.com.  3600  IN  TXT    "verification=abc123"

Most DNS providers refuse to save it. BIND won't load a zone that contains it:

named-checkzone example.com db.example.com

dns_master_load: db.example.com:14: shop.example.com: CNAME and other data
zone example.com/IN: loading from master file db.example.com failed: CNAME and other data
zone example.com/IN: not loaded due to errors.

Only One CNAME per Name

A name can have only one CNAME record. Unlike A records, you can't publish several CNAMEs to spread traffic.

Targets Must Be Names, Not Addresses

The value of a CNAME is always a hostname. Typing an IP address into a CNAME field creates a pointer to a hostname that happens to look like an address, such as 192.0.2.10.example.com, which won't resolve.

When You Should Avoid a CNAME

At the Bare Domain

The bare domain (example.com, often entered as @) always has an SOA record and NS records. Because a CNAME can't coexist with other records, a CNAME at the zone apex is not allowed. Even if a provider let you save one, it would hide your NS and SOA records and break the zone, including email.

For the bare domain, use:

A and AAAA records pointing at your server's addresses, or
A provider-specific ALIAS, ANAME or flattened CNAME feature, if your DNS provider offers one, which resolves the target itself and returns ordinary A and AAAA records.

On Names That Need MX, TXT or Other Records

If a subdomain needs to receive email, carry an SPF or verification TXT record, or hold any other record, it can't be a CNAME. For example, if you want support.example.com to point at a help desk and receive email directly, you'll need to use A records for the website or receive mail on a different name.

This catches people out with domain verification. If a service asks you to add a TXT record at shop.example.com and that name is already a CNAME, the TXT record can't be added. Ask the service whether it supports verification at a different name, such as _verify.shop.example.com.

As the Target of MX or NS Records

RFC 2181 says the hostname in an MX or NS record must not be an alias. Mail servers and resolvers may tolerate it, but many won't, and the failures are often silent or intermittent.

; Avoid: MX target is a CNAME
example.com.       3600  IN  MX     10 mail.example.com.
mail.example.com.  3600  IN  CNAME  mx.mailhost.example.net.

; Better: MX target has its own address records, or point MX at the provider's host
example.com.       3600  IN  MX     10 mx.mailhost.example.net.

The same applies to NS records: nameserver hostnames must have their own A and AAAA records.

In Long Chains

A CNAME can point to another CNAME, which can point to another. Each step is a potential extra lookup at a different set of nameservers, and each one adds latency on a cache miss and another point of failure:

dig app.example.com A +noall +answer

app.example.com.		3600	IN	CNAME	app.platform.example.net.
app.platform.example.net.	300	IN	CNAME	lb-eu.platform.example.net.
lb-eu.platform.example.net.	60	IN	CNAME	edge-17.cdn.example.org.
edge-17.cdn.example.org.	60	IN	A	198.51.100.17

Providers create some chains for good reasons, but don't add your own links on top. Point your CNAME at the hostname the provider documents, not at another alias you created for it. Resolvers also stop following chains after a limit, so very long chains can fail outright.

When the Target Might Disappear

A CNAME is a standing instruction to trust whatever the target name returns. If you stop using a service but leave the CNAME in place, the target may become available for someone else to claim. On many platforms, an attacker can then register the same hostname or resource and serve their own content on your subdomain. This is known as a subdomain takeover.

The fix is simple housekeeping: when you cancel a service, delete the CNAME pointing at it. Review CNAMEs that point outside your organisation periodically, and remove any whose target no longer resolves:

dig old-campaign.example.com A +noall +answer +comments | grep -E "status|CNAME"

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50112
old-campaign.example.com. 3600	IN	CNAME	example-campaign.pages.example.net.

A CNAME whose target returns NXDOMAIN is a strong sign the record is dangling and should be removed.

When Performance Matters Most and You Control the Address

If the target is a server you run with a stable IP address, an A record is one lookup fewer. For a high-traffic name, a direct A record avoids the extra resolution step on every cache miss. The difference is small with a well-cached target, but there's no benefit to adding an alias you don't need.

How to Create a CNAME Record

In a DNS Dashboard

Open the DNS records page for your domain at the provider that hosts your DNS.
Remove any existing A, AAAA or other records on the name you're aliasing.
Add a record with type CNAME.
Enter the subdomain label, such as shop, in the name field. Don't use @.
Enter the target hostname exactly as your provider gives it, such as shops.example.net.
Choose a TTL, usually one hour, and save.

Some dashboards add a trailing dot automatically, some require it, and some add your domain to the end if you leave it off. After saving, check the result with dig to make sure the target is what you intended.

In a Zone File

In a BIND zone file, the target must end with a dot if it's outside your zone. Without the dot, the zone's origin is appended:

$ORIGIN example.com.
; Correct: fully qualified target
shop   3600  IN  CNAME  shops.example.net.

; Wrong: becomes shops.example.net.example.com.
blog   3600  IN  CNAME  shops.example.net

With Terraform

On Route 53, a CNAME is a record set with exactly one value:

resource "aws_route53_record" "shop" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "shop.example.com"
  type    = "CNAME"
  ttl     = 3600
  records = ["shops.example.net"]
}

Checking a CNAME Is Working

After adding a CNAME, confirm three things:

# 1. The alias exists and points where you expect
dig shop.example.com CNAME +short

# 2. The target resolves to addresses
dig shops.example.net A +short

# 3. The service accepts requests for your hostname
curl -sI https://shop.example.com/

If the first two work but the third fails with a certificate error or a "domain not found" page, the DNS side is fine. The provider hasn't yet been told about your custom hostname, or hasn't issued a certificate for it. Most platforms need you to add the domain in their dashboard as well as creating the CNAME.

FAQ: CNAME Records

No. The root domain always has SOA and NS records, and a CNAME can't exist alongside other records. Use A and AAAA records, or an ALIAS or flattened CNAME feature if your DNS provider offers one.

No. A CNAME must point to a hostname. If you have an IP address, create an A record for IPv4 or an AAAA record for IPv6 instead.

No. A CNAME only changes where DNS looks up a name. The browser still shows your hostname, and the target server must be set up to serve it. To redirect from one URL to another, you need a web server or redirect service.

Because a name with a CNAME can't have any other records. Remove the CNAME and use A records instead, or ask the service requiring the TXT record whether it supports verification at a different name.

It's allowed, but each extra link adds lookup time and another point of failure. Point your CNAME directly at the hostname your provider documents rather than at an alias of your own.

Slightly, on a cache miss, because the resolver has to look up the target as a separate step. With sensible TTLs, the difference is usually a few milliseconds and well worth it for hosted services.

Lookups for your subdomain fail with NXDOMAIN, and in some cases an attacker can claim the target and serve content on your subdomain. Delete CNAMEs when you stop using the service they point to.

Conclusion

A CNAME record turns one hostname into an alias for another, so the resolver looks up the target's records instead. That makes it the right tool for connecting subdomains to hosted platforms and CDNs, for giving one server several names, and for letting providers manage records such as DKIM keys on your behalf.

Its power comes with firm limits. Never use a CNAME at the bare domain, on a name that needs MX or TXT records, or as the target of MX or NS records. Keep chains short, check targets with dig, and delete CNAMEs as soon as you stop using the service they point to. Follow those rules and CNAMEs will save you work rather than causing outages.