When an MX record points to a CNAME: why it's invalid, and what to fix
An MX record is only supposed to name a host that has its own address record, but it's easy to end up pointing one at a CNAME instead — usually by reusing a hostname a CDN or hosting provider already told you to alias — and RFC 2181 is explicit that this is not allowed, not just discouraged, which means the fix is changing the target, not tolerating a warning.
By AdminKit team, Netbase JSC · Updated October 31, 2026
The rule, and why it exists
RFC 2181 §10.3 states it directly: “the domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias.” The exchange field of an MX record has to name a host that resolves to an address in its own right — an A or AAAA record at that exact name — not a CNAME pointing somewhere else. This isn’t an isolated mail-specific rule; it follows from the more general constraint in RFC 1034 §3.6.2 that a name carrying a CNAME record shouldn’t carry any other data, and from how RFC 1035 §3.3.9 defines the MX RDATA format as holding a preference and a host name that gets resolved separately — a design that assumes the target is a “real” name with its own address, not an alias one more lookup away from one.
Why it doesn’t fail the same way everywhere
The practical effect of pointing an MX record at a CNAME splits into two outcomes depending on how strict the resolving side is:
- A lenient resolver or mail transfer agent follows the alias anyway. Mail appears to work, but RFC 2181 points out the real cost even here: a correctly-targeted MX host gets its address returned as “additional section processing” in the same DNS response, while a CNAME target forces an extra round-trip to resolve the alias before the address is even known. That’s slower on every single delivery attempt, for no benefit.
- A strict resolver refuses to treat the alias as a valid MX target. From its perspective, the MX host simply has no usable address, which is functionally identical to a dangling MX record pointing at a hostname with no A/AAAA record at all — see how to read an MX lookup result for what that failure mode looks like in a lookup.
Because different mail software disagrees on how forgiving to be, an MX-to-CNAME setup can look completely fine from one sending server and silently undeliverable from another — which is exactly the kind of intermittent, hard-to-diagnose failure a clear standards violation like this tends to produce.
How this actually happens
Nobody sets out to point an MX record at an alias. It typically comes from reusing a hostname that was already a CNAME for something else — a CDN endpoint, a marketing automation platform’s tracking domain, or a “vanity” hostname a SaaS provider’s setup instructions said to alias to their infrastructure — and then pointing mail at that same name instead of the dedicated mail host the actual mail provider issued. It also turns up after a mail platform migration done quickly, where a leftover CNAME from the old configuration gets reused by mistake instead of removed.
How to check for it
- Run AdminKit’s MX lookup against your domain. It resolves each listed mail host’s A/AAAA records as a second step — if a host comes back with no address at all, that’s consistent with (though not exclusive proof of) a CNAME sitting where an A/AAAA record should be.
- Query the MX target’s own records directly with AdminKit’s DNS lookup tool, selecting the CNAME record type for that exact hostname. If it returns a CNAME result, the target is an alias, not a proper mail host, and the MX record is invalid under RFC 2181 regardless of whether mail currently appears to be flowing.
How to fix it
Point the MX record at a hostname that has its own A/AAAA record — not an alias of another name. If your mail provider issued a dedicated mail-host name (most do, specifically because they know it needs a direct address record), use that. If you’re reusing a hostname that’s a CNAME for an unrelated purpose, publish a separate hostname with its own A/AAAA record for mail and update the MX record to point there instead, leaving the original CNAME untouched for whatever it was already aliasing. After changing it, re-run the MX lookup and wait out the record’s previous TTL before assuming the fix hasn’t taken effect — see DNS propagation and TTL explained for what controls that delay.
Next step
Run AdminKit’s MX lookup tool now to see exactly what your domain’s MX records currently resolve to, and confirm none of them land on a CNAME before mail delivery becomes inconsistent across different senders.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
Is an MX record pointing to a CNAME actually invalid, or just bad practice?
It's invalid per the DNS standard itself, not a style preference. RFC 2181 §10.3 states plainly that "the domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias." This sits alongside RFC 1034 §3.6.2's more general rule that a name carrying a CNAME record should carry no other data at all — the two rules together are why mixing CNAME into mail routing or delegation is treated as a configuration error, not a matter of taste.
Why does it sometimes seem to work anyway?
Some resolvers and mail transfer agents are lenient and will follow the CNAME to find an address anyway, which is exactly why this misconfiguration survives undetected for a long time. RFC 2181 itself notes the practical cost even when a lenient resolver cooperates: looking up an MX target skips the "additional section processing" a direct A/AAAA-bearing name gets, so a sender has to issue an extra DNS round-trip to follow the CNAME before it can even attempt to connect — and strict implementations may simply refuse to use the alias at all, failing delivery outright rather than working slowly.
What actually happens to mail when a receiver's resolver is strict about this?
The lookup for the MX target's address effectively comes back empty from that resolver's point of view, because it isn't willing to treat the CNAME as if it were the address holder. A sending server that can't resolve an MX host to an IP address has nothing to connect to, so mail queues, retries on the usual SMTP backoff schedule, and eventually bounces as undeliverable if the record isn't fixed before the sending server gives up.
How did my MX record end up pointing at a CNAME in the first place?
The most common path is reusing a hostname a third-party service already told you to alias for something else — a CDN, a marketing or tracking platform, or a "vanity" hostname a provider's onboarding instructions said to CNAME to their infrastructure — and then pointing the MX record at that same name instead of at the dedicated mail host the mail provider actually issued. It also shows up after a mail migration where the old setup is cleaned up in a hurry and a leftover alias gets reused by mistake.
What's the fix if my mail provider only gave me a hostname that happens to already be a CNAME somewhere else?
Ask the mail provider for the dedicated mail-host name they expect MX records to point at — reputable providers publish one specifically because they know it needs an A/AAAA record, not an alias. If a hostname is already in use as a CNAME target for something unrelated on your side, publish a separate hostname with its own A/AAAA record for mail and point the MX record at that instead, rather than trying to make one name serve both roles.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.
Talk to an expert
Huy Nguyen (David), Founder & CEO, Netbase JSC
Ask whether this fix applies to your setup, or get a second pair of eyes on your DNS and mail records.