← Back to Blog

It's one of the most common points of confusion in DNS: should you use an A record or a CNAME record? They both point a domain name somewhere, they're both fundamental to how DNS works, and they're often interchangeable in casual conversation. But they do different things, follow different rules, and choosing the wrong one can break your website, your email, or your SSL certificates.

The short version: an A record points a domain name to an IP address. A CNAME record points a domain name to another domain name. That distinction sounds simple, but the implications affect performance, maintainability, and what you're even allowed to configure.

This guide explains exactly what each record does, when to use which, the rules you cannot break, and the common mistakes that cause outages.

What an A Record Does

An A record (Address record) maps a domain name directly to an IPv4 address. It's the most fundamental DNS record type, the one that ultimately answers the question every DNS lookup is trying to resolve: what IP address should I connect to?

yourcompany.com.    300    IN    A    203.0.113.50

This says: when someone looks up yourcompany.com, return the IP address 203.0.113.50. The browser then connects directly to that IP.

The IPv6 equivalent is the AAAA record, which works identically but points to an IPv6 address:

yourcompany.com.    300    IN    AAAA    2001:db8::1

A records are direct and efficient. One DNS lookup returns the IP, and the connection proceeds. There's no intermediate step.

What a CNAME Record Does

A CNAME record (Canonical Name record) maps a domain name to another domain name, rather than to an IP address. It creates an alias.

www.yourcompany.com.    3600    IN    CNAME    yourcompany.com.

This says: www.yourcompany.com is an alias for yourcompany.com. When someone looks up www.yourcompany.com, the resolver sees the CNAME, then looks up yourcompany.com to find its actual IP address, and returns that.

CNAMEs are useful when you want a subdomain to always follow wherever another domain points, without having to update IP addresses in multiple places. A common example is pointing a subdomain to a third-party service:

shop.yourcompany.com.    3600    IN    CNAME    yourstore.myshopify.com.
status.yourcompany.com.  3600    IN    CNAME    yourcompany.statuspage.io.
blog.yourcompany.com.    3600    IN    CNAME    yourblog.ghost.io.

If Shopify, Statuspage, or Ghost change their underlying IP addresses, your CNAME automatically follows because it points to their hostname, not their IP. You never have to update anything.

The Key Difference: Indirection

The fundamental difference is indirection. An A record gives a direct answer (the IP). A CNAME gives a redirect to another name, which must then be resolved to eventually reach an IP.

Consider the resolution process:

A record lookup:

  1. Query yourcompany.com → returns 203.0.113.50
  2. Connect to 203.0.113.50

CNAME lookup:

  1. Query www.yourcompany.com → returns CNAME to yourcompany.com
  2. Query yourcompany.com → returns 203.0.113.50
  3. Connect to 203.0.113.50

The CNAME requires an extra resolution step. In practice, this adds minimal latency (resolvers often return the full chain in one response), but it's an important conceptual difference that drives the rules around when you can use each.

The Rules You Cannot Break

CNAMEs come with strict rules defined by the DNS specifications. Violating them causes unpredictable behavior or outright failures.

Rule 1: A CNAME Cannot Coexist With Other Records

If a name has a CNAME record, it cannot have any other record of any type. This is the most important and most commonly violated rule.

For example, this is invalid:

blog.yourcompany.com.  CNAME  yourblog.ghost.io.
blog.yourcompany.com.  TXT    "some verification string"   ← INVALID

You cannot have both a CNAME and a TXT record (or MX, or A, or anything else) at the same name. The reason: a CNAME means "this name is entirely an alias for another name." There's no room for additional records because the alias target's records take over completely.

This rule causes real problems. A common scenario: you point yourcompany.com to a service via CNAME, then try to add an SPF (TXT) record for email or a verification record. It fails because the CNAME already occupies that name.

Rule 2: No CNAME at the Zone Apex

The zone apex (also called the root or naked domain) is your bare domain without any subdomain: yourcompany.com rather than www.yourcompany.com.

You cannot place a CNAME at the zone apex. The reason is Rule 1: the zone apex must have SOA and NS records (they're mandatory for the zone to function), and since a CNAME can't coexist with other records, a CNAME at the apex would conflict with the required SOA and NS records.

This is why you can't simply CNAME yourcompany.com to a service like yourapp.herokuapp.com. The apex needs an A record.

Rule 3: CNAME Chains Are Allowed But Discouraged

A CNAME can point to another CNAME, creating a chain. This is technically valid but adds resolution steps, latency, and fragility. Each hop is another lookup and another potential point of failure. Keep CNAME chains short, ideally just one hop to the final target.

The Zone Apex Problem and Its Solutions

The inability to use a CNAME at the zone apex is a frequent frustration. You want yourcompany.com (not just www.yourcompany.com) to point to a service like a CDN, a static site host, or a SaaS platform, but those services give you a hostname, not an IP, and you can't CNAME the apex.

There are several solutions:

ALIAS / ANAME Records

Some DNS providers offer a special record type called ALIAS (or ANAME, or CNAME flattening). These records behave like a CNAME at the apex but are resolved by the DNS provider into A records before being served. From the outside, it looks like an A record (which is valid at the apex), but the provider automatically keeps it in sync with the target hostname's IP.

Cloudflare calls this "CNAME flattening." Route 53 calls it "Alias records." DNSimple, NS1, and others offer ALIAS or ANAME records. The implementation is provider-specific and not part of the DNS standard, so the exact behavior varies.

Provider-Specific Apex Support

Many modern hosting services and CDNs provide a set of static IP addresses specifically for apex domain A records, alongside the CNAME they recommend for subdomains. Check your service's DNS documentation for "apex domain" or "root domain" setup instructions.

Redirect the Apex to www

A simpler approach: use an A record (or ALIAS) at the apex that points to a lightweight redirect service, which sends visitors from yourcompany.com to www.yourcompany.com, where the CNAME does its job. Many registrars and DNS providers offer free URL redirect/forwarding for this.

When to Use an A Record

  • At the zone apex (yourcompany.com), where CNAMEs aren't allowed
  • When you control the IP address and it's stable (your own servers, a dedicated cloud instance with a static IP)
  • When you need the name to also have other records (MX, TXT, etc.), since A records can coexist with other types
  • When you want the fastest possible resolution with no indirection
  • For mail server hostnames (MX records must point to hostnames that resolve via A/AAAA, not CNAME)

When to Use a CNAME Record

  • For subdomains pointing to third-party services (Shopify, Ghost, Statuspage, GitHub Pages, Heroku, etc.), where the provider manages the underlying IPs
  • When the target's IP address might change and you don't want to track it
  • For the www subdomain pointing to your apex or CDN
  • When a service explicitly instructs you to use a CNAME for domain verification or routing
  • When you want one canonical name that multiple aliases can follow

Common Mistakes

Trying to CNAME the Apex

The most common mistake. You try to point yourcompany.com directly to a service hostname via CNAME, and it either fails or your DNS provider silently converts it (which can cause unexpected behavior). Use an ALIAS/ANAME record or your provider's apex support instead.

Adding a TXT Record to a Name That Has a CNAME

You have a CNAME for a subdomain, then try to add an SPF, DKIM, or domain verification TXT record at the same name. It fails because of Rule 1. The solution depends on your situation: you may need to move the service to a subdomain that doesn't need the TXT record, or use a different verification method.

Pointing MX Records to a CNAME

MX records must point to a hostname that has an A or AAAA record, not a CNAME. Pointing an MX record to a CNAME violates RFC 2181 and causes mail delivery issues with strict mail servers. Always point MX records to hostnames that resolve directly via A/AAAA records.

Long CNAME Chains

CNAME A → CNAME B → CNAME C → finally an IP. Each hop adds latency and fragility. If any link in the chain breaks or its provider has an outage, your domain breaks. Keep chains as short as possible.

Forgetting CNAMEs Inherit the Target's Behavior

When you CNAME to a third-party service, you inherit everything about how that service responds, including outages. If the service your CNAME points to goes down, your subdomain goes down with it. This is also a security consideration: if the service is decommissioned and you forget to remove the CNAME, you create a dangling DNS record vulnerable to subdomain takeover.

Quick Decision Guide

Situation Use
Bare domain (yourcompany.com) A record (or ALIAS/ANAME)
Subdomain to your own server with static IP A record
Subdomain to a third-party SaaS CNAME
www pointing to apex or CDN CNAME
Mail server hostname (MX target) A record (never CNAME)
Name that also needs TXT/MX records A record
Subdomain where target IP changes often CNAME

Check Your Records

Use the DNS lookup tool at dnsassistant.com/tools to see how your domain's A and CNAME records are configured. You can query specific record types and see the full resolution chain for any CNAME, including what it ultimately resolves to.

For a complete view of your DNS configuration, run a Free Domain Risk Report, which checks your records, email authentication, and TLS setup, and flags issues like dangling CNAMEs that point to decommissioned services.

For continuous monitoring of all your DNS records with alerts when A or CNAME values change, sign up at dnsassistant.com.

Start Monitoring Your DNS Today

Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.

Sign Up Free