A CNAME points one name at another name, rather than at an address. When something looks up shop.example.com and finds a CNAME pointing at store.platform.com, the lookup restarts at that second name and follows whatever it resolves to.
That indirection is the whole value. If the platform renumbers its servers, your record keeps working, because you never recorded their address in the first place.
What one looks like
Name Type Value shop CNAME store.platform.com www CNAME example.com
The value is a hostname. Putting an IP address there does not work: that is what an A record is for.
The rule that causes every CNAME problem
A name with a CNAME cannot have any other record. Not an A record, not an MX record, not a TXT record.
The reason is that a CNAME means "this name is another name for that one", so every lookup for it must follow the alias. Any other record at the same name contradicts that.
Two consequences follow, and both matter.
Never put a CNAME on the bare domain
Your domain itself must carry NS records and an SOA record. They are what make the zone exist. Since a CNAME cannot coexist with other records, a CNAME on the bare domain is invalid.
Some DNS providers accept it anyway and simulate the behaviour with a proprietary feature. cPanel does not. If a service tells you to point your root domain at a hostname with a CNAME, use an A record with their address instead, or ask them for one.
The practical symptom of getting this wrong is dramatic: mail stops, because the MX records at that name are now being ignored.
The same rule bites on subdomains
A service asks you to point shop.example.com at their platform with a CNAME. Later the same service asks you to add a TXT verification record at shop.example.com.
You cannot do both. The CNAME excludes the TXT record.
The resolution is usually to use an A record for the subdomain instead, which coexists with TXT records happily. Ask the service for an address, or put the verification record at the name they actually intended: often a different one.
CNAME or A record
Use whichever the destination service specifies. They know when they change addresses and you do not.
Broadly:
CNAME when pointing at an external platform that manages its own infrastructure. Their address changes are invisible to you.
A record for the bare domain, for anything on your own server, and whenever the same name also needs other records.
Do not convert one to the other on your own initiative. A service that gave you a CNAME target expects to be able to renumber behind it, and pinning their current address in an A record works right up until they do.
www as a CNAME
Pointing www at the bare domain with a CNAME is a common and reasonable pattern: changing the domain's A record then moves both.
An A record for www is equally fine, and means updating two records when the address changes. Either works; be deliberate rather than ending up with both.
What matters more is that both names resolve at all, and that one redirects to the other at the web server so you have a single canonical address. Forcing HTTPS deals with settling that.
Chains
A CNAME pointing at another CNAME works, and each hop is another lookup before anything resolves. Two hops are unremarkable; four are worth removing.
A CNAME pointing at itself, directly or through a chain, is a loop. Resolvers detect it and give up, and the symptom is a name that simply does not resolve with no obvious cause. Follow the chain by hand when a CNAME behaves inexplicably.
Verify
dig shop.example.com
The answer shows the CNAME and then the record it resolves to. Both should be present. A CNAME with nothing after it means the target does not resolve, and that is a dead end regardless of how correct your record looks.
To see just the CNAME:
dig CNAME shop.example.com
Common problems
Mail stopped after adding a CNAME. It was added on the bare domain, and the MX records are now ignored. Remove it and use an A record.
The panel refuses to save it. A record already exists at that name. Remove the conflicting record, or use a different name.
Verification record will not save alongside a CNAME. The coexistence rule. Use an A record for that name instead.
CNAME resolves to nothing. The target hostname does not resolve. Check it directly with dig.
Points at the right target but shows the wrong content. DNS is correct and the destination service is not configured to answer for your hostname. That is their side, not yours.
The one place a CNAME cannot be used is the bare domain, which is why so many services work at www and fail at the root. Understanding Apex Domains and CNAME Limits walks through the three ways round it.
One record type answers for every subdomain at once, with limits worth knowing before relying on it. For that, see Understanding Wildcard DNS Records.