Conflicting DNS records

A CNAME says that this name is an alias for another name, so every query for it should be answered from the target.

That includes queries for record types the alias author never thought about — MX, TXT, and the SPF and DMARC records that live in TXT.

So publishing a CNAME at a name that also has MX records means receivers follow the alias and find whatever the target publishes, which is usually nothing relevant.

The specification states the restriction plainly, and resolvers and providers enforce it inconsistently, which is why the situation arises at all.

Some DNS providers refuse to create the conflicting record; others accept it and serve both, leaving the resolver to decide.

A hosting platform asks you to point the domain at a hostname rather than an address, because its addresses change.

At a subdomain that is a CNAME and works fine. At the apex it collides with the MX, TXT and NS records the apex must carry.

The website starts working, which is the change everyone was watching, and the mail stops arriving, which nobody is watching.

The delay between the two makes the connection hard to see: mail failures are reported by senders over the following hours.

SPF and DMARC records disappear at the same moment, so authentication breaks alongside delivery.

Use the provider's flattening mechanism, which most managed DNS providers offer under a name of their own — it resolves the target and serves addresses, so no CNAME exists.

Or publish address records directly, accepting that you must update them when the platform's addresses change.

Or move the site to a subdomain and redirect the apex, which is a product decision rather than a DNS one.

What does not work is publishing the CNAME and hoping, because the conflict is not a warning — it is the other records becoming unreachable.

The same reasoning applies to any name carrying MX or TXT records, not only the apex.

Two CNAMEs at the same name, which is invalid and resolved arbitrarily.

A CNAME whose target is itself a CNAME in a loop, which resolvers abandon after a few hops.

A CNAME at a name that also carries the DNSSEC signing records, which breaks validation rather than resolution.

A wildcard record shadowed by a more specific CNAME, where the wildcard silently stops applying to that branch.

All of these share the same symptom shape: records that exist and are not being seen.

Remove the CNAME first. Everything else is secondary while it is in place.

Re-publish the address records for the website using whichever alternative you chose.

Confirm MX, SPF and DMARC records are answered again before assuming mail has recovered.

Expect a delay equal to the previous record lifetimes before every resolver agrees, which is genuine propagation this time.

Check for bounced mail during the window, since senders will have received rejections you never saw.

`dig +short CNAME example.com` — any answer at the apex is the defect.

`dig +short MX example.com` and `dig +short TXT example.com` immediately afterwards: empty answers alongside a CNAME confirm it.

Query a resolver you have not used recently, since a cached answer from before the change can mask the current state.

Check subdomains that carry mail or verification records the same way.

After fixing, verify from several resolvers rather than one, because they will recover at different times.

`dns.conflicts` reports record types that conflict at the same name, which is this problem directly.

`dns.cname` reports the alias records themselves, including their targets and whether those resolve.

`email.mx.present` and `email.spf.present` are what surface the consequence: records that should exist and are not answered.

`dns.resolution` and `dns.propagation` distinguish a conflict from a name that simply does not resolve or is mid-change.

`infrastructure.ip_dns_consistency` reports whether the addresses reached match what DNS publishes, which is the adjacent question.