MX Records Explained: How Email Routing Actually Works

Your website loads fine, SSL is green, but email to you@yourdomain.com bounces, arrives days late, or lands in the wrong inbox entirely. Nine times out of ten when a customer describes it that way, the culprit is an MX record — either missing, duplicated, or pointed at the wrong thing. MX records get far less attention than SPF or DKIM, but if they're wrong, none of the deliverability tuning in the world will save you.

What an MX Record Actually Does

An MX (Mail Exchanger) record tells the internet which mail server should receive email for your domain. When someone sends a message to you@yourdomain.com, their mail server doesn't look at your website's A record — it looks up your domain's MX records to find where incoming mail should be delivered.

Two things about MX records trip people up constantly:

• The value must be a hostname, never a bare IP address. mail.yourdomain.com is valid; 203.0.113.10 is not, even though most panels will let you type it in and only fail silently later.
• The priority number is backwards from what people expect. Lower numbers are tried first. An MX with priority 10 is preferred over one with priority 20, not the other way around.

How to Check Your Current MX Records

Don't trust what's cached in your browser or a panel that hasn't refreshed. Query it directly:

dig MX yourdomain.com +short

A healthy result for a domain using Google Workspace looks like this:

1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.

In cPanel, the same records live under Domains → Zone Editor → Manage → MX. If you manage DNS outside cPanel (say the domain's nameservers point elsewhere), check that provider's zone instead — editing MX in cPanel does nothing if cPanel isn't authoritative for the zone.

Common MX Misconfigurations We See

MX pointing to a CNAME

Symptom: mail bounces from some providers but not others, or delivery is wildly inconsistent.

Cause: RFC 2181 explicitly forbids an MX record from pointing at a CNAME. Some mail servers tolerate it anyway; strict ones (a lot of enterprise mail filters) reject the message outright with something like "MX points to CNAME."

Fix: point the MX at the real A/AAAA-backed hostname, not an alias. If mail.yourdomain.com is a CNAME to ghs.googlehosted.com, that's the bug — use the provider's actual MX hostname instead.

Old provider's MX records never removed

Symptom: some emails go to the new mailbox, others seem to vanish, and old logins still occasionally receive mail.

Cause: this happens constantly during migrations — you add the new provider's MX records but never delete the old host's. Now two servers are both willing to accept mail for your domain, and which one wins depends on priority and which server responds first.

Fix: before adding a new MX, list every existing MX record and delete anything that doesn't belong to the provider you're moving to. Don't "add on top."

Backup MX has a lower priority number than primary

Symptom: most inbound mail lands on what's supposed to be your backup or spam-catch server, and the primary mailbox is oddly quiet.

Cause: priority got entered backwards. Remember: lower number = tried first.

Fix: swap the numbers so the real primary carries the lowest priority value.

cPanel still set to "Local Mail Exchanger" after moving mail off-server

Symptom: you switched to Google Workspace or Zoho, but cPanel webmail still silently receives a copy of some mail, and password-reset emails or contact-form mail never reach the new inbox.

Cause: under Email → Email Routing in cPanel, the domain is still marked Local Mail Exchanger, so the server keeps trying to deliver locally regardless of what your public MX records say for the outside world.

Fix: change it to Remote Mail Exchanger once external mail is confirmed working, so the local server stops competing for delivery.

Step-by-Step: Fixing a Broken MX Setup

1. Run dig MX yourdomain.com +short from a machine outside your network — don't rely on a panel's cached view.
2. Compare the output line by line against the exact values your mail provider's documentation lists. Copy-paste, don't retype.
3. Delete any MX record that isn't in that list, especially ones left over from a previous host or a trial signup.
4. Set priorities so the intended primary has the lowest number.
5. In cPanel, set Email Routing to match reality (Remote if mail lives elsewhere, Local only if cPanel is the mailbox).
6. Drop the MX record's TTL to something like 300 seconds a day before a planned change, then raise it back to a normal value (3600+) once the new records are confirmed stable.
7. Send test mail from an external address (Gmail is a good neutral test) and check headers for the receiving server, not just "it arrived."

Why Multiple MX Records Exist

Redundancy, mostly. If your primary mail server is down for maintenance, a sending server will retry against the next-lowest-priority MX instead of bouncing immediately. Two records sharing the same priority number act as round robin — load gets split between them rather than one being preferred.

One thing worth knowing: some spammers specifically target the highest-priority-number (lowest-preference) MX in a domain's list, assuming it's a less-monitored backup server with weaker spam filtering. If you run your own backup mail server, make sure it enforces the same SPF/DKIM/DMARC checks as your primary — don't leave the back door unlocked.

Prevention Checklist

• Never point an MX at a CNAME — always a hostname backed by an A/AAAA record.
• When switching mail providers, remove the old MX records in the same change that adds the new ones.
• Double-check priority direction before saving — lower number wins.
• Match cPanel's Email Routing setting to where mail actually lives.
• Lower TTL ahead of any planned MX change, and confirm with dig from outside your network before calling it done.