If you've ever added a custom domain to a project, you've already used a CNAME or an A record, even if you didn't think much about which one at the time. These two record types power almost every domain configuration on the web, and the difference between them is smaller and more intuitive than most documentation makes it seem. Root domains and subdomains follow different DNS rules, and knowing which record type fits where gives you control over how your domain resolves, routes traffic, and works with services like email and SSL.
This guide covers how CNAME and A records work, when to use each, and how to configure them on Vercel.
Copy link to headingWhat is a CNAME record?
A CNAME (Canonical Name) record creates an alias from one domain name to another. Instead of telling the DNS resolver "go to this IP address," it says "go look up this other hostname instead," and the resolver follows that chain until it lands on an A or AAAA record with an actual IP. The record type was defined in RFC 1034, the original Internet Standard for DNS.
A CNAME lets you point a subdomain like www.example.com to your hosting provider's hostname, and if the provider later changes the IP addresses behind it, your DNS stays the same. The provider manages the IPs, and your CNAME just follows wherever the target hostname points.
Copy link to headingWhat is an A record?
An A record (Address record) is the most direct type of DNS record. It maps a hostname to a specific IPv4 address, and when a resolver looks it up, it gets that IP back in a single step with no extra lookups needed. The record type was defined in RFC 1035.
Because A records don't conflict with other record types, they can sit alongside MX records (for email), TXT records (for domain verification and authentication), and NS records (for subdomain delegation) at the same hostname. That's what makes them the go-to choice for root domains like example.com, where those other records typically live.
Copy link to headingHow CNAME and A records differ
A records give you a direct line from hostname to IP address. CNAME records give you an alias that lets someone else manage the IP on your behalf. In practice, that means each record type behaves differently when it comes to resolution speed, where it can be used, and what other DNS records can live at the same hostname.
Copy link to headingHow each record resolves
An A record resolves in one step. The resolver asks the nameserver for example.com, gets back 203.0.113.10, and it's done. A CNAME takes at least two steps because the resolver first gets back another hostname, then has to go look up that hostname's IP address separately. If the CNAME target points to yet another CNAME, each hop adds another lookup.
Here's what both paths look like in a DNS trace:
A record:
example.com → 203.0.113.10 (1 lookup, done)CNAME record:
www.example.com → loadbalancer.provider.com (lookup 1) loadbalancer.provider.com → 203.0.113.42 (lookup 2, done)Copy link to headingDNS lookup speed and caching
Because a CNAME requires at least one extra lookup compared to an A record, the first resolution takes slightly longer. On AWS Route 53, a CNAME lookup within the same zone can count as two queries instead of one because the resolver must also look up the target hostname.
Caching closes that gap quickly, though. Once a resolver stores both the CNAME target and its associated A record, repeat lookups within the TTL (Time to Live) window skip the extra step entirely.
Copy link to headingRoot domain restrictions
This is where the two record types diverge the most. A CNAME record can't exist at the root of your domain (like example.com), and this isn't a hosting provider limitation. It's baked into the DNS protocol itself via RFC 1034.
Every root domain needs an SOA (Start of Authority) record and at least one NS (Name Server) record for DNS to work at all, but the spec says no other data can exist at a hostname that has a CNAME. Since SOA and NS are non-negotiable at the root, putting a CNAME there creates a direct conflict. A records don't have this restriction, which is why they're the default for root domains.
Copy link to headingMaintenance and IP changes
When a server's IP address changes, every A record pointing to the old IP needs a manual update. If you're managing multiple domains on the same infrastructure, those updates add up.
CNAME records avoid that problem entirely. If the IP behind the canonical hostname changes, only the A record for that canonical name needs updating, and every CNAME alias pointing to it picks up the new address automatically. For subdomains connected to cloud platforms and CDNs that rotate IPs behind stable hostnames, that saves hours of manual DNS updates.
Copy link to headingCompatibility with other DNS records
The CNAME exclusivity rule extends beyond the root domain. The DNS specification says that no other records can share a hostname with a CNAME, which blocks several common record types:
MX records: Email delivery depends on MX records, and a CNAME at the same hostname blocks them.
TXT records: SPF, DKIM, and DMARC authentication all rely on TXT records that can't share a hostname with a CNAME.
NS records: Subdomain delegation requires NS records that are equally incompatible with a CNAME at the same name.
A records don't have any of these restrictions. If a domain handles email or uses TXT-based authentication, the A record is the only option that lets all of those services coexist at the same hostname.
If a hostname needs MX, TXT, or NS records, don’t place a CNAME at that same hostname. Use an A or AAAA record, or another DNS-provider-supported approach.
Copy link to headingWhen to use a CNAME record
CNAME records are the standard choice for subdomains that point to provider-managed hostnames:
Subdomain routing to hosting platforms: Subdomains like
www.example.com,blog.example.com, orapp.example.comconnected to a cloud provider, benefit from a CNAME pointing to the provider's hostname, which lets them rotate IPs without any DNS changes on your end.CDN and SaaS integrations: Third-party services like CDNs, email platforms, and marketing tools often ask you to create a CNAME for a subdomain so they can manage the underlying infrastructure independently.
Vercel subdomain configuration: Subdomains on Vercel use CNAME records that point to a project-specific target hostname, and Vercel's domain configuration docs walk through that setup.
As general DNS hygiene, remove CNAME records for services you've decommissioned so your zone stays clean and predictable.
Copy link to headingWhen to use an A record
Any root domain like example.com requires an A record because the DNS protocol prohibits CNAME at the root. Beyond that, A records are also the right fit in a few other scenarios:
Fixed-IP servers: On-premises infrastructure, dedicated VPS instances, and Elastic IPs where the address is stable and under your direct control don't benefit from CNAME indirection, so a direct A record is the cleaner choice.
Hostnames with email or authentication records: Domains that receive email, carry SPF or DMARC authentication, or delegate subdomains through NS records require an A record so those record types can share the same hostname without conflict.
Vercel root domains: Root domains on Vercel point to the IP address shown in your project's domain settings.
For domains that need both root-level aliasing and dynamic hostname resolution, an ALIAS record (where your DNS provider supports it) works as an alternative.
Copy link to headingAAAA and ALIAS records as alternatives
An A record maps to an IPv4 address, and a AAAA record (pronounced "quad-A") does the same thing for IPv6. The name comes from the fact that IPv6 addresses are four times longer than IPv4 addresses (128 bits vs 32 bits), so the record type uses four A's. AAAA records work at the root domain without any restrictions, and for dual-stack configurations you'd create both an A record (for IPv4) and a AAAA record (for IPv6) at the same hostname.
ALIAS records fill a different gap. They address the problem of CNAME records not being allowed at root domains by having the nameserver resolve the target hostname internally and return the resulting IP as a standard A or AAAA record to the client. The extra resolution step happens server-side instead of client-side, so the requesting resolver never sees the alias. Different providers call this by different names: "ALIAS" at DNSimple, "Alias records" at AWS Route 53, and "CNAME Flattening" at Cloudflare. No official IETF standard governs these implementations, so they remain provider-specific. On Vercel, root domains are typically configured with an A record pointing to 76.76.21.21.
Copy link to headingConfiguring CNAME and A records on Vercel
Vercel automates most of the DNS configuration process. When you add a domain to a project, the Vercel dashboard detects whether it's a root domain or subdomain and shows you the exact record type and values to enter at your registrar, so there's no guesswork about which record to create or what target to use.
Copy link to headingAdding a CNAME record for subdomains
For subdomains like www.example.com, create a CNAME record at your DNS provider. Each Vercel project gets a unique CNAME target (in the format [hash].vercel-dns-[number].com), which you can find under Project Settings, then Domains in the Vercel dashboard.
If the Vercel dashboard shows ‘Invalid Configuration’ after you save the record, verify that the Name field contains only the subdomain prefix, such as www, and that no conflicting records already exist at that hostname.
Copy link to headingAdding an A record for root domains
Your root domain (example.com) needs an A record pointing to the IP address Vercel shows in your project's Domain Settings. The @ symbol in the Name field represents the root domain itself.
Vercel uses anycast routing behind 76.76.21.21, which means the network directs traffic to the nearest edge location regardless of where the IP appears to resolve geographically. If you're adding both example.com and www.example.com, set up a redirect from one to the other to establish a canonical URL and prevent duplicate content indexing. You can verify propagation with dig.
dig a example.comdig cname www.example.comCopy link to headingGet your custom domain live on Vercel with the right DNS records
Picking between a CNAME and an A record comes down to two things: whether it's a root domain or subdomain, and whether the hostname needs to coexist with other record types like MX or TXT. Root domains use A records, subdomains benefit from CNAME records, and any hostname carrying email or authentication records can't use a CNAME.
Vercel's domain setup handles the complexity behind those protocol rules for you. The dashboard detects your domain type, shows the exact DNS values for your registrar, and once the records propagate, Vercel takes care of automatic SSL provisioning, Vercel CDN distribution, and redirect management between your root and www variants. If you're ready to go, create a new project or browse Vercel's templates to get from DNS configuration to a live deployment in minutes. For pull request workflows, preview environments give each PR its own URL without any additional DNS setup.
Copy link to headingFrequently asked questions about CNAME vs A record
Copy link to headingCan you use a CNAME record for a root domain?
No. RFC 1034 prohibits CNAME records at the root domain because every root needs SOA and NS records, and CNAME can't coexist with any other record type at the same hostname. DNS providers like Cloudflare, AWS Route 53, and DNSimple offer proprietary workarounds, but no official IETF standard governs these implementations.
Copy link to headingWhich is faster, a CNAME or an A record?
An A record resolves in a single DNS lookup, while a CNAME requires at least two. DNS caching reduces that difference to a negligible level for repeat visitors, so the performance gap rarely becomes the deciding factor.
Copy link to headingDo CNAME records affect SEO?
DNS record type is not a Google ranking signal. The more relevant SEO concern is making sure that multiple domains resolving to the same content are paired with 301 redirects and canonical tags, so search engines consolidate everything under a single preferred URL.
Copy link to headingWhen should you use an ALIAS record instead?
An ALIAS record makes sense when you need to point a root domain at a provider-managed hostname, and your DNS provider supports the feature. ALIAS records resolve the target server-side and return standard A or AAAA records, bypassing the root CNAME prohibition while still providing dynamic hostname resolution. On Vercel, root domains use an A record pointing to 76.76.21.21, so an ALIAS setup isn't usually necessary.