A Record vs CNAME: Which DNS Record for Domain Redirects?
Michel Bardelmeijer is Tech Lead and Sales at redirect.pizza, where he helps DevOps and IT teams solve domain redirect challenges at scale. Michel has guided organizations like SD Worx, Zurich Airport and Harvard through complex redirect scenarios involving thousands of domains.
Have questions about bulk redirects, HTTPS migrations, or domain consolidations? Connect with Michel on LinkedIn or reach out to the redirect.pizza team.
Apex domains need A records. Everything else gets a CNAME. Here's why that matters for your redirects.
The A record versus CNAME question comes up every time someone sets up a domain redirect. Your DNS provider asks you to create a record, and you are looking at two options with no obvious way to choose between them.
The answer depends on one thing: are you redirecting an apex domain (example.com) or a subdomain (www.example.com)? If you have ever stared at a DNS panel wondering which record type to pick, this is the short answer and the long explanation. For the full picture of how DNS records fit into domain redirects, see our complete guide to URL redirects.
Key Takeaways
- Use a CNAME for subdomains (www.example.com, shop.example.com). It points to the redirect service's domain name and follows automatically if their IP changes.
- Use an A record (plus AAAA for IPv6) for apex domains (example.com without www). Apex domains cannot have CNAME records.
- Most redirect setups need both: A record on the apex, CNAME on www. This covers all traffic.
- The apex restriction exists because CNAME records cannot coexist with the SOA and NS records that are required at the root of a DNS zone.
- CNAME flattening (Cloudflare) and ALIAS records (DNSimple, Route 53) are workarounds for the apex limitation, but they are not universally supported.
A Records: Direct to an IP Address
An A record maps a domain name to an IPv4 address. When a browser looks up example.com and finds an A record pointing to 89.106.200.1, it connects to that IP directly.
The upside: A records work everywhere, including on apex domains. No restrictions.
The downside: the IP address is hardcoded. If the redirect service migrates to new infrastructure and their IP changes, your redirect breaks until you manually update the record. For a single domain, that is a minor inconvenience. For fifty domains, it is a Monday morning you do not want to have. (Services with automatic DNS management can handle this for you.)
An AAAA record is the same concept for IPv6. If you add an A record for a redirect, add the AAAA as well. It takes 30 seconds and covers visitors on IPv6-only networks.
CNAME Records: Following a Domain Alias
A CNAME record maps a domain name to another domain name. Instead of pointing www.example.com to an IP, you point it to a hostname like edge.redirect.pizza. The redirect service controls the IP behind that hostname. Think of it as a DNS alias record: one name borrowing the address of another.
The upside: if the service changes their IP, the CNAME follows automatically. You configure it once and never touch it again.
The downside: CNAME records cannot be used on apex domains. That is not a quirk of specific registrars. It is a DNS protocol rule.
For a deeper explanation of how CNAME records work, see What Is a CNAME Record?. For a comparison of DNS-level redirects versus server-side approaches like .htaccess, see DNS-Level vs Server-Side Redirects.
A Record vs CNAME: When to Use Each for Redirects
The CNAME vs A record decision comes down to one question: are you redirecting an apex domain or a subdomain?
| A Record | CNAME | |
|---|---|---|
| Points to | IP address | Domain name |
| Works on apex domains? | Yes | No |
| Follows IP changes automatically? | No (manual update) | Yes |
| Can coexist with MX/TXT records? | Yes | No |
| IPv6 | Separate AAAA record needed | Included (if target has AAAA) |
| Best for redirects on | Apex domains | Subdomains |
CNAME when you are redirecting a subdomain:
Any domain name with a prefix (www.old-domain.com, shop.old-domain.com, blog.old-domain.com) can use a CNAME. This is the preferred option for redirect services because it is future-proof. The redirect service manages the IP, you never update your DNS.
A record (+ AAAA) when you are redirecting an apex domain:
The bare domain (old-domain.com, without www or any other prefix) must use an A record. The technical reason is in the next section. The practical consequence: if the redirect service changes their IP, you need to update this record manually.
Both when you are redirecting a full domain (most common):
Most redirects need to catch traffic on both the apex domain and the www subdomain. Whether visitors type your domain with www or without it, both need to land on the redirect. The standard setup:
- A record on old-domain.com (apex)
- AAAA record on old-domain.com (IPv6)
- CNAME on www.old-domain.com
This covers every way someone might reach your old domain: typing it with www, without www, following an old bookmark, clicking a backlink. If you only set up the CNAME on www and skip the apex, anyone who types old-domain.com directly gets a DNS error instead of a redirect. That is how you end up explaining to your manager why the old domain shows an error page instead of forwarding to the new site.
Not sure whether to use a 301 or 302 redirect? For domain moves, 301 is almost always the right choice.
One thing the DNS record does NOT control: path forwarding. Whether old-domain.com/products/widget forwards to new-domain.com/products/widget or just to new-domain.com depends on the redirect service, not on the A record or CNAME you created. The DNS record only gets the traffic to the redirect service. What happens after that is configured in the service itself. If preserving URL paths matters for your SEO, check that your service supports it before setting up the DNS records.
Why Apex Domains Cannot Use CNAME Records
This is the single most common DNS issue in redirect setup. Understanding why saves you from debugging a problem that has no solution other than using a different record type.
The apex domain (also called root domain or naked domain) is the base of your DNS zone. For a practical guide to handling the most common apex redirect scenario, see Apex to www. The technical reason it needs special treatment: the apex must have SOA (Start of Authority) and NS (Name Server) records. Often it also has MX records for email and TXT records for SPF/DKIM verification.
The DNS specification (RFC 1034) states that a CNAME record cannot coexist with any other record type on the same name. Since SOA and NS are mandatory at the apex, CNAME is technically impossible there. This is not a limitation of your registrar. It is how DNS works.
Some registrars will let you create a CNAME on the apex without complaint. It might even appear to work initially. Do not trust it. It violates the DNS spec and can cause unpredictable behavior: email delivery may break, DNSSEC validation may fail, and some resolvers will reject the response entirely.
The most common broken redirect we see in support is someone who created a CNAME on their apex domain. Their registrar let them do it, it looked like it worked, and then three weeks later their email stopped arriving. The A record is the correct answer for apex domains. Every time.
– Michel Bardelmeijer, Tech Lead at redirect.pizza
Workarounds for Apex Aliasing
Two non-standard alternatives exist for situations where you want CNAME-like behavior on an apex domain:
CNAME flattening (Cloudflare): Cloudflare resolves the CNAME target server-side and returns an A record to the client. From the outside, it looks like a regular A record. From your perspective, it behaves like a CNAME: you point to a hostname, and Cloudflare handles the IP resolution. The catch: you must use Cloudflare as your DNS provider, and this behavior is Cloudflare-specific, not a DNS standard.
ALIAS / ANAME records (DNSimple, Route 53, others): Some DNS providers offer a proprietary DNS alias record that works like a CNAME at the apex. DNSimple calls it ALIAS, AWS Route 53 calls it ALIAS, and the concept is sometimes referred to as ANAME. Like CNAME flattening, the provider resolves the target and returns an A record. The catch: not all DNS providers support this, there is no universal standard, and you are locked into providers that offer it.
The standard solution: For most redirect setups, A + AAAA records on the apex domain are the simplest and most portable option. They work at every registrar, require no special provider, and are supported by every DNS resolver on the planet.
Common DNS Mistakes in Redirect Setup
Four mistakes that account for most broken redirect configurations:
1. Creating a CNAME on the apex domain. Covered above, but worth repeating because registrars let you do it without warning. If your apex redirect is not working, check whether you accidentally created a CNAME instead of an A record.
2. Setting up the CNAME on www but forgetting the apex. Your redirect works for www.old-domain.com but not for old-domain.com. Half your traffic sees an error. Add the A + AAAA records on the apex to catch both.
3. Adding an A record but skipping the AAAA. Your redirect works for IPv4 visitors but fails for anyone on an IPv6-only network. This is still a minority of traffic, but it is growing, and the fix takes 30 seconds.
4. Not lowering the TTL before a migration. You set up your redirect, test it, and it does not work. You check the DNS records, and they look correct. The problem: your old records had a 24-hour TTL, and DNS servers around the world are still caching the previous values. Lower the TTL to 300 seconds (5 minutes) a day before you make the switch, and propagation happens in minutes instead of hours.
DNS Records for a Redirect Setup
Enough theory. Here is what you actually type into your DNS panel.
These examples use redirect.pizza's DNS values. Check the current DNS records for up-to-date values, as these can change if the service migrates infrastructure.
Redirecting a subdomain only
If you only need to redirect www.old-domain.com:
www.old-domain.com CNAME edge.redirect.pizzaOne record. Done.
Redirecting an apex domain + www (standard setup)
If you need to redirect old-domain.com and www.old-domain.com:
old-domain.com A 89.106.200.1
old-domain.com AAAA 2a12:5240::1
www.old-domain.com CNAME edge.redirect.pizzaThree records: A and AAAA for the apex, CNAME for www. If you need help with the DNS changes, redirect.pizza shows you the exact records to create after you add your redirect.
A note on TTL
TTL is the setting most people ignore until they need to change something fast. It controls how long DNS servers cache your records before checking for updates. For both A records and CNAME records, the TTL determines how quickly changes propagate. For a redirect you are setting up once, the default TTL (usually 3600 seconds, or 1 hour) is fine.
If you are in the middle of a migration and might need to change records quickly, lower the TTL to 300 seconds (5 minutes) before making changes. A lower CNAME TTL or A record TTL means DNS servers will pick up your new values faster. After the migration is stable, set it back to a higher value to reduce unnecessary DNS lookups.
For a step-by-step walkthrough of the full redirect setup process, see How to Set Up a Domain Redirect.
Related Guides
- What Is a CNAME Record? How It Works for Domain Redirects
- How to Set Up a Domain Redirect
- How to Redirect With HTTPS
- URL Redirects: The Complete Guide
Frequently Asked Questions
No. Search engines see the HTTP redirect (301 or 302), not the DNS record behind it. Whether your domain reaches the redirect service via a CNAME or an A record, the browser receives the same redirect response, and search engines process it identically. The choice between A and CNAME is a DNS infrastructure decision, not an SEO decision.
Only if you use A records for both. You could create an A record for example.com and another A record for www.example.com, both pointing to the same IP. But this means you lose the automatic-update benefit of CNAME on the www subdomain. The recommended setup is A (+ AAAA) on the apex and CNAME on www: you get the broadest compatibility on the apex and the maintenance-free alias on the subdomain.
Most services announce IP migrations in advance by email or on their status page. Some provide a changelog or migration guide with updated DNS values. If you used a CNAME, you do not need to act on these announcements, your DNS follows automatically. If you used A records, you need to update them before the old IP goes offline. Set a calendar reminder when you receive a migration notice. If you miss it, the first sign is usually that your redirect stops working.
On a subdomain, yes. Delete the A record and create a CNAME instead. The change takes effect after DNS propagation (usually 1-2 hours). On an apex domain, no, because CNAME is not allowed there. The only way to get CNAME-like behavior on an apex is through CNAME flattening (Cloudflare) or ALIAS records (provider-specific). For most setups, keeping A records on the apex is simpler.
An ANAME record is a non-standard DNS record type that some providers offer as a workaround for the CNAME-at-apex limitation. It behaves like a CNAME (pointing to a hostname instead of an IP) but resolves server-side and returns a regular A record to the client. Different providers use different names for the same concept: DNSimple and AWS Route 53 call it ALIAS, while others use ANAME. There is no universal standard, and an IETF draft to standardize it expired in 2020 without being adopted. If portability matters to you, use A + AAAA records on the apex instead.
Three records. One redirect.
Three DNS records. That is all that stands between your old domain and a working redirect. redirect.pizza handles both apex and subdomain redirects with automatic HTTPS. See the exact DNS records or get started for free.
