A service gives you setup instructions: create a CNAME pointing your domain at theirs. You try it on the bare domain and the DNS interface refuses, or accepts it and breaks your email.
This is not a limitation of your provider. It is how CNAME works.
The rule
A CNAME says "this name is another name for that one". Everything asking about it is redirected to the target.
The rule that follows: a name with a CNAME may have no other records. It cannot have an A record, an MX record or a TXT record, because the CNAME has already said that all answers come from somewhere else.
The bare domain. The apex, must carry the zone's SOA and NS records. It therefore already has records, and so cannot also be a CNAME.
That is the entire explanation for why www.example.com can be a CNAME and example.com cannot.
What happens if a provider lets you do it anyway
Some interfaces accept it. The result is not what you wanted.
Because the CNAME claims every lookup, your MX records stop being answered, and mail for the domain goes to whatever the target's mail configuration says, usually nowhere.
The symptom is a website that works and email that vanished, with no error to connect the two. If email stopped after a DNS change, this is the first thing to check.
Option one: ALIAS or flattening
Some DNS providers offer a record type called ALIAS, ANAME, or CNAME flattening.
It behaves like a CNAME for you and like an A record for the internet: the provider resolves the target itself and answers with the resulting addresses. The apex keeps its SOA, NS and MX records, and still follows the service when its addresses change.
This is the correct answer when your provider offers it. It is not a standard record type, so it does not exist everywhere, and moving DNS to a provider that supports it is occasionally the simplest fix for the whole problem.
Option two: a plain A record
Look up the service's address and point an A record at it.
Works immediately, and carries a real risk: you have hard-coded an address the service expects to be able to change. When they do, your site points at nothing, and there is no warning: the DNS record is still valid, it simply refers to a machine that no longer serves you.
Acceptable for a service with documented stable addresses. Poor for anything behind a large content network, where addresses change as a matter of routine.
Option three: redirect to www
Let www carry the CNAME, and redirect the bare domain to it at the HTTP level.
This is a legitimate and widely used arrangement. One detail catches people: the bare domain still needs an A record, pointing at whatever will serve the redirect. A redirect cannot happen if nothing answers the name at all.
The cost is a redirect on every visit to the bare domain, which is small. Redirecting a domain or page explains setting it up.
Deciding which
ALIAS if your provider offers it. Otherwise redirect to www, unless the service publishes stable addresses and you are content to own that dependency.
What matters either way is writing down which choice you made and why. An A record at the apex pointing at a third-party service is invisible until it breaks, and the person debugging it a year later will not know it was a workaround.
Subdomains have none of this trouble
Any subdomain can be a CNAME, because nothing requires it to hold other records. This is why service documentation is written for subdomains and treats the apex as the awkward case. Pointing a subdomain at a third-party service walks through the straightforward version.
Understanding CNAME records goes into the record type itself, and which record type you need goes into choosing between them.
Check which behaviour your provider actually offers
The alternatives look identical in a control panel and behave differently, so the first step is finding out which you have.
dig example.com A +short dig example.com CNAME +short dig example.com NS +short
If the first returns addresses and the second returns nothing, the provider is resolving the target and publishing the result, which is the arrangement you want at the domain itself.
If the second returns a name, the provider has allowed a record that is not valid there. It may work today and it will interact badly with mail records and with anything else at the same name.
The mail records are what break
The rule exists because an alias at a name replaces everything else at that name, and mail is usually what gets replaced.
dig example.com MX +short dig example.com TXT +short | head -3 dig example.com A +short
All three should return values. A domain with an alias at the top frequently answers for the address and returns nothing for mail, which stops delivery entirely while the website continues working perfectly.
That combination is the recognisable symptom: a site that is fine and mail that stopped on the day somebody changed the hosting. Checking these three together identifies it in seconds.
Watch it when the target changes address
Using a plain address record at the top means you have taken responsibility for keeping it current.
dig example.com A +short dig target.provider.example A +short
Compare the two occasionally. When a platform changes its addresses, everybody using an alias follows automatically and everybody using a fixed address does not.
Providers announce these changes and the announcement reaches an address nobody reads. A monthly comparison of those two answers is a thirty second check that prevents an outage with no apparent cause. Monitoring DNS covers automating it.