A Record vs CNAME: When to Use Each for Your Website

Overview

Here is the short version: an A record points a hostname directly to an IPv4 address, while a CNAME record points one hostname to another hostname. That sounds simple, but the right choice depends on what you are connecting, where the record lives, and whether the target might change over time.

Think of it this way:

• Use an A record when you know the server IP address and want a domain or subdomain to resolve directly to it.
• Use a CNAME when the provider tells you to point one hostname to another hostname they control.

Examples help:

• example.com -> 203.0.113.10 uses an A record.
• www.example.com -> app.hostingplatform.com uses a CNAME.

In most real setups, both record types appear together. A common pattern is:

• The root domain or apex domain such as example.com uses A records.
• The www subdomain such as www.example.com uses a CNAME.

This pattern exists because the root domain has stricter DNS rules in many DNS providers, while subdomains are more flexible. Some managed DNS services offer special features such as ALIAS, ANAME, or flattened CNAME behavior at the root. Those features can be useful, but they are provider-specific. If you want portable, easy-to-understand DNS, start by assuming:

• Root domain: use A record unless your provider explicitly supports a safe root-domain alias method.
• Subdomain: use CNAME when your service gives you a hostname target.

If you need a broader walkthrough for connecting your domain to a hosting provider, website builder, or server, see How to Point a Domain to Your Hosting Provider, Website Builder, or Server.

A record in plain English

An A record maps a name to a server IP address. If your hosting company, VPS, load balancer, or reverse proxy gives you a fixed IPv4 address, the A record is usually the right fit.

Use cases include:

• Pointing your root domain to a web server
• Pointing a subdomain to a specific server IP
• Keeping direct control of where traffic resolves

The tradeoff is maintenance. If the destination IP changes, you have to update DNS yourself.

CNAME in plain English

A CNAME makes one hostname an alias of another hostname. You do not point to an IP directly. Instead, you point to a canonical name controlled by your provider.

Use cases include:

• Connecting a subdomain to a SaaS platform
• Pointing www to another hostname
• Using a service where the underlying IPs may change without notice

The advantage is flexibility. If the service changes its infrastructure, the provider updates their DNS target and your CNAME keeps following it.

The one rule that trips people up

A hostname with a CNAME generally should not have other record types attached to it. In practical terms, if blog.example.com is a CNAME, do not also add A, AAAA, MX, or TXT records to that exact same hostname unless your DNS provider documents a special exception. This is one of the easiest ways to create hard-to-diagnose DNS problems.

Checklist by scenario

Use this section as your decision checklist before adding or editing records. Start with the scenario that matches your setup.

Scenario 1: You are pointing the root domain to a web server

Typical example: example.com should load your site.

Usually use: A record

Checklist:

• Confirm the exact IPv4 address from your hosting provider or server dashboard.
• Create or update the A record for @ or the blank host field, depending on your DNS interface.
• If your host also provides IPv6, add an AAAA record separately if needed.
• Make sure there is not a conflicting CNAME at the root.
• Verify whether your provider recommends redirecting www to root or the other way around.

Why this is usually correct: the root domain often needs to point directly to infrastructure, and the simplest portable method is an A record.

Scenario 2: You are connecting the www version of your site

Typical example: www.example.com should load the same site as example.com.

Usually use: CNAME

Checklist:

• Check whether your host wants www to point to their hostname, such as sites.provider.net.
• Create a CNAME for www to the target hostname.
• Decide which version is canonical for redirects: root to www or www to root.
• Confirm SSL covers both hostnames.
• Test both versions after propagation.

Why this is usually correct: www is a subdomain, and CNAME is clean and flexible for subdomains.

Scenario 3: You are connecting a subdomain to a SaaS product

Typical example: app.example.com, help.example.com, or shop.example.com should point to a hosted platform.

Usually use: CNAME

Checklist:

• Copy the target exactly as provided by the platform.
• Create the CNAME only for that subdomain.
• Do not place A or TXT records on the same hostname unless the provider explicitly asks for them and the DNS rules allow it.
• If the platform needs ownership verification, add the verification TXT record to the hostname they specify, which may be different.
• Wait for propagation and finish domain verification inside the SaaS dashboard.

Why this is usually correct: SaaS platforms often move traffic behind the scenes. A CNAME lets them manage infrastructure changes without asking you to chase new IP addresses.

Scenario 4: You have a server with a stable IP and want a subdomain to point directly to it

Typical example: api.example.com should resolve to your VPS or reverse proxy.

Usually use: A record

Checklist:

• Confirm that the IP is static or at least unlikely to change unexpectedly.
• Create the A record for the subdomain.
• If you expect future load balancing or managed routing, note that you may later replace this with a different pattern.
• Check firewall, web server virtual host, and SSL configuration after DNS resolves correctly.

Why this is usually correct: direct server control usually means direct IP pointing.

Scenario 5: Your DNS provider supports root-domain aliasing features

Typical example: your platform tells you to point the root domain to a hostname instead of an IP.

Usually use: provider-specific alias feature, not a normal CNAME

Checklist:

• Read your DNS provider's documentation for ALIAS, ANAME, flattened CNAME, or similar features.
• Confirm that the feature is supported at the root domain.
• Make sure you understand whether it behaves like a CNAME at the DNS layer or only as a provider-side convenience.
• Document the setup so future changes are not confusing.

Why this matters: many people search for a root domain CNAME solution, but a standard CNAME at the apex is often not the right answer.

Scenario 6: You are migrating hosting and want to minimize confusion

Usually use: whatever the new platform requires, but simplify first

Checklist:

• List existing A, AAAA, CNAME, MX, TXT, and redirect rules before changing anything.
• Identify which records are for the website and which are for email or verification.
• Change only the web-related hostnames first.
• Leave email records untouched unless the mail provider is also changing.
• Lower TTL in advance if your provider allows it and you are planning a timed cutover.

If your move includes a registrar change, review How to Transfer a Domain Name Without Breaking Your Website or Email. If you are troubleshooting delays, see DNS Propagation Time Guide: How Long Changes Take and How to Check.

What to double-check

Before you click save, verify these details. Most DNS mistakes are small typing or logic errors, not deep technical failures.

1. Are you editing the right zone?

If DNS is hosted somewhere different from your registrar, changes must be made where the active nameservers point. This is a common nameservers vs DNS confusion. If the nameservers are delegated to a DNS service, editing records at the registrar may do nothing.

2. Are you working on the right hostname?

example.com, www.example.com, and blog.example.com are different DNS names. Check whether the provider wants the root domain, a specific subdomain, or both.

3. Is the target an IP address or a hostname?

This is the fastest way to decide:

• If the target looks like 192.0.2.10, you probably need an A record.
• If the target looks like service.vendor.net, you probably need a CNAME for a subdomain.

4. Are there conflicting records?

If a hostname already has a CNAME, avoid adding other records to that same hostname. If it already has an A record, confirm whether it should be replaced or kept. Duplicate or conflicting entries create unpredictable results across dashboards and caches.

5. Did you preserve email records?

Website DNS changes should not casually overwrite MX, SPF, DKIM, or DMARC records. If email uses the same domain, leave mail-related records alone unless you intend to reconfigure email hosting. For that workflow, see How to Set Up MX, SPF, DKIM, and DMARC for a Custom Domain Email and Best Email Hosting for Custom Domains Compared.

6. Is TTL reasonable?

TTL controls how long resolvers may cache a record. Shorter TTLs can help before a planned change, but they do not guarantee instant propagation everywhere. Use a moderate TTL unless you have a specific reason to change it.

7. Did you plan redirects and canonical URLs?

DNS gets traffic to the right place, but it does not decide your preferred URL version. Your hosting or application should redirect visitors consistently between root and www, and SSL should cover every public hostname in use.

8. Does your hosting match the setup you are trying to build?

Sometimes the DNS record is not the real problem. A shared host, VPS, cloud instance, or website builder may require a different connection method. If you are still choosing infrastructure, these guides can help: Best Web Hosting for Beginners Compared and Shared Hosting vs VPS vs Cloud Hosting: Which One Should You Choose?.

Common mistakes

This is the section to review when a setup should work in theory but does not work in practice.

Using a CNAME at the root without understanding provider behavior

Many platforms tell you to point your domain to a hostname. That works well for subdomains, but the root domain is special. If your DNS provider supports a root alias feature, use that feature as documented. If not, ask the platform whether they also provide A records for the apex.

Pointing the wrong hostname

People often update www and expect the root domain to change, or they update the root and forget that visitors mainly use www. Always list the public hostnames you want working before you start.

Keeping stale records after a migration

Leftover A or CNAME records from a previous host can create split behavior during cutovers. Remove records you no longer need, but only after confirming they are not tied to email, verification, or another service.

Changing DNS and email at the same time without a record inventory

Website and email often share the same DNS zone. A rushed cleanup can remove MX or SPF records and cause mail delivery issues. Make a simple inventory first.

Confusing DNS success with application readiness

Even if DNS resolves correctly, the site may still fail because the web server, SSL certificate, virtual host, or application routing is incomplete. DNS is one layer in the launch chain, not the whole chain.

Ignoring propagation and local cache

After a change, one network may show the new destination while another still shows the old one. Browser cache, operating system cache, recursive resolvers, and upstream TTL behavior can all make changes appear inconsistent for a while.

Following generic tutorials instead of provider instructions

The most reliable DNS answer is often the one your hosting platform or SaaS provider gives for your exact hostname. Use general rules to understand what you are doing, but copy provider-supplied targets exactly.

When to revisit

This topic is worth revisiting any time your website stack changes. The right record today may not be the right record after a migration, redesign, replatform, or email move. Use this short action list whenever you are about to touch DNS.

Revisit your A record vs CNAME decision when:

• You move the site to a new hosting provider or server
• You connect a new website builder, CDN, proxy, or SaaS tool
• You add or remove a www version
• You launch a new subdomain such as blog, shop, or api
• Your provider changes onboarding instructions or verification flow
• You switch DNS providers and gain or lose root-alias features
• You troubleshoot propagation, SSL, or redirect issues
• You do seasonal planning or a pre-launch audit

A reusable pre-change checklist

1. Write down the hostname you are changing.
2. Write down the destination exactly as provided: IP or hostname.
3. Choose A for direct IP targets; choose CNAME for hostname targets on subdomains.
4. Check whether the record is at the root domain or a subdomain.
5. Inspect the existing records for conflicts.
6. Preserve mail and verification records.
7. Save a screenshot or export of the current DNS zone before editing.
8. Make the change in the active DNS provider, not just the registrar.
9. Test resolution, site loading, redirects, and SSL after propagation.
10. Document why the record was set that way for future you.

If you want a simple rule to remember, use this one: IP address means A record; provider hostname means CNAME, usually on a subdomain. Then pause and check whether you are dealing with the root domain, because that is where most exceptions and provider-specific behaviors appear.

For adjacent planning, you may also want to review How to Choose a Domain Name for SEO, Branding, and Trust and Domain Privacy Protection Explained: Is WHOIS Privacy Worth It?. They will not change your DNS records, but they do help you make cleaner decisions around the domain itself.

The goal is not to memorize every DNS rule. It is to build a reliable habit: identify the hostname, identify the target, choose the record type that matches the target, and double-check for conflicts before you publish changes. That habit solves most A record vs CNAME questions before they become downtime.