CNAME vs A record: what's the difference?

An A record maps a hostname directly to an IPv4 address, while a CNAME record maps a hostname to another hostname — an alias that the resolver follows to find the real address. Reach for an A record when you have an IP to point at (and always at the root domain); reach for a CNAME when you want a name to inherit whatever address another name resolves to.

Quick Takeaways

• An A record answers "what IP is this name?" with an IPv4 address; a CNAME answers "what other name should I look up instead?"
• A CNAME cannot coexist with any other record at the same name, so you cannot use one at the root domain (the apex), which already holds NS and SOA records.
• Use an A record for the apex (example.com) and for hosts whose IP you control; use a CNAME to point a subdomain at a provider's hostname.
• CNAMEs shield you from IP changes: if the target's address changes, your alias follows automatically with no edit.
• Never point an MX record at a CNAME — the mail standard requires MX to reference a name with A/AAAA records.
• DKIM is commonly set up as a CNAME so your provider can rotate signing keys without you touching DNS.

| | A record | CNAME record | |---|---|---| | Points to | An IPv4 address (e.g. 203.0.113.10) | Another hostname (e.g. app.provider.net) | | Resolves in | One lookup | An extra lookup to follow the alias | | Allowed at apex | Yes | No — apex already has NS/SOA | | Coexists with other records | Yes (MX, TXT, etc.) | No — must be the only record at that name | | Best for | Hosts whose IP you manage; the root domain | Subdomains aliased to a provider's hostname |

What is an A record?

An A record ("address" record) maps a hostname to a single IPv4 address — the 32-bit, dotted-quad numbers like 203.0.113.10. When a resolver looks up example.com and finds an A record, it has the final answer in one step and can connect. Its IPv6 counterpart is the AAAA record, which does the same job for 128-bit addresses.

Because an A record is a direct address, it is the only correct choice at the zone apex — the bare root domain with no subdomain in front. It also coexists happily with other record types at the same name, so example.com can hold an A record, an MX record, and TXT records for SPF and DMARC all at once.

What is a CNAME record?

A CNAME (Canonical Name) record does not contain an address at all — it points one hostname at another, canonical hostname. When a resolver hits a CNAME for www.example.com pointing to example.com, it stops, restarts the lookup on the target name, and follows that name's A record to the address. The alias inherits whatever the target resolves to.

The defining constraint is that a CNAME must be the only record at its name. DNS forbids a CNAME from coexisting with any other record type for the same host, because the alias replaces the whole name — there is nowhere to attach a second record. That single rule explains most of the practical differences between the two record types, including why a CNAME can never live at the apex.

CNAME vs A record: what's the actual difference?

The core difference is what the record returns: an A record returns an address, a CNAME returns a pointer to another name. That leads to three practical distinctions.

Lookups. An A record resolves in one step; a CNAME adds a hop, because the resolver has to chase the alias and then look up the target's address. The extra hop is usually negligible, but chaining many CNAMEs together compounds it.

Placement. An A record can sit anywhere, including the root domain. A CNAME cannot sit at the apex, and cannot share a name with an MX, TXT, or any other record — a hard rule, not a preference.

Maintenance. An A record hard-codes an IP, so if that IP changes you must edit DNS. A CNAME points at a name, so when the target's IP changes, your alias follows automatically. That is exactly why hosting and email providers hand you CNAMEs to publish.

When should you use an A record vs a CNAME?

Choose based on what you are pointing at and where.

• Use an A record when you control the server and know its IP, and always at the root domain — example.com must resolve via A (or AAAA), never a CNAME.
• Use a CNAME when you are pointing a subdomain at a service whose IP you do not manage: www aliased to your apex, shop aliased to a storefront host, or a vendor subdomain aliased to something.provider.net. If the provider re-numbers, you never have to notice.
• Prefer a CNAME for provider-managed names specifically so key rotation and IP changes stay the provider's problem rather than yours.

Many DNS hosts offer a flattening feature — sometimes called ALIAS or ANAME — that behaves like a CNAME but is legal at the apex, resolving the target to an address behind the scenes. It is the standard escape hatch when you want apex aliasing without breaking the coexistence rule.

How do A records and CNAMEs affect email?

DNS record choice has two email-specific consequences worth memorizing.

First, never point an MX record at a CNAME. The mail standard requires an MX host to be a name that resolves via A or AAAA records directly. If your MX target is itself a CNAME, some sending servers will reject or mishandle the route, causing intermittent delivery failures that are painful to diagnose. Point MX at a real hostname with an A/AAAA record.

Second, DKIM is often deployed as a CNAME. Providers such as Google Workspace and many email platforms ask you to publish CNAMEs like selector._domainkey.example.com pointing to a host they control, so they can rotate signing keys without you editing DNS every time. By contrast, SPF and DMARC always live in TXT records at fixed names, and because those TXT records sit at the apex or at _dmarc, the coexistence rule is why you cannot CNAME those names elsewhere. If your authentication is misconfigured, Palisade's Email Security Score shows which records resolve and which are missing before deliverability suffers.

Common mistakes with A records and CNAMEs

The most frequent error is trying to put a CNAME at the root domain to alias it to another host. Every registrar rejects it, because the apex already carries NS and SOA records and a CNAME demands exclusive ownership of the name. Use an A record or your host's ALIAS/flattening feature instead.

A close second is aliasing a name that already holds other records — pointing a CNAME at a subdomain that also needs a TXT or MX record. Only one can exist. And watch for CNAME chains: pointing an alias at another alias works but multiplies lookups and can trip resolvers that cap chain depth. When in doubt, point the alias straight at the final canonical name.

Frequently asked questions

Can I use a CNAME at my root domain?

No. The apex already holds NS and SOA records, and a CNAME must be the only record at its name, so the two conflict. Use an A record, or an ALIAS/ANAME/flattening feature if your DNS host offers apex aliasing.

Is a CNAME slower than an A record?

Marginally. A CNAME adds one resolution hop to look up the target's address, but the difference is usually imperceptible. It only becomes noticeable if you chain several CNAMEs together.

Can a CNAME and an MX record share the same name?

No. A CNAME cannot coexist with any other record type, MX included. Separately, an MX record's target should point to a hostname that has A/AAAA records, not to a CNAME.

What is the difference between a CNAME and a PTR record?

A CNAME aliases one name to another in forward DNS; a PTR record maps an IP address back to a hostname in reverse DNS. They operate in opposite directions and serve different purposes.

Related reading

• What is an A record?
• What is a CNAME record?
• What is a PTR record?