CNAME vs A Record: Which to Use and the Apex Rule

What an A record and a CNAME actually do

Both records answer the same question — “where does this name point?” — but they answer it with different kinds of information, and that single difference explains every rule that follows.

An A record maps a name directly to an IPv4 address. example.com → 203.0.113.10. It is the end of the chain: the resolver has what it needs and stops. (The IPv6 equivalent is an AAAA record, and everything in this guide applies to it identically.)

A CNAME record maps a name to another name. www.example.com → example.com, or shop.example.com → myshop.myprovider.net. The resolver does not get an address; it gets a second name it must now look up. CNAME is short for “canonical name”, and the record is best read as a sentence: the real name for this is over there, go ask about that instead.

That redirection is the whole point. If the thing you are pointing at ever changes its IP address, a CNAME keeps working without you touching anything, because you never wrote the address down.

The difference that actually matters

In practice the choice comes down to one question: who owns the address?

• You own it — a server, a VPS, a load balancer with a static IP you control. Use an A record. You know the address, it will not change without you knowing, and a direct answer is the fastest answer.
• Someone else owns it — a hosting platform, a CDN, a shop builder, a form or status-page service. Use a CNAME. Their addresses change, often silently and without notice, and a CNAME means their change is not your outage.

This is why every platform's setup page tells you to create a CNAME rather than giving you an IP. It is not a convention — it is them reserving the right to move. Hardcode their current IP in an A record and you have quietly opted out of their maintenance window.

There is one more structural difference, and it trips people up: a name that has a CNAME can have no other records. The standard is explicit about this. If www.example.com is a CNAME, it cannot also carry a TXT record, an MX record or an A record. Most DNS providers refuse to save the second record, but some accept it and simply behave unpredictably — which is a very unpleasant way to spend an afternoon.

Why the apex cannot be a CNAME

The apex — also called the root, the zone apex or the naked domain — is example.com with nothing in front of it. And it is the one name in your zone that cannot be a CNAME. This is not a limitation your provider invented; it follows from the rule above.

Your apex already carries records that must exist for the domain to work at all: the NS records naming your authoritative nameservers, and the SOA record describing the zone. Those live at the apex by definition. Since a CNAME forbids every other record on the same name, and the apex is required to hold NS and SOA, a CNAME at the apex is a contradiction. A standards-compliant DNS server will not serve it.

This has a practical consequence people discover at the worst moment. Your MX records also live at the apex. If a provider ever lets you force a CNAME there, you have not just pointed your website — you have put your email in an undefined state, because the name now claims a canonical name somewhere else while also needing to answer MX queries.

What to put at the apex instead

There are four workable answers, in roughly the order you should prefer them.

Use your provider's alias record

Most modern DNS providers offer a record type that behaves like a CNAME but is legal at the apex: ALIAS, ANAME, or Cloudflare's CNAME flattening. The names differ, the mechanism is the same — the nameserver resolves the target itself and answers the query with the resulting A record. The outside world sees a perfectly ordinary A record, so no rule is broken, and you still never wrote down an IP.

This is the right answer whenever your DNS provider offers it. The catch is that it is a feature of your provider, not of DNS: move your zone somewhere that does not support it and the record does not come with you.

Redirect the apex to www

Put the real site on www as a CNAME — entirely legal — and make the apex a redirect to it. Many registrars and all CDNs offer this as a one-line setting, usually called domain forwarding or a redirect rule. You get a clean CNAME where it counts and one canonical hostname, which is good for SEO anyway.

The trade-off is cosmetic: your visible URL has a www. in it, and some people have strong feelings about that.

Use an A record, knowingly

If the platform publishes a static IP address and commits to it in writing, an A record at the apex is fine. The word doing the work is “commits”. An IP you found by pinging their CNAME target is not a commitment, it is a snapshot, and it will change.

If you do this, lower the record's TTL before any planned migration so you are not stuck waiting on caches when the address does move.

Check what you actually have

Before changing anything, look at the current state of the zone rather than trusting the control panel's summary. Query the apex and the www name separately and compare: you are looking for whether each answers with an A record or a CNAME, and whether anything unexpected is already there. A free DNS lookup tool shows the record type, the value and the remaining TTL for each one.

When a CNAME is the right choice

Reach for a CNAME whenever the target is a name you do not control:

• Subdomains pointing at a platform — shop, docs, status, blog, help pointing at a hosted service. This is the single most common correct use.
• A CDN in front of your origin, where the CDN hands you a hostname like d1234.cloudfront.net.
• Domain-verification and service records that a vendor asks you to create with a CNAME, often with a long random label.
• Keeping www in step with the apex, so one change updates both.

In all four cases the value is the same: the vendor can change infrastructure and your DNS keeps working untouched.

When an A record is the right choice

An A record is correct when you hold the address:

• Your own server or VPS with a static IP.
• The apex, when no alias record is available and the platform publishes a stable IP.
• A load balancer that your provider gives you as an address rather than a hostname.
• Infrastructure hosts — a mail server named in an MX record, for instance, must resolve via A or AAAA. An MX record is not allowed to point at a CNAME, and mail servers will reject it.

That last one catches people migrating email. mail.example.com as a CNAME looks harmless and breaks delivery in ways that are tedious to diagnose.

The extra lookup, and the second TTL

A CNAME costs one more step. The resolver asks for your name, gets back “ask about this other name”, and asks again. In practice the extra round trip is a few milliseconds and nearly always cached, so this is not a reason to avoid CNAMEs — but two consequences are worth knowing.

First, a CNAME chain pointing at another CNAME pointing at another CNAME adds a step each time. Two links is normal; a long chain is a latency problem and a fragile dependency, since any link breaking takes your name down.

Second, a CNAME brings a second TTL with it. The resolver caches your CNAME with your TTL, and caches the target's record with the target's TTL, counting down separately. Your real wait when something changes is the longer of the two, which is why a CNAME pointing at a provider with a long TTL can lag behind your own setting no matter how low you set it. If you are planning a change, how TTL and propagation actually work covers the sequence that avoids downtime.

Common mistakes

• Forcing a CNAME at the apex because a provider's UI allowed it. It puts your MX records — your email — into undefined behaviour.
• Adding a TXT or MX record to a name that already has a CNAME. Not legal, and providers disagree about how to fail.
• Copying a platform's current IP into an A record instead of using the CNAME they asked for. It works until the day it doesn't, and you will not be told.
• Pointing an MX record at a CNAME. Receiving mail servers reject it; use a name with an A record.
• Setting up www and forgetting the apex, or the reverse. Decide which one is canonical, point the other at it, and keep certificates covering both.
• Changing record type and value at once without lowering the TTL first, then wondering why half the world still sees the old target.

The short version

Use an A record when you own the IP address; use a CNAME when you are pointing at somebody else's hostname and want their infrastructure changes to be invisible to you. Your apex cannot be a CNAME, because it must hold NS and SOA records and a CNAME forbids company on the same name — so use your provider's ALIAS, ANAME or CNAME flattening there, redirect the apex to www, or use an A record only when the platform publishes a stable address. Check what a domain resolves to today, including the record type and the remaining TTL, with the free DNS lookup tool, and confirm the certificate on the new host with the SSL certificate checker.

Related tools and guides:

• DNS Lookup - Query A, AAAA, MX, TXT, NS and more DNS records with values and TTL, plus reverse DNS.
• SSL Certificate Checker - Check any domain's SSL certificate, issuer, expiry date, and days remaining.
• Why DNS Changes Take Time: TTL and Propagation Explained - A DNS change is not slow, it is cached

Frequently Asked Questions