AI AI Tools Guidebook
Troubleshooting

A vs CNAME Confusion: Which DNS Record Do I Use?

Your host says A, a tutorial says CNAME, and the apex won't resolve or email broke. A web-verified cheat sheet for apex vs www vs subdomains (Vercel, Netlify, GitHub Pages, Cloudflare).

Published: Updated: Author: AI Productivity Guide Team 🌐 查看中文版本

You’re setting up DNS for a new domain. Vercel’s docs say “add an A record.” A YouTube tutorial says “use CNAME.” You tried CNAME at the apex (the bare root, example.com) and your DNS provider rejected it, or it accepted it and then MX email stopped delivering.

Fastest fix: at the apex use an A record (or an ALIAS/ANAME/CNAME-flattening option if your provider has one); at subdomains like www use a CNAME. There is one hard rule behind all of this, from RFC 1912 §2.4: a CNAME cannot coexist with any other record at the same name. The apex always carries other records (SOA, NS, usually MX), so a CNAME there is illegal and breaks those records. Subdomains usually carry nothing else, so CNAME is fine there. When in doubt, trust your hosting platform’s own dashboard values over any generic tutorial.

Which bucket are you in?

Your situationWhat to use
Apex / root (example.com, @)A record to the platform IP. Use ALIAS/ANAME or Cloudflare CNAME-flattening only if you need to track a rotating target.
www or any other subdomainCNAME to the platform’s *.vercel-dns.com / *.netlify.app / *.pages.dev / username.github.io target.
Provider rejected “CNAME at apex”Switch the apex to A (or ALIAS).
Email broke after adding the recordYou put a CNAME at the apex and it wiped MX. Replace it with A.
Site loads sometimes old, sometimes newYou have both A and CNAME (or stale + new) at the same name. Delete the wrong one.

Common causes

Ordered by hit rate, highest first.

1. Tried to use CNAME at the apex

RFC 1912 §2.4 forbids a CNAME at the zone apex because the apex must hold SOA and NS records (and often MX), and a CNAME cannot share a name with anything else. Your provider rejects it with something like CNAME records cannot coexist, CNAME conflicts with NS, or silently accepts it and email stops flowing.

How to spot it: the DNS provider error mentions “CNAME and apex,” “CNAME flattening required,” or you have a CNAME at the root and MX records suddenly don’t resolve.

2. Followed two different documentation sources

One source says A, another says CNAME. You configured both for the same name. The DNS provider may reject the second one or accept it silently with unpredictable resolution.

How to spot it: the DNS panel shows two records at the same name. It should be one or the other, never both.

3. Used an A record where a CNAME was needed

For subdomains, hosts like Vercel (www) and Netlify hand you a CNAME target that resolves to load-balanced, rotating IPs. If you hardcode an A record to a single IP, you’ll point at a stale server the day the host rotates its fleet.

How to spot it: host docs say CNAME cname.vercel-dns-0.com but you set A 76.x.x.x. The site works today and breaks weeks later for no obvious reason.

4. Used a CNAME where an A was needed

Vercel’s apex requires A 76.76.21.21, not a CNAME. Some platforms accept ALIAS/ANAME (or CNAME flattening) as a CNAME-like option at the apex. If your DNS provider doesn’t offer one of those, you must use A.

How to spot it: your DNS provider has no apex-CNAME option, you set a CNAME at the apex anyway, and the platform refuses to issue an SSL certificate or shows Invalid Configuration / DNS verification failed.

5. Mixed records during a migration

You moved hosts. The old A record is still there and a new CNAME points elsewhere. Resolvers round-robin between them or pick one inconsistently.

How to spot it: two records at the same name pointing to different places; the site sometimes loads the new deployment, sometimes the old one.

6. Used ANAME/ALIAS but the provider implements it as a real CNAME

ANAME and ALIAS are non-standard extensions that mimic apex-CNAME behavior by resolving the target to an A/AAAA answer at query time. Some providers implement them correctly; a few map ANAME to a literal CNAME under the hood, which then breaks MX.

How to spot it: check the provider’s ANAME compatibility note. Add an MX record as a test; if it disappears or throws a conflict, your ANAME is really a CNAME.

Shortest path to fix

Step 1: Check what your hosting platform requires

These are the official values as of June 2026. Always confirm against the values your own dashboard shows, since some platforms hand out project-specific targets.

PlatformApex (@)www / subdomain
VercelA 76.76.21.21 (or move nameservers to Vercel)CNAME cname.vercel-dns-0.com (or the project-specific target your dashboard shows)
NetlifyA 75.2.60.5, or ALIAS/ANAME to apex-loadbalancer.netlify.comCNAME yoursite.netlify.app
Cloudflare PagesCloudflare nameservers; CNAME yoursite.pages.dev at @ (auto-flattened)CNAME yoursite.pages.dev
Firebase Hostingthe two A records shown in the consolethe CNAME shown in the console
GitHub PagesA 185.199.108.153, 185.199.109.153, 185.199.110.153, 185.199.111.153CNAME username.github.io
AWS (S3 + CloudFront)A-ALIAS to the CloudFront distribution (Route 53)CNAME to the CloudFront domain

Use the exact values from your platform’s docs or dashboard.

Step 2: For the apex, use A or ALIAS/ANAME (or move nameservers)

If your DNS provider supports ALIAS/ANAME (Route 53, Cloudflare, DNS Made Easy, Namecheap, Porkbun), you can use it at the apex to follow a CNAME-like target. Otherwise use an A record with the platform IP.

  • Cloudflare: just put a CNAME at @. Cloudflare applies CNAME flattening automatically on every plan (including Free) when the record name is @, resolves the chain to an A/AAAA, and returns that, staying RFC-compliant so MX keeps working.
  • Vercel / Netlify / Firebase: the cleanest path is to delegate the whole domain to the platform’s nameservers, after which the platform manages the apex A records for you. If you keep external DNS, use the A value above.

Step 3: For subdomains, use CNAME

www, blog.yourdomain.com, staging.yourdomain.com should all be a CNAME to the platform’s target. Never put an apex IP in an A record for a subdomain that the host load-balances.

Step 4: Remove conflicting records

Don’t keep both an A and a CNAME at the same name, and don’t leave a stale record from a previous host. Pick one record per name and delete the rest.

Step 5: Verify the record type with dig

dig +short example.com           # apex: should print an IP (the A record)
dig +short www.example.com CNAME # www: should print the CNAME target

If the apex prints a hostname instead of an IP, you still have a CNAME there. If www prints nothing for CNAME, you set an A where a CNAME belongs. Also confirm email survived:

dig +short MX example.com        # should still list your mail host(s)

Step 6: Wait for propagation, then re-verify

DNS changes are not instant. Allow up to 24 hours (some providers warn up to 48 hours) for caches to clear, though most resolvers update within 15-60 minutes. Query from a few public resolvers, then refresh the browser:

dig +short example.com @1.1.1.1   # Cloudflare resolver
dig +short example.com @8.8.8.8   # Google resolver

When every resolver returns the new value and the platform shows the domain as Valid Configuration (and the SSL certificate issues), you’re done.

How to confirm it’s fixed

You’ve fully fixed it when all three are true:

  1. dig +short example.com returns the platform IP (an A), and dig +short www.example.com CNAME returns the platform’s hostname (a CNAME).
  2. dig +short MX example.com still lists your mail host, so email is intact.
  3. The hosting dashboard reports the domain as valid and serves it over HTTPS without a certificate error.

FAQ

Can I ever use a CNAME at the root domain? Not a real CNAME. The workaround is ALIAS/ANAME or Cloudflare’s automatic CNAME flattening, which present a CNAME-like target but answer with an A/AAAA record so SOA, NS, and MX keep working at the apex.

Why did my email stop after I added a CNAME to the root? A CNAME cannot coexist with any other record at the same name (RFC 1912 §2.4), so it suppresses the apex MX records. Replace the apex CNAME with an A record (or ALIAS/flattening) and your MX records become visible again.

A record vs CNAME, what’s the actual difference? An A record maps a name directly to an IPv4 address (AAAA for IPv6). A CNAME is an alias that says “look up this other name instead,” and the resolver then fetches that name’s A/AAAA. A is fixed to an IP; CNAME follows whatever the target currently resolves to.

Should I use an A record or move my nameservers to the host? If you only host the website on that platform and don’t run complex external DNS, delegating nameservers is the most reliable option because the platform updates the apex IPs for you. Keep external DNS with an A record when you need to manage MX, TXT, or other records elsewhere.

My host gave me cname.vercel-dns-0.com instead of cname.vercel-dns.com. Which is right? Use whatever your own dashboard shows. Vercel issues project-specific CNAME targets, so the suffix can differ between projects; copying the value from the dashboard is always correct.

The dig output looks right but the browser still shows the old site. Why? Your local DNS cache or the browser is holding the old answer. Flush the OS resolver cache, query a public resolver with dig +short example.com @1.1.1.1, and try a private/incognito window once the public resolver returns the new value.

Prevention

  • Trust your hosting provider’s dashboard values, not generic tutorials.
  • Note which record type you chose per name in your DNS provider’s comment field.
  • Apex domain: always A or ALIAS/ANAME/flattening, never a literal CNAME.
  • Don’t mix record types at the same name; pick one and delete conflicts.
  • When you change hosts, remove the old records completely before adding the new ones.

Tags: #Troubleshooting #DNS #Debug

Related Articles