MX records in depth: priority, several mail servers and the mistakes that lose e-mail

Domains & DNS·· 4 views· 4 min read

The short answer: the MX record tells other servers where to deliver your domain’s mail. Each MX has a priority (a number) and the name of a server. Senders try the lowest number first. Trouble starts when there are too many MX records, from different providers, or pointing at the wrong place: mail does not vanish all at once, it leaks away bit by bit, which is why it is hard to track down.

How the MX rules work

Situation What happens
Two MX records, priorities 10 and 20 Senders try 10. They only use 20 if 10 does not answer. The numbers themselves do not matter, only the order.
Two MX records with the same priority Senders pick either one, in no fixed order. Both must deliver to the same mailboxes.
MX records from two different providers (say, your hosting and Google) Mail splits: some messages go to one, some to the other. It looks like e-mails are lost.
No MX at all By the standard, senders try to deliver to the domain’s own address (its A record). It may work by accident, but do not rely on it.
MX 0 . (the null MX) States outright that the domain accepts no mail (RFC 7505). Senders give up at once and bounce the message.
MX pointing at an IP address Invalid. An MX points at a name, and that name has its own A or AAAA record.
MX pointing at a name that is a CNAME Forbidden by the standard. Many servers accept it anyway, some do not: mail that fails only sometimes.

Checking and fixing your MX records

1 List the MX records: dig example.com MX +short
10 mail.example.com.
Each line is the priority and the server. Check that only servers from the mail provider you use today appear. (example: example.com is a domain reserved for examples, and 192.0.2.10 and 2001:db8::10 are documentation addresses; replace them with yours.)
2 Check each server on the list: dig mail.example.com A +short must return an IP, and dig mail.example.com CNAME +short should come back empty.
3 Delete MX records for providers you no longer use. In cPanel, in the Zone Editor, under Manage next to the domain. Keep only one provider’s records.
4 If your mail lives outside the hosting (Google Workspace, Microsoft 365 or another), open Email Routing in cPanel and choose the remote server. Without that, messages the website itself sends to your domain (contact forms, for example) can be delivered on the hosting and never reach the real mailbox. See Google Workspace or Microsoft 365 on your own domain.
5 After changing MX records, watch both mailboxes for as long as the old MX’s TTL: until then, some servers still deliver to the old place. Do not delete the old mailbox before that.
A backup MX at another provider is rarely worth it today. Senders already keep retrying for a while when your server is down (each server decides how long). And a backup MX that does not know which mailboxes exist accepts spam for made-up addresses and then bounces it to forged senders, which can land your domain on blocklists.
A domain that never receives mail (it only has the website) is better protected with the null MX, 0 .. If it never sends either, add an SPF record that says so: creating your SPF record.

Mail reaches some mailboxes and not others, or only sometimes? Tell us the domain and an example of a message that did not arrive.

Open a support ticket

SEE ALSO

DNS records explained: A, CNAME, MX, TXT and TTL

Google Workspace or Microsoft 365 on your own domain: MX records, and keeping your website with us

Why your e-mail is not sending or receiving

Creating your SPF record, step by step

PTR and reverse DNS: why your e-mail depends on it

TXT records in practice: long values, quotes and several records on one name

RECOMMENDED PRODUCT

Professional e-mail on your domain

Mailboxes in your company name, no adverts, with spam filtering. from $6.59/mo (3-year plan, with coupon)

See plans
Was this answer helpful? Your answer helps us improve this article.