An A record maps a hostname directly to an IPv4 address, such as 203.0.113.10. A CNAME maps a hostname to another hostname. Use an A record for your bare domain and when you control a fixed IP; use a CNAME for subdomains that point to a service which manages its own addresses.
Below we cover how each record works, the rules that catch people out (especially the root-domain restriction), and a quick reference for common setups like Shopify, Microsoft 365 and CDNs.
Key takeaways
- An A record points a hostname directly to an IPv4 address, while a CNAME points it to another hostname.
- Use an A record for your bare domain, because the DNS standards do not allow a CNAME at the root alongside SOA and NS records.
- Use a CNAME for subdomains on platforms such as Shopify or a CDN, so your record follows the platform when its IP addresses change.
- Never point an MX record at a CNAME, and delete CNAMEs for cancelled services to avoid subdomain takeover.
What is an A record?
An A (address) record is the most basic DNS record. It says "this name lives at this IPv4 address". Its IPv6 equivalent is the AAAA record.
example.com. 3600 IN A 203.0.113.10
example.com. 3600 IN AAAA 2001:db8::10
When a browser looks up example.com, the resolver gets the IP straight away. One lookup, one answer. You can have several A records on the same name (for simple load spreading) and you can have other record types, such as MX and TXT, alongside them.
What is a CNAME record?
A CNAME (canonical name) record says "this name is an alias of that name; go and look that one up instead". The target must be a hostname, never an IP address.
www.example.com. 3600 IN CNAME example.com.
shop.example.com. 3600 IN CNAME shops.myshopify.com.
The resolver follows the alias, looks up the target, and returns the target's A or AAAA records. If the platform behind shops.myshopify.com changes its IP addresses, your subdomain follows automatically. That is the main advantage: someone else maintains the address.
What is the difference between a CNAME and an A record?
| A record | CNAME record | |
|---|---|---|
| Points to | An IPv4 address | Another hostname |
| Lookups | One | Two or more (alias, then target) |
Allowed at the root domain (@) |
Yes | No, under the DNS standards |
| Can share a name with MX, TXT and other records | Yes | No, a CNAME must be alone on its name |
| Who updates the IP | You | Whoever controls the target hostname |
| Typical use | Your own server, the bare domain | www, SaaS platforms, CDNs, verification records |
Why can't I put a CNAME on my root domain?
RFC 2181 says a name that holds a CNAME can carry no other data apart from DNSSEC records, and RFC 1912 spells out that "a CNAME record is not allowed to coexist with any other data". Your bare domain (example.com, written as @ in most dashboards) must always have SOA and NS records. So a CNAME there would clash with records that have to exist.
In practice this means:
- Some DNS dashboards simply refuse to save a CNAME on
@. - Others accept it, and things break in odd ways: email stops because MX records are ignored, or verification TXT records disappear.
What if my platform tells me to use a CNAME on the root?
Use your DNS provider's workaround. Cloudflare calls it CNAME flattening: you enter a CNAME at the apex, and Cloudflare looks up the target and answers with the final IP address, so resolvers only ever see A or AAAA records. Other providers offer the same idea as an ALIAS or ANAME record. If your provider has none of these, point the root at the platform's published A record IPs and use a CNAME on www, then redirect one to the other.
Can an MX record point to a CNAME?
No. RFC 2181 says the hostname in an MX or NS record must not be an alias; it has to have address records directly. Some mail servers tolerate it, but others will not, so you get intermittent delivery failures that are very hard to diagnose. Point MX records at the hostnames your email provider gives you, which are already set up correctly.
Which should I use? A quick reference
| Setup | Record to use |
|---|---|
| Bare domain on your own VPS or host | A (and AAAA if the server has IPv6) |
www on the same server as the root |
CNAME to the root, or A to the same IP |
| Subdomain on Shopify, Squarespace, Wix, HubSpot and similar | CNAME to the platform's hostname |
| Root domain on a SaaS platform | The platform's A record IPs, or ALIAS/flattening |
| CDN in front of your site | CNAME to the CDN hostname (flattening at the apex) |
| DKIM for Microsoft 365, Google Workspace or a sending platform | CNAME or TXT, exactly as the provider specifies |
| Domain verification for Google or Microsoft | Usually TXT; follow the provider's instructions |
| Email (MX targets) | Never a CNAME |
When a provider gives you both options, prefer the CNAME on subdomains. If they move servers, you do not need to do anything.
Is a CNAME slower than an A record?
Slightly, in theory. A CNAME needs an extra lookup to resolve the target. In practice, popular targets are heavily cached by resolvers, so the difference is usually a few milliseconds and only on the first visit. Avoid chains, though: a CNAME pointing to a CNAME pointing to another CNAME adds a lookup each time and multiplies the chances of something breaking. If you are chasing every millisecond of server response, our guide to reducing TTFB covers the bigger wins.
How do I check what records my domain has?
Use a lookup tool rather than reading your dashboard, because the dashboard shows what you saved, not what the world sees. The free MakeItFlow DNS lookup tool shows A, AAAA, CNAME, MX, TXT and NS records. From a terminal:
dig +short www.example.com CNAME
dig +short example.com A
If dig returns a CNAME and then an IP, the alias is working. If it returns nothing, the target hostname may not exist, which leaves a "dangling" CNAME.
Why are dangling CNAMEs a security risk?
If you delete a service, for example a cloud storage bucket or an old landing-page tool, but leave the CNAME pointing to it, someone else may be able to claim that hostname on the same platform and serve content on your subdomain. This is called subdomain takeover. Review your CNAMEs whenever you cancel a SaaS subscription and delete any that point to services you no longer use. Our free subdomain finder lists the subdomains recorded in public certificate logs and flags CNAMEs whose targets no longer exist.
Frequently asked questions
Can I have both an A record and a CNAME on the same name?
No. A CNAME must be the only record on its name. If you need an IP address and other records on the same hostname, use A or AAAA records instead.
Should www be a CNAME or an A record?
Either works. A CNAME to the root means you only update one IP address if you change servers. An A record avoids the extra lookup. Most small business sites use a CNAME and redirect www to the root, or the other way round.
Does the choice affect SEO?
Not directly. Search engines care that the site loads reliably over HTTPS and that one version (with or without www) is canonical. Set up a 301 redirect and a canonical tag; our canonical tags guide explains how.
What does the trailing dot in a CNAME mean?
It marks a fully qualified domain name. In raw zone files, a target without the dot gets your domain appended, so shops.myshopify.com would become shops.myshopify.com.example.com. Most web dashboards add the dot for you.
How long does a CNAME change take?
As long as the TTL on the old record. With a TTL of 300 seconds, most users see the change within minutes; with 86400, allow up to a day. See DNS propagation explained for the details.
What to do next
Look up your domain's records and check that the root uses an A record or flattening, that no MX points to an alias, and that no CNAME points to a service you have cancelled. MakeItFlow checks your DNS, DNSSEC, CAA and email records as part of a free website audit, or you can run the focused DNS health check. For a wider tour of record types, read DNS records explained.
Sources
Written by the MakeItFlow team
We build the website audit these guides are based on. Every fact is checked against the primary sources listed above and this guide was last reviewed on 1 November 2026 . How we research and check
Check your own site in 30 seconds
Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.
