CNAME vs A Record: When to Use Each

If you have ever stared at a DNS control panel trying to decide whether to add a CNAME or an A record, you are not alone. The two record types look similar on the surface, both point a hostname somewhere useful, but they work in completely different ways under the hood. Choosing the wrong one causes broken subdomains, email delivery failures, and SSL certificate errors that are genuinely difficult to debug if you do not know where to look. This guide cuts through the confusion with concrete examples, exact configuration steps, and clear rules for when each record type belongs in your zone file.

What an A Record Actually Does

An A record maps a hostname directly to an IPv4 address. When a resolver asks "where is example.com?", an A record answers with something like 203.0.113.42. That is the end of the lookup chain. The resolver hands the IP address to the browser, and the browser opens a TCP connection to that address.

A records are the most fundamental building block in DNS. Every hostname that users or services reach must ultimately resolve to an IP address, and an A record is the most direct way to get there.

You can have multiple A records for the same hostname pointing to different IP addresses. Resolvers will return all of them, and clients typically try each one, which gives you a basic form of load balancing or failover without any extra infrastructure.

What a CNAME Record Actually Does

A CNAME (Canonical Name) record is an alias. Instead of answering with an IP address, it tells the resolver "go look up this other hostname instead." The resolver then follows that second hostname through whatever records it has, which might be another CNAME, or eventually an A record.

In the second example above, anyone visiting shop.example.com will be transparently redirected at the DNS level to Shopify's infrastructure. When Shopify changes their IP addresses, your DNS record does not need to change because the CNAME still points to the same Shopify hostname.

The Core Difference That Matters in Practice

The single most important distinction: a CNAME points to a hostname, an A record points to an IP address. Everything else flows from that.

Because a CNAME defers the final IP resolution to another hostname, it adds one extra DNS lookup step. For most situations that extra millisecond is irrelevant, but it becomes relevant when you chain CNAMEs together. RFC 1034 technically allows CNAME chains, but deep chains add latency and some older resolvers or strict implementations refuse to follow them beyond a certain depth. Keep CNAME chains to two hops maximum as a practical rule.

The Zone Apex Problem with CNAMEs

This is where most confusion and real breakage originates. You cannot use a CNAME at the zone apex, which is the root of your domain (example.com without any subdomain prefix). The DNS specification forbids it because a CNAME record must be the only record for that name, but the apex always has SOA and NS records. Putting a CNAME there would make the zone invalid.

This is why providers like Cloudflare, AWS Route 53, and others invented proprietary record types (ALIAS, ANAME, or CNAME flattening) that look like CNAMEs in your control panel but resolve like A records externally. If you need your bare domain (example.com) to point to a load balancer hostname or a CDN endpoint, you need one of these flattened record types, not a raw CNAME.

When to Use an A Record

• Your zone apex (bare domain). example.com must use an A record unless your DNS provider supports ALIAS/ANAME flattening.
• When you control the server and its IP is stable. Dedicated servers, VPS instances, or on-premises equipment with static IPs are perfect candidates.
• Mail server hostnames (MX targets). The target of an MX record must resolve to an A record, never to a CNAME. RFC 2181 explicitly prohibits CNAME targets for MX, NS, and SOA records.
• When you need multiple IPs for the same name. Round-robin DNS with A records is simple and supported everywhere.
• Internal and split-horizon DNS. When pointing internal hostnames to RFC 1918 addresses (10.x, 192.168.x, 172.16-31.x), use A records directly.

When to Use a CNAME Record

• Pointing a subdomain to a third-party SaaS platform. Shopify, HubSpot, Zendesk, GitHub Pages, Heroku, Fastly, and virtually every hosted platform tells you to create a CNAME so they can rotate IPs without breaking your setup.
• Creating a www alias for your root domain. A common pattern is www.example.com CNAME example.com, so the www version always follows wherever the root resolves.
• When the destination IP changes frequently. CDN edge nodes, cloud load balancers, and auto-scaling services change IPs constantly. A CNAME to their stable hostname means you never have to chase IP changes.
• Simplifying multi-region or multi-environment setups. Point staging.example.com to a CNAME that your infrastructure team controls independently, without touching your main zone for every deployment.

Step-by-Step: Adding an A Record

The exact steps depend on your DNS provider, but the fields are the same everywhere.

1. Log into your DNS provider's control panel (Cloudflare, GoDaddy, Namecheap, Route 53, etc.).
2. Navigate to the DNS management section for your domain.
3. Click Add Record or equivalent.
4. Set Type to A.
5. Set Name/Host to @ for the zone apex, or the subdomain label (e.g., mail for mail.example.com).
6. Set Value/Content to the IPv4 address of your server.
7. Set TTL to 3600 (one hour) for stable records, or 300 (five minutes) if you expect to change it soon.
8. Save the record.

Step-by-Step: Adding a CNAME Record

1. Log into your DNS control panel.
2. Click Add Record.
3. Set Type to CNAME.
4. Set Name/Host to the subdomain label only. For www.example.com, enter www. Do not enter the full domain here; most providers append the domain automatically.
5. Set Value/Target/Points to to the destination hostname. Include the trailing dot if the interface accepts raw zone file syntax, otherwise just the hostname.
6. Set TTL. CNAME records for third-party services often benefit from a shorter TTL (300-600 seconds) so you can update quickly if the provider changes their hostname.
7. Save. Do not add any other record type for the same name (no A, MX, or TXT for a name that already has a CNAME).

How to Verify Your Records Are Correct

Never assume a DNS change worked. Verify it from the command line and from an external tool.

On Linux or macOS, use dig:

On Windows, use nslookup:

For a CNAME, the first query should return the canonical name (the target hostname), and a subsequent A lookup for that canonical name should return IP addresses. If your CNAME query returns an IP directly, your provider is doing CNAME flattening, which is fine for most use cases.

You can also use the DNS Lookup tool to query specific record types and see exactly what is published in the DNS for your domain from multiple resolvers.

Common Mistakes and How to Fix Them

CNAME at the Zone Apex

Symptom: Your DNS provider throws an error when you try to save the record, or worse, it saves but your domain stops working entirely because the SOA and NS records are hidden behind the CNAME.

Fix: Delete the CNAME. Add an A record with the IP address of the destination. If you do not know the IP and only have a hostname, use dig to resolve the target hostname, get its current IP, and use that. Better yet, switch to a DNS provider that supports ALIAS/ANAME records (Cloudflare, DNS Made Easy, Route 53, Constellix all do this).

CNAME on the Same Name as an MX Record

Symptom: Email stops delivering. Mail servers following your MX record find a CNAME and either refuse to connect or fail silently.

Fix: Remove the CNAME. Point the mail subdomain with a dedicated A record. Your MX record should point to something like mail.example.com, and mail.example.com must have an A record, not a CNAME.

Chained CNAMEs Causing Timeouts

Symptom: The hostname resolves in dig but is intermittently unreachable, or resolution takes noticeably longer than other hostnames.

Fix: Run dig +trace www.example.com and follow the chain. If you see three or more CNAME hops, collapse them. Either point your CNAME directly to the final canonical hostname, or replace intermediate CNAMEs with A records where you have control.

Forgetting to Remove an Old A Record Before Adding a CNAME

Symptom: The CNAME is saved, but the hostname still resolves to the old IP. Dig shows both records, which means the zone is invalid and behavior becomes unpredictable depending on which record the resolver picks up.

Fix: Delete the A record first, then add the CNAME. DNS does not allow a CNAME to coexist with any other record type for the same hostname.

A Quick Decision Framework

• Is the name your bare domain (example.com)? Use an A record (or ALIAS if available).
• Is the name a target of your MX or NS record? Use an A record.
• Are you pointing to a third-party service that gave you a hostname? Use a CNAME.
• Does the IP address behind the destination change regularly? Use a CNAME.
• Do you need multiple IPs for the same name? Use multiple A records.
• Is it a subdomain you fully control and the server IP is static? Either works, but an A record is simpler and has no extra lookup overhead.

How to Prevent Future Confusion

Document your DNS zone. Keep a simple spreadsheet or a comment in your infrastructure-as-code repository noting why each record exists, what it points to, and the date it was last updated. This sounds tedious but saves hours when you are debugging at 2am.

Use shorter TTLs (300-600 seconds) for records that are tied to third-party services or that you expect to change. Use longer TTLs (3600-86400 seconds) for stable A records to reduce resolver load and improve performance for your visitors.

Audit your DNS zone periodically. Look for orphaned CNAMEs pointing to decommissioned third-party accounts, a security risk known as subdomain takeover. If a CNAME target hostname is no longer claimed by you or your provider, an attacker can register it and serve content under your domain.

Understanding the distinction between A records and CNAMEs is one of those foundational DNS skills that pays dividends every time you configure a new service, migrate a server, or troubleshoot a broken deployment. Get these two right, and most of the common DNS headaches simply stop happening.