MX record points to a CNAME or an IP address: why it is invalid

What it means

The MX record tells other mail servers where to deliver email for your domain. Its value is a priority and a host name, for example 10 mail.yourdomain.com. That host name must have its own A (IPv4) or AAAA (IPv6) record.

Two mistakes are common:

• MX pointing to an IP address: yourdomain.com MX 10 203.0.113.25. This is not allowed: RFC 5321 says the MX value is a domain name, and an address there is not valid.
• MX pointing to a CNAME: the MX target mail.yourdomain.com is itself a CNAME to another name. RFC 2181 (section 10.3) says the MX target must not be an alias.

Why it happens

• A DNS panel lets you type an IP in the MX field, or someone thought it was simpler.
• Some panels treat the IP as a relative name and publish 203.0.113.25.yourdomain.com, which does not exist.
• The mail host was set as a CNAME to the hosting company's server name (for example mail CNAME server12.host.example) to avoid updating IPs.
• A provider's documentation was copied into the wrong record type.

What happens in practice

• IP in the MX: many sending servers cannot find a host name and fail. Some fall back to the domain's A record (the website server), which usually does not accept mail. Results are unpredictable: some senders deliver, others bounce, often with messages such as "Domain not found", "No MX for domain" or "Host or domain name not found".
• CNAME as MX target: many servers follow the alias and deliver anyway, which is why the mistake goes unnoticed. But it is non-standard, some strict servers and validators reject it, and it adds an extra lookup that can fail.

A domain with no MX at all is a different problem, covered in no MX record on your domain.

How to check

1. Open the domain scanner and enter your domain. It lists your MX records and their targets.
2. With dig:

   dig MX yourdomain.com +short
   10 mail.yourdomain.com.
   
   dig CNAME mail.yourdomain.com +short
   (must be empty)
   
   dig A mail.yourdomain.com +short
   203.0.113.25

   If the MX answer is a number like 203.0.113.25., or if dig CNAME on the target returns a name, you have one of the problems above.
3. On Windows: nslookup -type=MX yourdomain.com.
4. Test the server itself: nc -v mail.yourdomain.com 25 should show a 220 greeting.

How to fix it

MX pointing to an IP

1. Create an A record (and AAAA if you use IPv6) for a mail host name:

   Host: mail      Type: A      Value: 203.0.113.25

2. Change the MX to use that name:

   Host: @         Type: MX     Priority: 10     Value: mail.yourdomain.com

   Some panels need a trailing dot (mail.yourdomain.com.), others add the domain for you; check what your panel shows after saving.

MX target is a CNAME

Replace the CNAME on the mail host by A/AAAA records with the server's IP, or point the MX directly at the real host name your provider gives (the one that has the A record):

Before:
yourdomain.com.        MX 10  mail.yourdomain.com.
mail.yourdomain.com.   CNAME  server12.host.example.

After (option 1):
mail.yourdomain.com.   A      203.0.113.25

After (option 2):
yourdomain.com.        MX 10  server12.host.example.

If you use Google Workspace, Microsoft 365 or another provider, use exactly the MX values from their setup page. Also make sure the mail host is not proxied by a CDN (see Cloudflare proxied records break email) and that its name has no other conflicting CNAME (see CNAME conflicts with MX and TXT records).

Your own server

Ideally the MX host name matches the server's reverse DNS (PTR) and TLS certificate name, for example mail.yourdomain.com everywhere.

Check that it is fixed

Wait for the old MX TTL to expire, then run dig MX again and check the result in the domain scanner. Send an email from an outside mailbox (Gmail, Outlook) to an address on your domain and confirm it arrives. If your server also sends, run a Delivmail test from it to check SPF, DKIM and reverse DNS.