MX (mail exchanger) records tell the world which servers accept email for your domain. When a domain has several MX records, the priority number decides which server senders try first. This guide explains MX record priority, load sharing and whether you still need a backup MX.
Before you start
Check your current MX records with dig example.com MX +short or in cPanel → Email → Email Routing and the Zone Editor.
How MX priority works
example.com. 3600 IN MX 10 mx1.example.com.
example.com. 3600 IN MX 20 mx2.example.com.- Lower number = higher priority. Senders try
mx1(10) first. - If
mx1is unreachable or returns a temporary error, they trymx2(20). - If all fail, the sending server queues the message and retries for days.
The numbers themselves don't matter, only their order – 10/20 works the same as 1/5.
Equal priorities share the load
example.com. IN MX 10 mx1.example.com.
example.com. IN MX 10 mx2.example.com.Senders pick randomly between servers with the same priority, spreading incoming mail. Both servers must be able to deliver to the same mailboxes.
Do you need a backup MX?
Historically, a secondary MX accepted and queued mail while the primary was down. Today it's often unnecessary or even harmful:
- Senders already retry for several days when your server is down, so mail isn't lost during short outages.
- Spam magnet – spammers target backup MXs because they often have weaker filtering and don't know which mailboxes exist, causing backscatter.
- Useful when the backup has the same spam filtering and recipient validation as the primary, or for very long outage protection with a managed queuing service.
Rules for MX records
- MX targets must be hostnames with A/AAAA records – never an IP address and never a CNAME.
- Every MX target should have matching reverse DNS (PTR) and a valid TLS certificate.
- Remove MX records for services you no longer use – senders will keep trying them.
- A domain with no MX falls back to its A record; publish a "null MX" (
MX 0 .) for domains that should never receive mail.
Local vs remote mail on cPanel
When MX points elsewhere (for example to Google Workspace or Microsoft 365), set cPanel → Email → Email Routing to Remote Mail Exchanger. Otherwise the server delivers mail from local scripts to its own mailboxes instead of your real provider.
Troubleshooting
- Mail goes to the old provider: old MX records still exist or are cached – remove them and wait out the TTL.
- Website forms' mail never arrives: Email Routing is set to Local while MX is remote.
- "MX points to CNAME" warnings: point MX to the canonical hostname instead.
FAQ: MX priority
What priority should my main mail server have?
Any number lower than the others; 10 is conventional, or 0 when it is the only server.
Can MX point to a different domain?
Yes, e.g. MX 10 mx.provider.example. – that's how hosted email services work.
How fast do MX changes take effect?
After the record's TTL expires on resolvers – lower it in advance before a migration.