MX records: how your mail is routed
MX (Mail eXchanger) records tell other mail servers where to deliver email for your domain. Each MX names a host and a preference number; lower numbers are tried first.
What the report checks
- That MX records exist and every nameserver agrees on the same set.
- That each MX target is a real hostname that resolves to a public address.
- That the set is consistent across all of your nameservers (a split view sends some mail to the wrong place).
No MX at all
If a domain has no MX, mail servers fall back to the domain's A/AAAA record. That is rarely what you want for a domain that receives mail, so publish explicit MX records.
How to fix it
Point your MX records at your mail provider's hosts, with the preferences they specify. For a domain on Google Workspace:
example.com. MX 1 aspmx.l.google.com.
Make sure the same records exist on every nameserver, and that the targets are hostnames (not IP addresses) with their own A/AAAA records.
- cPanel: Zone Editor, MX record type; check that "Email Routing" is set to remote if you use an external provider.
- Cloudflare: DNS, add MX records; the mail hostnames should be "DNS only" (grey cloud).
How to verify
dig example.com MX +short
Confirm the hosts and preferences, then resolve each host with dig <host> A +short.
Common mistakes
- Leaving cPanel on "Local" mail routing while using an external provider (Google, Microsoft 365), so the server tries to deliver mail to itself. Set Email Routing to "Remote Mail Exchanger."
- An MX pointing at a CNAME, which is invalid (see below).
- Nameservers disagreeing on the MX set after a change that did not reach every server, so some senders deliver to the old host.
- Proxying the mail host through a CDN (Cloudflare orange cloud) - mail hostnames must be "DNS only."