An A record points a name at an IP address. A CNAME points a name at another name. That is the whole difference, and for most of what you do either would work.
Then you try to put a CNAME on your bare domain, and everything breaks — the site, and more alarmingly your email. This is why that happens, and how to choose correctly.
What each one is
An A record maps a hostname directly to an IPv4 address:
www.example.com. 3600 IN A 203.0.113.10
An AAAA record does the same for IPv6. They behave identically in every way that matters here.
A CNAME record — canonical name — maps a hostname to another hostname:
www.example.com. 3600 IN CNAME example.com.
When a resolver hits a CNAME, it starts over with the new name and looks that up instead. The result is a second lookup, then whatever that name's A record says.
Why a CNAME is often the better choice
The advantage is that you stop being responsible for an address that is not yours.
If you point shop.example.com at your platform's IP address with an A record, you have hard-coded a value that belongs to someone else's infrastructure. When they migrate servers, fail over to a different region, or restructure their network, your subdomain points at nothing — and you find out from a customer.
With a CNAME to shops.platform.example, the platform controls the address behind that name. They can change infrastructure freely and your record keeps working. That is why every hosted service asks for a CNAME.
CNAMEs also work well with load-balanced and geographic DNS, where the target name deliberately returns different addresses to different users. An A record can only be one fixed address.
The rule that breaks things
A CNAME cannot coexist with any other record at the same name.
This is not a limitation of your DNS provider. It is in the DNS specification, and the reason is that a CNAME is a redirection for the entire name, not for one record type. If a name has a CNAME, every lookup for that name — of any type — follows the redirection. Allowing an MX record alongside it would create an ambiguity the protocol has no answer for.
Which leads directly to the problem everybody hits.
Why the bare domain is special
Your root domain — example.com, with no subdomain, called the zone apex — is required to have NS records and an SOA record. That is what makes it a delegated zone at all. Those records cannot be removed.
So the apex already has other records. And a CNAME cannot coexist with other records. Therefore you cannot put a CNAME at the root of a domain. Ever, in any provider, under any circumstances.
If your provider lets you save one, one of two things is happening: it is silently doing something else (see flattening, below), or it has created a configuration that will fail in ways you will struggle to diagnose.
What actually breaks
Here is the part that turns an inconvenience into an incident. A CNAME at the apex does not just affect web traffic. Every lookup at that name follows the CNAME, including MX.
So a mail server looking up example.com for MX records follows the CNAME to your hosting provider's name, finds no MX records there, and gives up. Your email stops. Not bounces you can see — quiet failures at the sending end, from people who assume you are ignoring them.
The site being down is obvious within minutes. The mail being down can go unnoticed for a day.
What to do at the apex instead
You have three real options.
Use an A record. If your host gives you a stable IP address, this is correct and simple. The risk is that the address is not yours to control, so if the host changes it you must update the record. Many hosts will tell you in advance; some will not.
Use ALIAS, ANAME or CNAME flattening. Most modern DNS providers offer a synthetic record type under one of these names. It behaves like a CNAME from your side, but the provider resolves the target themselves and returns the resulting A record in the answer. Because what leaves their nameserver is an ordinary A record, the specification is satisfied and MX records at the apex work normally.
This is the best answer when your host gives you a hostname rather than an address. Note that it is a provider feature, not a standard — if you migrate DNS providers, check the new one supports it before you move.
You can see this behaviour directly: run a domain using flattening through the DNS Checker and the A row will show plain IP addresses with no CNAME anywhere, even though the control panel shows an ALIAS. What the provider returns is what the internet sees.
Redirect the apex to www. Serve the site from www.example.com, where a CNAME is perfectly legal, and have the apex return a 301 to it. Many hosts and CDNs offer this as a setting. It is a legitimate choice, though it costs an extra round trip for visitors typing the bare domain.
Choosing between them
Use a CNAME when you are pointing a subdomain at a service someone else operates — a hosted shop, a documentation site, a status page, a CDN endpoint. Let them own the address.
Use an A record when you control the server and its address is stable, or when the name is the apex and your provider offers no flattening.
Never use a CNAME when the name needs to carry other records. That means the apex always, and any subdomain that has its own MX or TXT records. A common trap: adding a CNAME to mail.example.com when that name also carries an SPF TXT record.
Diagnosing it
Run the domain through the DNS Checker. The tool queries A, AAAA, CNAME, MX, NS and TXT separately, so you can see the interaction rather than one merged answer.
A CNAME appearing in the answer for an A query is normal and expected — it is the resolver showing its working as it follows the chain. Not a fault.
A CNAME at the apex alongside anything else is the failure described above. If the CNAME row returns a value for your bare domain and the MX row is empty, you have found why your email stopped.
A CNAME pointing at a name with no records produces a chain that resolves to nothing. The CNAME row shows the target; look that target up on its own to see whether it has an address at all.
Long chains — a CNAME to a CNAME to a CNAME — are legal but add a lookup each. Two hops is unremarkable. Five is worth simplifying, since every hop is latency before your page starts loading.
The short version
CNAME for subdomains pointing at infrastructure you do not own. A record when you own the address. Never a CNAME at the apex — use ALIAS or flattening if your provider has it, an A record if not. And if your email has mysteriously stopped, check whether someone added a CNAME to the bare domain.