A Record vs CNAME: Which DNS Record to Use for Your Site
An A record points a name to an IP address; a CNAME points it to another hostname. See the apex rule, a when-to-use table, and site builder examples.
Short answer: An A record maps a name directly to an IPv4 address, while a CNAME maps a name to another hostname and lets that hostname's records decide the final address. Use an A record for your root domain (example.com) and a CNAME for subdomains like www, shop, or blog when your host gives you a hostname instead of an IP. The key rule: a CNAME can't sit at the root of a domain.
What each record actually points to
A record: name to IP address
An A record answers the question "what is the IPv4 address for this name?" It looks like this in a zone file:
`` example.com. 3600 IN A 192.0.2.10 ``
That address (from a range reserved for documentation) is the server a browser connects to. If you have an IPv6 address too, you add an AAAA record alongside it. If the server's address changes, you have to edit the record yourself.
CNAME record: name to another name
A CNAME ("canonical name") says "this name is an alias for that other name." It never contains an IP address:
`` www.example.com. 3600 IN CNAME sites.hostingprovider.example. ``
A resolver sees the alias, looks up the target, and uses whatever A or AAAA records it finds there. The benefit is that your host can change its server addresses without you touching your DNS. For the basic definition, see what a CNAME is, and for the wider family of records see DNS record types explained.
The apex restriction, explained
The apex (also called the root, bare, or naked domain) is the name with nothing in front of it: example.com. The DNS rules say a name with a CNAME can't have any other record type next to it. The apex always has other records:
- NS records that say which servers are authoritative for the domain
- An SOA record
- Usually MX records for email and TXT records for verification and SPF
A CNAME at the apex would clash with all of these. Some DNS panels will refuse to save it. Others will save it and quietly break email delivery or domain verification, which is worse.
Subdomains don't have this problem, because www.example.com normally has no other records at that exact name. That's why hosts nearly always tell you to point www with a CNAME.
The workaround: ALIAS, ANAME, and flattening
Many DNS providers offer a non-standard record that acts like a CNAME at the apex. It goes by different names (ALIAS, ANAME, or "CNAME flattening"), and the provider resolves the target hostname on their side and answers visitors with plain A records. Because these are provider features, not part of the DNS standard, the name, the behavior, and whether they're included all vary. Check your DNS provider's documentation before relying on one, and never assume a record type of that name exists in a different provider's panel.
A record vs CNAME: when to use which
| Situation | Use | Why |
|---|---|---|
| Root domain (example.com), host gives an IP address | A (and AAAA if given IPv6) | Apex can hold A records |
| Root domain, host gives only a hostname | ALIAS/ANAME/flattening if your DNS provider has it; otherwise move DNS or use the host's nameservers | Standard CNAME isn't allowed at the apex |
| www subdomain, host gives a hostname | CNAME | Follows the host if its servers move |
| Subdomain, host gives an IP address | A | CNAME has nothing to point to |
| Subdomain for a SaaS tool (help, status, shop) | CNAME | Vendor manages the target |
| Name that also needs MX or TXT records | A, AAAA, or ALIAS-style, never CNAME | CNAME can't coexist with other records |
| Pointing a name at another name you control | CNAME | One place to update |
| Email service records (DKIM selectors) | CNAME only if the email provider instructs it | Provider-specific, follow their instructions |
For mail routing specifically, see how MX records work and what a TXT record does.
Examples for site builders
Most website builders and hosts fall into one of two patterns. Your dashboard shows which one applies to you.
Pattern 1: host gives you an IP and a hostname
Many hosts list both. The typical setup is:
| Host (name) | Type | Value |
|---|---|---|
| @ (root) | A | the IP address your host lists |
| www | CNAME | the hostname your host lists |
In most DNS panels, @ means the apex. Use exactly the values your host shows. Don't copy IP addresses from a blog post, including this one, because hosts change them.
Pattern 2: host gives only a hostname
Some platforms avoid fixed IPs. You then have three choices:
- Point www with a CNAME and redirect the root domain to www using your registrar's forwarding feature.
- Use an ALIAS/ANAME/flattening record at the apex if your DNS provider supports it.
- Switch your domain's nameservers to the host or to a DNS provider that supports apex aliasing.
Option 1 is the most portable, because every registrar can do a redirect, though it adds one hop for visitors on the bare domain.
Step-by-step: pointing a domain at a site builder
- Find your host's DNS instructions in the domain or custom-domain settings. Note whether it lists an IP, a hostname, or both.
- Open your DNS panel at the registrar or DNS provider (wherever your nameservers point).
- Delete conflicting records. Old A or CNAME records at the same name (often a registrar parking page) must go first.
- Add the apex record. Use an A record with the host's IP, or an ALIAS-style record with the host's hostname.
- Add the www record. Use a CNAME pointing to the hostname the host gave you.
- Leave MX and TXT records alone unless you're deliberately changing email.
- Wait for the TTL of your old records to expire, then check the domain in a browser. A lower TTL set a day before the change makes switches faster.
- Confirm the host shows the domain as connected and that HTTPS is issued. Hosts usually need DNS to resolve correctly before they can issue a certificate.
Quick troubleshooting checklist
- [ ] The same name doesn't have both a CNAME and another record
- [ ] No CNAME at the apex (unless it's a provider-specific ALIAS-style record)
- [ ] The CNAME target ends in a real hostname, not an http:// URL or a path
- [ ] The A record contains an IPv4 address and nothing else (no port, no https://)
- [ ] There's no stale AAAA record pointing at an old server
- [ ] Your nameservers are the ones where you actually edited records
- [ ] MX records are still in place if you use email on this domain
Common mistakes
- Putting a CNAME on the root to "fix" www. It breaks email and verification records instead. Use the A or ALIAS approach.
- Copying an old IP address. If a CNAME is available, it keeps you in step with the host. If you must use an A record, re-check the IP in your host's dashboard when something stops working.
- Pasting the URL as the target. DNS values are hostnames or IPs only, with no https:// and no trailing path.
- Forgetting AAAA. A leftover IPv6 record can send some visitors to a server you no longer use.
If you're still choosing a platform, We.Inc's free plan lets you publish up to three sites from ready-made templates; the AI builder that drafts a site from a prompt starts on the Starter plan at $20 a month. You can start free here and connect a domain using whichever record type the dashboard tells you to use.
Frequently asked questions
Can I put a CNAME on my root domain?
Under the standard DNS rules, no. A CNAME cannot share a name with any other record, and the root of a domain always carries NS and SOA records. Some DNS providers work around this with an ALIAS, ANAME, or CNAME-flattening feature that behaves like a CNAME but is answered with A records, so check your provider's docs for what they call it.
Is a CNAME or an A record faster?
For visitors, the difference is usually too small to notice. A CNAME adds one extra lookup the first time a resolver has to follow the alias, and after that the answer is cached according to the TTL. Pick based on what your host tells you to use and whether the name is the apex, not on speed.
Why does my host give me a CNAME for www but an IP address for the root domain?
Because www is a subdomain, where a CNAME is allowed, and the root domain is the apex, where it is not. Hosts that publish a fixed IP address for the apex are giving you something an A record can hold. Hosts that only give a hostname are expecting you to use a CNAME on a subdomain, or an ALIAS-style record at the apex if your DNS provider supports one.
Can an A record and a CNAME exist for the same name?
No. If a name has a CNAME, it cannot have an A record, MX record, TXT record, or any other record type. Your DNS panel may block you from saving the second record, or it may save it and cause unpredictable resolution. Delete the old record before adding the new type.
What happens to my email if I change the apex record?
Changing the A record at your root domain does not affect email, because mail routing is handled by MX records. Adding a CNAME at the apex is the dangerous move, since it conflicts with the MX and TXT records that email depends on. Keep MX records in place and only touch the A or AAAA records when you move a website.
More in Blog
- Accountant & CPA Website Design: Template and Examples
- How to Add a User to Google Search Console (Step by Step)
- How to Add a Website Builder to Your SaaS Platform
- How Bright Digital Agency Built and Resold 22 Client Sites With We.Inc White-Label
- 88% of Companies Hit by AI Agent Security Breaches. What That Means for Your Website.
- AI Assistant for Business: How to Automate Support, Sales, and Lead Generation
- AI Content Creation: A Practical Workflow for Web Content
- How to Implement AI Customer Service, Step by Step
Related guides and tools
Start building
- how to make a website
- AI website builder
- free website builder
- website templates
- website builders by industry
How we research, test and update this page: our editorial policy. We.Inc is our own product.
Product
Who It's For
- For Agencies
- For Freelancers
- For Hosting Providers
- For SaaS Platforms
- For Startups
- For Financial Services
- For Healthcare
Features
Resources
- Blog
- Help Center
- Free Business Tools
- Free UI Components
- Website Templates
- Template Collections
- Website Examples
- Guides
- Comparisons
- Alternatives
- Best Lists
- Reviews
- Pricing Guides
- Use Cases
- Glossary & Guides
- Integrations
- Developers
- Benchmark
- Windows App