An MX record tells other mail servers where to deliver mail for your domain. It is the only DNS record that decides whether email arrives, and it is entirely separate from the records that decide whether the website loads, which is why one can break without the other.
What one looks like
Name Type Priority Value @ MX 0 mail.example.com
The value is a hostname, not an IP address. Putting an address there produces a record that looks plausible and does not work, mail servers will not follow it.
That hostname must itself resolve, via its own A record. An MX pointing at a name with no A record is a dead end, and this is a genuinely common mistake when a zone has been rebuilt.
Priority: lower wins
The number is a preference, and smaller means preferred. Sending servers try the lowest first and fall back to higher ones if it does not answer.
@ MX 10 mail1.provider.com @ MX 20 mail2.provider.com
Mail goes to mail1; mail2 receives it only when the first is unreachable.
Two records at the same priority split traffic between them, which providers use deliberately for load sharing. Do that only when a provider tells you to, setting equal priorities by accident means half your mail goes to a server that may not be configured for it.
The absolute numbers do not matter, only their order. 10 and 20 is conventional; 0 and 1 works identically.
Moving mail to an external provider
The usual request. A client moves to a hosted mail service and needs the MX records changed.
Delete the existing MX records and add the ones the provider gives you, with their priorities exactly as specified. Then add their SPF record as a TXT record, and their DKIM record if they provide one: without those, mail sent through the new provider will be treated as suspect.
Then do the step that gets missed.
Set mail routing to remote
Changing MX records tells the outside world where to deliver. It does not tell your own server to stop handling mail for the domain.
So the server keeps believing it is the destination. Anything sent by a script on that server (a contact form, an order confirmation, a password reset) is delivered into a local mailbox instead of going out to the external provider.
External mail works perfectly. Messages from the website vanish. The client tests by emailing themselves from Gmail, it arrives, and everything looks fine, until someone notices no enquiries have come through for three weeks.
In cPanel, open Email Routing and set the domain to Remote Mail Exchanger. One setting, and it is the difference between a working migration and a silent one.
Verify
dig MX example.com
Check the hostnames and priorities match what the provider specified. Then confirm each hostname resolves:
dig mail1.provider.com
Finally send a real message from an outside address and confirm it arrives, and submit the website's contact form and confirm that arrives too. Those are two different paths and testing one proves nothing about the other.
Common problems
Mail stopped after a nameserver change. The MX records were not recreated on the new provider. This is the most predictable failure in all of DNS. A nameserver change hands the zone to a new provider that starts from defaults, and custom MX records are not carried across.
MX points at an IP address. It must be a hostname. Add an A record for a hostname and point the MX at that.
MX hostname does not resolve. Dead end. Mail bounces with a message about the domain not being found.
Both old and new MX records present. Mail goes to whichever has the lower priority, intermittently, depending on which servers have which cached. Remove the old ones.
External mail works, website mail vanishes. Mail routing is still local. Set it to remote.
Mail arrives but lands in spam. Not an MX problem. SPF, DKIM and DMARC are missing or reference the old provider. For that, see understanding SPF, DKIM and DMARC.
If mail is handled here
When mail stays on your hosting account, the MX records are created automatically and there is nothing to configure. Leave them alone.
The only reason to open this screen in that case is when mail has stopped, and then the first thing to check is not the record but the account quota, because a full account rejects mail regardless of DNS. The email troubleshooting guide goes into that order.
If those records are pointing at a provider outside your hosting, there is one setting on the account that must change too. How to Use an External Mail Provider with Your Domain goes into it.
Website here and email elsewhere is routine, and it fails in one specific way that the DNS does not show. How to Split DNS Between Website and Email Providers has the detail.
Read every record, not the first one
Mail delivery problems frequently come from a record that is present in addition to the correct one rather than instead of it.
dig example.com MX +short | sort -n dig example.com MX @8.8.8.8 +short | sort -n dig example.com A +short
A leftover entry from a previous provider with a low priority number receives mail before your current provider does. The result is mail that arrives sometimes and disappears otherwise, which reads as an intermittent fault rather than a configuration one.
Comparing your own view with a public resolver's is worth doing, since a change made recently may be visible locally and not yet elsewhere. If they disagree, the answer is to wait rather than to change anything further.
The hostnames the records point to
A mail record must name a host, and several rules about that host are easy to break.
for h in $(dig example.com MX +short | awk '{print $2}'); do
printf '%-32s %s\n' "$h" "$(dig +short "$h" A | tr '\n' ' ')"
done
Each name must resolve to an address. A record naming a host with no address is a delivery failure, and it is invisible unless you follow the chain.
The name must also be a name rather than an address, and it must not point at an alias. Both are technically invalid and both are accepted by many providers, which means they work until they meet one that enforces the rule.
Two providers, and why that usually goes wrong
Listing records for two different mail systems does not share the load between them. It creates two independent destinations that know nothing about each other.
Mail arrives at whichever answers, mailboxes exist in one and not the other, and a message delivered to the wrong side is not forwarded. Users see mail appearing in one client and not another with no pattern.
dig example.com MX +short | awk '{print $2}' | sed 's/\..*//' | sort -u
If that returns names belonging to two different companies, the configuration is almost certainly a mistake rather than a design. Pick one, remove the other, and let the change propagate before judging whether it worked. Splitting DNS between website and email providers deals with the arrangement that does work.
