A DNS A record points a domain name directly at an IP address; a CNAME record points a domain name at another domain name instead. That distinction matters because an alias only works at the DNS level — it never redirects a visitor's browser the way a URL redirect does, and the two get confused constantly in web development, hosting, and marketing work. DNS (the Domain Name System) is the lookup service that translates a domain like example.com into the numeric address a browser needs to connect to a server. A record and CNAME are two of several record types that live in a domain's DNS zone, and choosing the wrong one causes real problems: broken subdomains, failed email delivery, or a marketing redirect that silently doesn't work the way the person setting it up assumed.
Table of Contents
- What an A Record Actually Does
- What a CNAME Record Actually Does
- Why "Alias" Doesn't Mean "Redirect"
- When to Use Each One
- Troubleshooting Common Mix-Ups
- Frequently Asked Questions
What an A Record Actually Does
An A record ("Address" record) maps a hostname to an IPv4 address — a string like 203.0.113.42. When someone types example.com into a browser, the DNS resolver looks up the A record and gets back the server's IP address directly. No intermediate lookup, no extra hop at the DNS layer. Because an A record stores a raw IP address, it has no idea what's running on that server.
It doesn't know the server will serve a WordPress site, a Drupal install, or a static HTML page — it just tells the browser where to connect. The web server at that IP address is what decides, based on the Host header the browser sends, which site to serve if multiple domains share the server. A record is the typical choice for a root domain (example.com, sometimes written as the "apex" or "naked" domain), because many DNS providers don't allow a CNAME on the root — more on that limitation below. It's also the right choice any time you have a fixed, known IP address and want DNS resolution to happen in one step rather than two.
What a CNAME Record Actually Does
A CNAME ("Canonical Name") record doesn't point to an IP address at all. It points to another hostname, and tells the resolver "look up that hostname instead, then use whatever it resolves to." If www.example.com has a CNAME pointing to example.com, a visitor's browser resolves www.example.com by first reading the CNAME, then separately resolving example.com's own A record to get the actual IP. That extra lookup step is the whole point of a CNAME: it's an alias, not a destination. The practical benefit is that the IP address only has to be correct in one place.
If the server's IP address changes, you update the A record once, and every CNAME pointing at that hostname follows automatically — no need to track down and edit every alias individually. This is why CNAMEs are the standard way to point a subdomain at a third-party service: a blog platform, a CDN, an email marketing tool, or a hosting provider's load balancer. The provider gives you a hostname to alias to (something like mysite.hosted-platform.com) rather than a specific IP, because the provider's own infrastructure may move between IP addresses over time. The CNAME insulates the subdomain from those changes.
Why "Alias" Doesn't Mean "Redirect"
This is the distinction that causes the most confusion. A CNAME is a DNS-level alias: it tells the resolution process to keep looking under a different name, but the browser's address bar, the URL the visitor sees, and the HTTP request never change. The visitor is never told to go anywhere else — their browser is simply handed a different IP address to connect to, transparently, before any content loads. A web redirect (an HTTP 301 or 302 response, or similar) is something else entirely.
It happens after DNS resolution is already finished and the browser has connected to a server. The server responds with a status code and a new URL, and the browser then visits that new URL — which the visitor can usually see happen in the address bar, and which search engines treat as a distinct signal about which URL is canonical. A common mistake is setting up a CNAME and expecting it to behave like a redirect — for example, aliasing an old domain to a new one and assuming visitors will see the new domain's URL. They won't. The address bar still shows the original hostname, because nothing about DNS resolution is visible to the browser's URL display.
- A CNAME changes where a hostname's lookup ends up pointing, invisibly, before a connection is made.
- A redirect changes what URL the visitor and browser end up at, visibly, after a connection is made.
- A CNAME cannot carry a path, query string, or "this page moved to that page" instruction — it only aliases one hostname to another.
- A redirect can send one specific URL to another specific URL, including different paths, which a CNAME can never do.
When to Use Each One
The right choice depends on what you're pointing and what you already know about the destination. Many providers also offer an "ALIAS" or "ANAME" record as a workaround for root domains that need CNAME-like behavior; it behaves like a CNAME but is implemented by the DNS provider resolving it to an A record automatically, since the root domain itself can't hold a true CNAME. Check whether your specific DNS host offers this before assuming a root domain is stuck with a static A record.
- Use an A record for a root/apex domain, since most DNS providers block CNAMEs there (a long-standing DNS rule: a root domain generally can't carry a CNAME alongside the other records — MX, TXT, NS — it needs).
- Use an A record when you have a static, known IP address you control and don't need the indirection.
- Use a CNAME for a subdomain pointed at a third-party platform (hosting, email tools, CDNs) that gives you a hostname rather than an IP.
- Use a CNAME when the destination's IP address might change and you want that change to happen in one place.
- Use an actual HTTP redirect — configured at the web server or application level, not in DNS — when the goal is to send visitors or search engines from one URL to a different one.
Troubleshooting Common Mix-Ups
Several recurring problems trace back to this A-record-versus-CNAME distinction. A subdomain that "won't load" after being pointed at a hosting platform is often a CNAME aimed at the wrong hostname, or an A record left in place from an old setup that conflicts with a new CNAME — a hostname can't have both an A record and a CNAME at the same name. Getting the record type right is necessary but not sufficient — DNS determines where a request is routed, while what happens to the visitor's URL afterward is decided entirely by server and application configuration, not by the DNS zone.
- If www.example.com doesn't match example.com's content, check whether www is a CNAME to the root domain or has its own separate A record that's gone stale.
- If adding a third-party service (email, CDN, site builder) isn't working, confirm whether the provider's instructions asked for a CNAME (a hostname to alias to) or an A record (an IP address) — using the wrong type for what they provided is a frequent setup error.
- If a domain migration seems to have "redirected" traffic but analytics show the old URL still showing in browsers, the DNS was changed but no HTTP redirect was configured — the two have to be set up separately.
- DNS changes also take time to propagate due to caching (TTL, or time-to-live, settings), so a correct change can take anywhere from minutes to around 48 hours to be visible everywhere, which is a separate issue from getting the record type right.
Frequently Asked Questions
Can a domain have both an A record and a CNAME at the same hostname?
No. DNS rules require a CNAME to be the only record at that exact hostname, so it can't coexist with an A record, MX record, or any other record type there.
Does changing a CNAME affect SEO the way a redirect does?
Not directly. A CNAME only changes DNS routing and is invisible to the URL a browser or search engine sees, so it carries none of the canonicalization signal a 301 redirect provides.
Why can't most domains use a CNAME at the root (apex) level?
The root domain typically needs to hold other records simultaneously, such as MX for email and NS for nameservers, and a CNAME can't share a hostname with any other record type.
If I change the IP address behind a CNAME's target, do I need to update the CNAME itself?
No — that's the benefit of a CNAME. Since it points to a hostname rather than an IP, updating the A record that hostname resolves to is enough; every CNAME aliased to it picks up the change automatically.
