MX Cutover Troubleshooting: Why Mail Still Hits the Old Server

You updated your MX records hours ago, but test messages still arrive at your old mailbox, or don't arrive at all. Before you start changing things again, work out which situation you are in. Some delay is normal DNS caching that will clear without help. Some is a configuration mistake that will never fix itself. This guide shows you how to tell them apart.

Three situations that look the same

When mail goes to the wrong place after an MX change, the cause is almost always one of these:

• Caching: resolvers around the internet still hold your old MX answer and will keep it until its TTL expires.
• The change never happened where it counts: you edited records at a provider that isn't authoritative for your domain.
• The change happened, but it's wrong: a typo, a leftover record or a malformed hostname.

Only the first one fixes itself. The other two need you to act, so rule them out first.

Step 1: Confirm which nameservers are authoritative

Many domains have DNS zones at more than one company. A typical case is a registrar that offers DNS while the domain actually uses nameservers at a CDN or hosting provider. Edits made in the unused panel do nothing.

Check the delegation:

• dig NS example.com +short

If the nameservers returned don't belong to the provider where you made the change, you've found the problem. Make the change in the right panel, or move the domain's nameservers on purpose.

Step 2: Ask the authoritative server directly

Next, query one of those nameservers directly. This skips every cache and shows what your zone really contains right now:

• dig @ns1.your-dns-provider.com MX example.com

For MXcatch, you should see exactly two records: 10 mx1.mxcatch.net. and 20 mx2.mxcatch.net. If the authoritative answer is correct, your zone is fine and any remaining problem is caching. If it's wrong, no amount of waiting will help.

Step 3: Look for the usual misconfigurations

When the authoritative answer looks off, check for these common mistakes:

• Old MX records left in place. Sending servers try the lowest priority number first, but they will fall back to any record you leave behind. An old provider's record at priority 5 will take mail ahead of yours. Delete records you no longer use.
• Hostname with your domain appended. Some DNS panels treat a name without a trailing dot as relative. The result is mx1.mxcatch.net.example.com. Look for that in the dig output and fix it by adding the trailing dot or following your provider's format.
• Record on the wrong host. If you want mail for you@example.com, the MX belongs on the root of the domain, often shown as @. Don't put it on www or mail.
• An IP address instead of a hostname. MX records must point to a hostname, not an IP.
• A CNAME on the same name. A CNAME can't coexist with other records on the same name, and some providers handle this conflict in ways you won't expect.

Step 4: Read the TTL to estimate the wait

If the authoritative data is correct, the question is how long caches will keep the old answer. The TTL that matters is the one on the old records, because that is what resolvers cached. If the old MX had a TTL of 86400 seconds, some resolvers may hold it for up to a day after your change.

When you query a public resolver, the TTL in the answer counts down. It shows how much time that cache has left:

• dig @8.8.8.8 MX example.com
• dig @1.1.1.1 MX example.com

Run each command twice, a minute apart. A falling number means you're seeing a cached copy. For your next migration, lower the TTL a day or so before the change, then raise it again once things are stable.

Step 5: Check from outside your own network

Your laptop, office router and ISP all cache DNS, and some corporate networks override public answers. A clean result on your machine proves little, and so does a stale one. Check from somewhere else. The public resolvers above are one option. You can also use DomainScope's free domain and DNS lookup tools, which show MX, NS and SOA records with TTL values from outside your network. The WHOIS lookup there also lists the nameservers on record at the registrar, which helps with Step 1.

What happens to mail during the switch

While caches expire, some senders will deliver to your old provider and some to the new one. Keep the old mailbox active until the old TTL has fully passed and traffic there has stopped. Messages can still trickle in later from servers that queued them. Sending servers usually retry when a destination is temporarily unavailable, but don't rely on that to cover a mistake. Check your old inbox for stragglers before you close it.

Confirm with a real message

DNS lookups tell you where mail should go. A test email tells you where it actually goes. Send messages from a couple of external providers, not from inside the domain you're migrating. Then confirm they appear in your MXcatch inbox or trigger the webhook or forward you set up. Once those land, and the authoritative and public answers match, the cutover is done.