Skip to main content
MX records tell the internet which server handles email for your domain. Getting them wrong means mail either goes to the wrong place or bounces.
Three things have to agree, and mail breaks if any one of them is out of step:
  1. The MX record in whichever DNS your domain actually uses
  2. An A record for the mail hostname, pointing at your server’s IP address
  3. Email Routing in cPanel, set to Local or Remote to match

​
The standard setup

For a domain whose email is hosted here: Priority 0 is the highest priority, not the lowest. Lower numbers win.
The mail A record is the one people forget. An MX record pointing at mail.example.com is useless unless mail.example.com itself resolves to your server. If you have created the MX record and mail still fails, check the A record exists.
Use a domain-specific mail hostname — mail.yourdomain.com with its own A record — rather than a shared server hostname. It keeps working if your account moves server.

​
Where to make the change

  • DNS is here — cPanel → Zone Editor, or the Hosting Panel’s DNS settings
  • DNS is elsewhere — at that provider. Records you add in cPanel will not resolve if your nameservers point somewhere else

​
Email Routing: Local or Remote

cPanel needs to know whether it should accept mail for the domain itself or hand it on. Find it in cPanel under Email Routing.
If your DNS is managed externally and mail is handled elsewhere, set this to Remote Mail Exchanger. Left on Local, the server accepts mail for the domain and delivers it into a local mailbox that nobody reads, so it never reaches the real provider.
Equally, if mailboxes are here but routing is set to Remote, incoming mail is passed on to nowhere.

​
Website on one provider, email on another

A common setup: the site is on Wix, Squarespace or Vercel, and the mailboxes stay here. That works, but only if you split the records deliberately. If your nameservers point at us: Only touch the website records. Leave everything mail-related alone. If your nameservers point at the website provider — Wix, for example — then all of it is managed there:
  • Set the MX record to your mail hostname with priority 0
  • Add the mail A record pointing at your hosting server’s IP
  • Add an SPF TXT record that authorises your hosting server to send
See Email authentication: SPF, DKIM and DMARC for the SPF value to use.
Using Cloudflare? Set your mail and webmail records to DNS Only — the grey cloud, not the orange one. Proxying mail records through Cloudflare breaks email connections, because Cloudflare does not proxy SMTP.

​
Troubleshooting

​
Outgoing mail works, incoming does not

Almost always MX or routing. Check, in order:
  1. The MX record points where mail should actually go
  2. The mail A record exists and points at the right IP
  3. Email Routing matches — Local if mailboxes are here, Remote if not
  4. Your nameservers point where you think they do

​
451 errors, or senders saying verification failed

Some receiving servers do a sender verification callback to your MX before accepting your mail. If your public MX points at an external relay rather than your hosting server, that callback fails and legitimate mail is rejected with a 451. Fix: point the MX record at your own domain or a mail subdomain on your hosting server, priority 0.

​
New mailboxes never receive anything

If you have just moved hosting, the nameservers may still point at the old provider. New mailboxes here will not receive mail until the domain resolves to us. Allow 1 to 24 hours after a nameserver change.

​
MX points at a legacy mail service

If mail was previously on a separate platform — SmarterMail, for instance — and the MX records still point there while mailboxes are now on the web hosting server, or the reverse, inbound delivery fails. The MX has to match wherever the mailboxes actually are.

​
Records look right but the mail A record points at the wrong IP

Check the actual IP, not just that the record exists. After a server move or plan change, a mail A record left on the old address is a common cause of silent inbound failure.

​
No bounce at all, mail simply vanishes

Sometimes neither the sender nor the recipient sees an error. If your records check out, open a ticket with the sender’s address, the recipient’s address, the exact timestamp and any message headers you have, so we can trace the mail logs. See Emails are not arriving.

​
How long changes take

  • MX, A and TXT record changes — usually under an hour, but allow up to several hours to resolve everywhere
  • Nameserver changes — 1 to 24 hours
Local browser and network caching can delay you seeing the effect even after DNS has propagated globally, so verify with a DNS lookup tool rather than by refreshing your inbox.