An MX record whose target is a CNAME is invalid. RFC 2181 §10.3 says the host name in an MX record “must not be an alias”, and some mail servers follow the alias while others refuse to deliver, so mail reaches you from some senders and bounces or stalls from others. Fix it by pointing the MX at the final hostname, the one that has A or AAAA records, or by turning the alias name into an A/AAAA record. Run the MX lookup on your domain to see which target it flags.
A broken setup looks like this:
example.com. 3600 IN MX 10 mail.example.com.
mail.example.com. 3600 IN CNAME ghs.provider.example.
A working setup points the MX at a name that resolves to addresses:
example.com. 3600 IN MX 10 mx1.provider.example.
If you copied mx1.provider.example from your mail provider’s documentation, use it exactly as written there.
Why it is invalid
RFC 2181 §10.3 forbids an alias as the target of an MX (or NS) record. RFC 5321 §5.1, which governs mail delivery, requires the MX data field to contain a domain name that, when queried, “MUST return at least one address record (e.g., A or AAAA RR)”. The same section says that a value “that will return a CNAME record when queried, lies outside the scope of this Standard”. In other words, the standard does not define what a sender should do, and implementations differ. The same RFC also says that if a CNAME is found while looking up the name, the resulting name is processed as if it were the initial name, which is why some servers cope with it.
The result is unpredictable behavior: a large sender may follow the alias and deliver, while a smaller or stricter server logs a permanent failure. This is hard to debug because your own test mail may arrive.
Symptoms
| What you see | Likely meaning |
|---|---|
| Mail from Gmail arrives, but some corporate senders get a bounce | Sender software does not follow aliases |
| Bounce text such as “Host or domain name not found” or “MX points to a CNAME” | The sender flagged the alias |
| Messages sit in the sender’s queue for days | The sender treats the lookup as a temporary failure and retries |
| MX lookup shows a target that also appears as CNAME in DNS lookup | The record described on this page |
Bounce wording differs between mail servers, so treat these as examples rather than exact strings.
How to fix it
- Query the MX with the MX lookup, then query each target with the DNS lookup for type
AandCNAME. A target that returns a CNAME is the problem. - Follow the CNAME chain to its end. The last name that returns A or AAAA records is the real host.
- Choose one of two edits:
- Change the MX to the real host. Use this when the host belongs to your mail provider and the provider documents it.
- Delete the CNAME and create A (and AAAA) records with the same name, pointing at your own mail server’s addresses. Use this when the name is yours, such as
mail.example.com.
- Keep the old TTL in mind. Resolvers cache the earlier answer until the TTL runs out, so mail can still take the old path for up to that time.
Do not use an IP address as the MX target either; the field takes a hostname. See How to set up MX records for priorities and the full list of allowed targets.
The apex variant
A different mistake looks similar: a CNAME on the domain name itself (example.com). A name that has a CNAME cannot hold other record types, so MX, NS and TXT records at that name conflict with it (RFC 1034 §3.6.2: “If a CNAME RR is present at a node, no other data should be present.”). If your website host asked you to add a CNAME at @, ask for an A record or an ALIAS/ANAME-style feature at your DNS host instead. Those flatten to addresses at the DNS host and are not a CNAME on the wire. They are a DNS-host feature, not a standard record type, so check your host’s documentation.
FAQ
My provider told me to create a CNAME for mail. Is that an MX target? Providers use CNAMEs for things such as DKIM keys or tracking domains. Those are fine. The restriction applies to the name an MX record points to.
Will it work if I point the MX at a CNAME and test from Gmail? It might, and that is the trap. Passing from one sender proves nothing about the others.
Does the same rule apply to NS records? Yes. RFC 2181 §10.3 covers both MX and NS targets.
Sources
- RFC 2181, §10.3 MX and NS records: https://www.rfc-editor.org/rfc/rfc2181#section-10.3
- RFC 5321, §5.1 Locating the Target Host: https://www.rfc-editor.org/rfc/rfc5321#section-5.1
- RFC 1034, §3.6.2 Aliases and canonical names: https://www.rfc-editor.org/rfc/rfc1034#section-3.6.2