How does MX misconfiguration affect inbound mail?

Picture sending an important email to a colleague, and it bounces back two days later with a cryptic error. Or worse, it vanishes entirely and nobody ever knows it was lost. That's what MX misconfiguration feels like from the outside. Figuring out what actually went wrong requires knowing the different ways an MX record can break.

Your MX record tells the internet which mail server should receive email for your domain. When that record is wrong, missing, or pointing somewhere unreachable, inbound mail has nowhere to go.

Here's what each failure mode actually looks like.

Wrong server
Your MX record points to a hostname that exists but isn't your mail server anymore. This happens most often after migrations where someone updates the email platform but forgets to update DNS. Mail routes to the old server, which may reject it, silently discard it, or bounce it back to the sender days later. You might not notice until someone tells you they've been trying to reach you.

Unreachable server
The MX record points to a valid hostname, but the server at that address isn't responding. Senders will queue the message and retry (usually for 24 to 72 hours depending on their setup). If the server stays down long enough, the message bounces with a 421 or 450-class error. Brief outages often resolve quietly. Long ones cause genuine mail loss.

Missing record
No MX record at all means sending mail servers have nothing to connect to. Most will fall back to the domain's A record, which probably isn't a mail server either. The result is an immediate delivery failure and a hard bounce. This one's easy to spot because it affects everyone trying to reach you at once.

Typo in the hostname
A single wrong character in an MX record hostname is enough to break everything. The record exists, DNS resolves, but the target doesn't match any real server. This is one of the sneakiest failures because tools confirm the record is present without flagging that the hostname is nonsense. Always double-check the hostname manually after any DNS edit.

Priority misconfiguration
When you have multiple MX records, priority numbers tell senders which server to try first. Lower numbers mean higher priority. If your primary server has a higher priority number than your backup, senders hit the backup first. Mail still arrives (usually), but it's hitting a server that wasn't designed to be primary, which can cause capacity issues or missed filtering rules.

How to verify your MX records

The fastest way is to run a quick lookup. From your terminal, dig MX yourdomain.com or nslookup -type=MX yourdomain.com will return the current MX records as the world sees them. You're checking that the hostname is correct, the server is reachable, and the priority numbers are set the way you intended.

But if you prefer a browser tool, MXToolbox runs a full MX lookup and flags common problems for free. It'll show you what your record returns, whether the target resolves, and whether port 25 is open on that server.

After any DNS change, give records 24 to 48 hours to fully propagate, then run the check again from a different network or tool. Cached results can make a broken record look fine from your own machine right after a change.

So if you're seeing unexpected bounces and can't find the cause, our SOS hotline is free. We'll take a look and tell you what's actually going on.