On this page
A CNAME makes one hostname an alias of another name, and a DNAME rewrites an entire subtree the same way. You almost never want either record at the zone apex, which is the bare domain itself. A real CNAME there cannot sit beside MX or TXT, and a DNAME will pull mail and auth names along with it. For the apex, use A and AAAA records, or a flattening feature you can see and control in the panel.
What CNAME and DNAME actually do
A CNAME says this exact name is an alias of that other name. Once a CNAME is present, other record types are not allowed at the same name. That includes MX for mail delivery and TXT for SPF or domain verification. A DNAME is broader: it treats a whole branch of names as an alias of another branch. Hostnames you never planned to move, including _dmarc and DKIM selectors, can follow that rewrite.
A and AAAA simply publish addresses for a name. Some DNS hosts offer apex flattening, which may look like a CNAME in the UI but answers with synthesized A or AAAA data. Flattening still involves a second lookup and a TTL you should watch. It is a workaround that can work well when you understand it. Keep aliases easy to reason about by being explicit about which name owns which records.
Why the apex should stay on addresses
MX at the apex plus a CNAME at the apex cannot coexist. SPF TXT fails for the same reason. You should not trade working mail for a setup wizard that CNAMEs example.com to a CDN. Keep the apex on A or AAAA pointed at your origin, or use documented flattening if your DNS host provides it. Put the CDN on www with a normal CNAME. That is what www is for, and your MX and TXT records stay untouched at the apex.
Lower the TTL before you switch anything. After you publish, query the authoritative nameservers first, then a public resolver. Authoritative answers and recursive cache are not the same view. Ping is not a DNS check. A CNAME answer for the apex is the bug you are fixing.
dig example.com A +short
dig example.com CNAME +short
dig example.com MX +short
dig www.example.com CNAME +shortIf the second command prints a name, the apex is a CNAME. Remove that CNAME and put A or AAAA records back. Fix www on its own as a separate name. Wait out the old TTL instead of toggling every few minutes. Send a test message afterward, because mail is often the first sign that the apex was abused.
Why DNAME is usually the wrong shortcut
DNAME can look like a clever way to point a whole brand at another zone in one step. It also aliases mail-related names and hostnames you did not intend to follow. Mail authentication then fails, and the outage is easy to misread as “DNS is down.” Prefer explicit records per name. A DNAME that swallowed _dmarc or DKIM selectors often turns into a long week of SPF and DKIM tickets.
Apex and www are different names, even when a wizard treats them as one. If mail already stopped, restore MX and TXT at the apex first, then place the CDN on www. More on flattening versus a real CNAME is here: A vs AAAA vs CNAME.
Tagged
Was this article helpful?
Be the first to rate this article.
