A Record vs CNAME: Differences and When to Use Each

An A record points a hostname straight to an IPv4 address. A CNAME record points a hostname to another hostname, and DNS follows that name to find the address. Use an A record when you know the server's IP and for your root domain. Use a CNAME for subdomains that should follow a name someone else maintains, such as www, shop or mail.

The rest of this guide covers the rules behind that answer, the mistakes that break sites and email, and what to do when you want CNAME behavior at the root of your domain.

TL;DR

• An A record maps a name to an IPv4 address. A CNAME maps a name to another name, so it works as an alias.
• A CNAME must be the only record at its hostname. You can't put an A, MX or TXT record beside it.
• Use an A record for the root (apex) domain. Use CNAMEs for subdomains that point to a service you don't control.
• If you need CNAME-like behavior at the root, look for an ALIAS, ANAME or CNAME flattening feature at your DNS provider.
• A CNAME doesn't need an A record on the same name, but the name it points to must resolve to an address somewhere.

Table of Contents

• What an A record does
• What a CNAME record does
• A record vs CNAME at a glance
• The rule that trips everyone up: a CNAME stands alone
• Can you have a CNAME without an A record?
• When to use a CNAME
• When to use an A record
• What to use at the root domain instead of a CNAME
• Worked example: a small business site
• Common mistakes and how to avoid them
• How to check what you have
• Our perspective
• Moving a site or setting up a new domain
• FAQ
• Sources

What an A record does

An A record (short for Address) is the most basic DNS record. It maps a hostname to an IPv4 address, and Google's DNS documentation describes it as mapping a name directly to an IP address. The same documentation notes that in an A record entry, the @ character stands for the zone apex (your bare domain), and the data field holds the numeric address.

A typical A record looks like this:

When a browser asks for example.com, the DNS resolver returns 203.0.113.10 and the browser connects to that server. There is one step, and you control the answer.

IPv6 has its own record, the AAAA record. It does the same job as an A record but holds an IPv6 address instead of an IPv4 one, according to DNS documentation. If your server has both address types, you publish both an A and an AAAA record at the same name.

What a CNAME record does

CNAME stands for Canonical Name. Instead of holding an IP address, it holds another domain name. Google's documentation describes a CNAME as pointing to another resource record and acting as an alias for it.

Here is an example:

When someone visits www.example.com, the resolver sees the CNAME, then looks up example.com, and returns whatever address that name has. A real-world pattern from the University of Illinois networking documentation shows exactly this: www.illinois.edu is a CNAME to illinois.edu, and illinois.edu has an A record pointing to 192.17.172.3.

The big benefit is maintenance. If the server's IP changes, you update one A record, and every CNAME that points to that name follows automatically. When the target belongs to a third party, like an online store, a help desk or an email service, they can move servers without asking you to touch your DNS.

A record vs CNAME at a glance

The rule that trips everyone up: a CNAME stands alone

The most common DNS error with CNAMEs is adding one at a name that already has other records. The standard is explicit. RFC 2181, published in July 1997, says a name with a CNAME can carry the DNSSEC-related SIG, NXT and KEY records but no other data. An A record can't coexist with a CNAME at the same hostname.

The University of Illinois documentation puts the logic the same way, quoting RFC 1034: when a CNAME is present at a node, no other data should be present. The idea is simple. A CNAME says "this name is really that name, so ask there for everything." If you also published an A record or an MX record at the alias, the resolver wouldn't know whether to believe the alias or the local data.

That has practical consequences:

• Root domains usually already have other records. Your bare domain nearly always carries NS and SOA records, and often MX records for email and TXT records for verification. That is why a standard CNAME can't go at the apex.
• Adding a CNAME can silently break email. If you put a CNAME at a name that has MX or TXT records, those records can stop working. SPF, DKIM and verification records are all TXT records, which is a reason to check the name first. Our guide to SPF and DKIM for small sites covers the email side in more detail.
• Your DNS panel may or may not stop you. Some control panels refuse the conflicting entry. Others accept it and let you find out when something stops working.

Can you have a CNAME without an A record?

Yes. A CNAME doesn't need an A record at the same name. In fact, it can't have one. What it needs is a target that eventually resolves to an address. As the Valimail explanation puts it, the CNAME can exist without an A record because the name it points to resolves to an IP itself.

So blog.example.com CNAME hosting-platform.net works with no A record for blog.example.com, as long as hosting-platform.net (or the next name down the chain) has an A or AAAA record.

One caution: chains. If a CNAME points to another CNAME that points to a third, every hop adds a lookup, and resolution slows down. Point your alias at the final hostname whenever you can.

When to use a CNAME

Use a CNAME when the destination is a name, not an address, and when the destination's owner may change addresses over time. Common cases:

1. www pointing at your main domain. The www name follows your root domain's A record, so you maintain the IP in one place.
2. Subdomains for outside services. A store, a booking tool, a support portal or a status page usually gives you a hostname to point at, not an IP.
3. Domain ownership verification. Services often ask you to publish a CNAME with a specific name and value to prove you control the domain. Google Workspace's documentation lists verifying domain ownership and customizing a web or service address among the uses of CNAME records.
4. Custom addresses for email tracking and links. Cold-email and marketing tools often ask you to set up a branded tracking subdomain with a CNAME. If that's your use case, this walkthrough on setting up a custom tracking domain shows the idea in practice.
5. Content delivery networks. A CDN typically gives you a hostname to alias your cdn or static subdomain to.

Before creating any CNAME, check that the name you are using has no other records. Then confirm the exact target hostname the service wants, including whether it ends with a dot in your DNS panel's format.

When to use an A record

Use an A record when you know the IP address and you control or have been assigned it:

• Your root domain. example.com should point to your hosting server's IPv4 address through an A record (plus an AAAA record if you have IPv6).
• A server you manage. If you run a VPS or dedicated server with a fixed IP, an A record points a subdomain like app.example.com right at it.
• A name that must also carry other records. Anything that needs MX, TXT or other records at the same name must use an A record (or no address record at all), since a CNAME would rule those out.
• Fewer lookups. An A record answers in one step, which is a small but real advantage on names that get heavy traffic.

If your site runs on one of our hosting plans, you'd normally point the root domain's A record at the server IP shown in your account and make www a CNAME to the root. Our DNS management explainer walks through where those values come from.

What to use at the root domain instead of a CNAME

This is where the "CNAME vs ALIAS" question comes from. Many hosted platforms give you a hostname, not an IP, and you want your bare domain to use it. A standard CNAME isn't allowed there, so DNS providers built workarounds.

ALIAS or ANAME records. According to Google Cloud's DNS documentation, an ALIAS (or ANAME) record is a non-standard DNS feature. It gives CNAME-like behavior at the zone apex: the DNS provider resolves the target's IP addresses itself and returns them to the client as A or AAAA records. The Internet Systems Consortium notes that some providers offer these records for the case where a third party gives you a target name rather than an IP address.

The resolver on the visitor's side sees an ordinary A record, so it doesn't conflict with the other records at the apex. The aliasing happens on the DNS provider's servers.

CNAME flattening. Some DNS providers let you enter a CNAME at the apex and then flatten it, returning the final address records when queried. The effect is similar to ALIAS, only the record is entered as a CNAME in the panel.

Two caveats before relying on either:

• They're provider-specific. ALIAS and ANAME aren't part of the DNS standards. The name, behavior and availability depend on who hosts your DNS. Check your provider's documentation before assuming you have one.
• DNSSEC can complicate them. Google Cloud's documentation says ALIAS records in its Cloud DNS service aren't compatible with DNSSEC. Other providers handle it differently, so if you sign your zone, confirm the combination is supported. Our article on what DNSSEC is and why it matters explains the background.

CNAME vs ALIAS in short

IBM's overview of the topic says ALIAS records generally perform better than CNAMEs because the target address is resolved internally, avoiding the extra lookup. The difference is small for most small sites, and portability matters more if you ever move DNS.

If your provider has no ALIAS option, the fallback is simple: ask the platform whether it publishes a fixed IP address, and use an A record. Or send visitors to a www subdomain with a CNAME and redirect the bare domain to it.

Worked example: a small business site

Suppose you run bluefinplumbing.com with a site on a hosting server at 203.0.113.10, a booking tool, and Google-hosted email. A clean set of records could look like this:

The addresses here are documentation examples, not real servers. The point is the pattern: address records where you own the server, CNAMEs for outside services, and nothing at all conflicting with @.

If you later move the site to a new server, you edit one A record. The www name follows. The booking tool is unaffected.

Common mistakes and how to avoid them

1. CNAME at the root. The most frequent error. Use an A record, or ALIAS or flattening if your provider supports it.
2. CNAME next to MX or TXT. This breaks email and verification at that name. List every record at the name before adding the alias.
3. Leaving an old A record behind. If you switch shop from an A record to a CNAME, delete the A record first, or your panel may reject the change or serve unpredictable results.
4. Long CNAME chains. Each hop is another lookup. Point to the final target.
5. Pointing a CNAME at an IP address. The value must be a hostname. If all you have is an IP, use an A record.
6. Forgetting TTL. Lower the TTL (the time records are cached) before a planned change, then raise it again afterward, so the move takes effect quickly. Our guide to changing nameservers without downtime shows how to plan for it.
7. Assuming changes are instant. DNS caching means some visitors see the old answer for a while. Test with a lookup tool, and wait for the TTL to pass before concluding something is broken.

How to check what you have

You don't need special software. From a terminal, dig example.com A shows A records for a name, and dig www.example.com CNAME shows its alias. On Windows, nslookup -type=CNAME www.example.com does the same. If a lookup for a name returns a CNAME, any A record you thought you had there is either not published or being ignored.

Before you add a CNAME, ask three questions: Is this the root domain? Does this name already have MX, TXT or A records? Does the service want a hostname or an IP? If the answers are no, no, hostname, a CNAME is the right tool.

Our perspective

Most DNS trouble we see for small sites isn't exotic. It's an alias placed on a name that already carries email records, or a root domain pointed the wrong way during a move.

Our view is that DNS should be something you can see and edit in one place, next to your domain and your hosting. When your domain registration, DNS records and hosting plan sit in the same dashboard, you can check what a name already holds before you add a CNAME, and you avoid the guesswork of three logins.

Our hosting is managed by SRE and DevOps engineers in the EU and US, and migrations to us are free. That matters for DNS because a move is exactly when records get misplaced. We'd rather help you map the A records and CNAMEs correctly than leave you to find out from a broken inbox.

Ihor

Moving a site or setting up a new domain

If you're setting up a new site or migrating one, you'll create these records anyway. Our domain registration with DNS management lets you manage A records, CNAMEs and the rest from your account. For the site itself, you can pick from shared hosting, WordPress hosting or a VPS when you want a dedicated IP and full control. Plans include free migration and a 30-day money-back guarantee.

Already own a domain elsewhere? You can transfer it to us and keep your records in one dashboard. For background on how DNS services work, our DNS hosting guide is a good next read.

FAQ

Can I have both a CNAME and an A record on the same name?

No. RFC 2181 allows a CNAME to coexist only with DNSSEC-related records, and no other data. If you need an A record at that name, remove the CNAME. If you want an alias, remove the A record.

Can you have a CNAME without an A record?

Yes, and that is the normal setup. The CNAME hands the lookup to another hostname, and that target must have an A or AAAA record somewhere along the chain. You don't publish one at the alias name itself.

When should I use a CNAME instead of an A record?

Use a CNAME for a subdomain that should follow another hostname, such as www following your root domain or help pointing at a support platform. Use an A record when you have a fixed IP, for your root domain, or whenever the name also needs MX or TXT records.

What is the difference between a CNAME and an ALIAS record?

A CNAME is a standard record that can't sit at the root domain. An ALIAS (sometimes called ANAME) is a provider-specific feature that works at the root by resolving the target on the server side and returning A or AAAA records. Availability and behavior depend on your DNS host.

Sources

• RFC 2181: Clarifications to the DNS Specification
• Stand-alone DNS Records, University of Illinois Networking Public
• DNS records overview, Google Cloud Documentation
• About CNAME records, Google Workspace Admin Help
• ISC Knowledgebase: ALIAS and ANAME records
• A Record vs. CNAME: What's the difference, Valimail
• CNAME vs ALIAS, IBM
• DNS records, Cloudflare Learning Center

Recommended

• DNS Management Explained: What Website Owners Must Know
• DNS Hosting Explained: Your 2026 Performance Guide
• Round Robin DNS: How It Works and When to Use It
• What Is a Subdomain and How Should You Use It?