Fix MX Record Pointing to Wrong Server After DNS Migration

After a DNS migration, an MX record can fail silently. The domain resolves and the website loads, but email keeps routing to a server nobody is checking.

This is common. DNS migrations touch dozens of records, and MX entries get missed, copied wrong, or left pointing at a host that no longer handles your mail. Here's how to find a wrong MX, fix it, and verify the fix actually worked.

What We're Fixing

By the end of this, you'll have:

• Confirmed whether your MX record is pointing to the correct server
• Identified if you're experiencing split delivery (some mail going to old host, some to new)
• Updated the MX record to your current email provider
• Verified propagation across multiple DNS resolvers
• Set up a test to confirm mail actually reaches the right inbox

If your MX record is completely missing rather than pointing to the wrong server, that's a different problem — our missing MX record guide covers that scenario. This one's about stale or wrong MX values after a migration.

Prerequisites

• Access to your DNS provider's control panel (Cloudflare, Namecheap, Route 53, wherever your nameservers point)
• Your current email provider's MX record values — grab these from their documentation or dashboard
• Terminal access for dig/nslookup, or use a web-based DNS lookup tool
• 10-15 minutes

Step 1: Check Your Current MX Record

First, find out what your MX record actually says. Not what you think it says — what the DNS system returns.

On Mac or Linux:

dig MX yourdomain.com +short

On Windows:

nslookup -type=MX yourdomain.com

You'll see output like:

10 mail.oldemailhost.com.

That number is the priority (lower = higher priority). The hostname after it is where mail gets routed.

Compare this to what your current email provider expects. For example:

If dig returns your old provider's hostname instead of your current one? That's the problem. Your domain is telling the world "send my email to Server X" while you're actually reading mail on Server Y.

Here's the thing: this silent failure is why MX records should be verified immediately after any DNS migration. Not a day later. Immediately. One missing email from a customer asking about pricing is all it takes to lose a deal you'll never know you lost.

Step 2: Understand Why This Happened

DNS migrations fail on MX records for a few reasons:

The new provider didn't import mail records. Cloudflare, for instance, attempts to scan and import existing records when you add a domain — but it prioritizes A, AAAA, and CNAME records. MX records sometimes get skipped. Or they import with values from six months ago.

You copied records from documentation, not your live zone. If you referenced a setup guide from six months ago instead of your actual DNS dashboard, you might have entered placeholder values or old hostnames.

The old provider had multiple MX records with different priorities. Google Workspace uses five MX records (ASPMX.L.GOOGLE.COM at priority 1, plus four ALT servers at priorities 5/10). If you only copied one, mail delivery becomes unreliable.

You changed email providers but forgot the DNS step. Switched from Zoho to JustEmails or from Google Workspace to Fastmail? The dashboard migration might be done, but DNS doesn't update itself.

TTL caching makes it look like nothing changed. You updated the record, but you're testing from a resolver that cached the old value. More on this in Step 4.

Step 3: Fix the MX Record in Your DNS Provider

Log into your current DNS provider — the one your domain's nameservers actually point to. If you're unsure, run:

dig NS yourdomain.com +short

This returns your authoritative nameservers. If you see ns1.cloudflare.com and ns2.cloudflare.com, you're managing DNS in Cloudflare.

Navigate to DNS records and find any existing MX entries. You need to either:

1. Delete the old MX record pointing to the previous host, then add the correct one
2. Edit the existing MX record to point to the correct hostname

For JustEmails, add:

The @ means the root domain (yourdomain.com). Priority 10 is standard for a single MX server. Lower numbers = higher priority if you have multiple MX records.

Common mistake: Adding the MX record for a subdomain instead of the root. If you're setting up mail.yourdomain.com as the record name, that's wrong — email to user@yourdomain.com won't route correctly. The name field should be @ or left blank (depending on your provider's UI).

Another thing: some providers auto-append the domain. If you enter mail1.justemails.app. with a trailing dot, good. If your provider shows the value as mail1.justemails.app.yourdomain.com after saving, you entered it wrong. The value should be the mail server hostname, not a subdomain of your domain.

Step 4: Wait for Propagation (Or Don't)

DNS changes don't take effect instantly. Every resolver on the internet caches DNS records based on their TTL (time-to-live). If your old MX had a TTL of 86400 seconds (24 hours), some resolvers might serve the stale record for up to a full day.

But here's what actually happens in practice: most major resolvers (Google's 8.8.8.8, Cloudflare's 1.1.1.1) respect TTL strictly, so they'll pick up your change fast. ISP resolvers? Less predictable. Corporate DNS servers with aggressive caching are total wildcards, and they can hold onto stale records for 72 hours despite a 1-hour TTL. Infuriating.

Check propagation across multiple resolvers:

# Google's resolver
dig @8.8.8.8 MX yourdomain.com +short

# Cloudflare's resolver
dig @1.1.1.1 MX yourdomain.com +short

# Your ISP's resolver (default)
dig MX yourdomain.com +short

If Google and Cloudflare show the new value but your ISP doesn't, give it time. If none of them show the new value after 30 minutes, double-check you saved the record correctly and that you're editing DNS in the right provider.

Web tools like whatsmydns.net check propagation from dozens of global locations. Useful for confirming worldwide propagation, especially if you have international users. For tracking uptime and domain health alongside your ad campaigns, ClickzProtect monitors your infrastructure while protecting ad spend from click fraud.

Step 5: Identify Split Delivery Issues

During propagation, you might experience split delivery: some senders hit your new MX, others hit the old one. This is the worst-case scenario because it's intermittent and hard to diagnose.

Signs of split delivery:

• Some emails arrive, others don't (no pattern to which senders fail)
• Users report "I sent you something yesterday" but nothing in your inbox
• Emails appear on your old provider's dashboard even though you've migrated
• Bounce-backs referencing a server you no longer use

If you still have access to the old email host, check its inbox. Any mail arriving there after your MX change is split delivery in action.

To minimize split delivery duration:

1. Lower the TTL before migration. If you're planning a DNS move, change your MX TTL to 300 (5 minutes) a day before. This means resolvers will check for updates more frequently.
2. Keep the old mailbox monitored for 48-72 hours. Forward anything that arrives to your new address manually, or set up a forwarding rule if the old provider supports it.
3. Send a test email from an external account (Gmail, Yahoo, etc.) and verify it arrives at the new host, not the old one.

Split delivery is temporary. But those 24-48 hours? They can lose important messages: invoice payments, job offers and support requests can all be missed in this gap. That's why migration weekend means checking both mailboxes. Annoying? Yes. Cheaper than losing business? Also yes.

Step 6: Verify Mail Actually Arrives

DNS looks correct? Great. But email delivery involves more than DNS. Let's confirm end-to-end delivery.

Send a test email from an external account (not from the same domain you're testing) to your migrated domain. Gmail to your-address@yourdomain.com, for example. If you're running outbound campaigns from a VeloCalls sales workflow, this verification ensures your reply-to address actually works.

Check:

1. Did it arrive in your inbox on the new provider? Not spam, not missing — actually in the inbox.
2. Check the email headers. Look for Received: headers showing the correct mail server handled delivery.

In Gmail, click the three dots → "Show original" and search for lines like:

Received: from mail1.justemails.app (...)

If you see your new provider's server in the Received chain, the routing is correct. If you see your old provider's server, something's still wrong — maybe you're looking at a cached page, or propagation isn't complete in your region.

While inbound is settling, line up the outbound side too. A daily send allowance counts from the moment a domain is verified rather than from the day the account was opened, so a freshly migrated domain begins at 20/day, moves to 200/day in its second week and reaches 500/day from day 15 — per account, with mailbox and API sends drawing on the same total. If the domain you just moved was pushing a few hundred messages a day at the old host, plan the first fortnight around that ramp rather than discovering it mid-week.

For authentication verification (SPF, DKIM, DMARC), the DMARC enforcement guide covers checking those headers specifically.

Common Errors and Fixes

"Mail delivery failed: Host not found"

The MX record points to a hostname that doesn't exist anymore. Your old provider decommissioned the server, or you have a typo. Verify the exact hostname from your email provider's documentation.

Emails bouncing with "relay access denied"

The MX is correct, but the receiving server doesn't recognize your domain. This happens when you update DNS but forget to add the domain to your new email provider's dashboard. In JustEmails, make sure the domain is added and verified in your account.

"Connection timed out" in bounce messages

The mail server IP is unreachable. Could be a firewall blocking port 25, or the server is actually down. Check your email provider's status page. If you're self-hosting, verify the server is running and port 25 is open inbound.

MX record shows correct server, but mail still goes to old host

Propagation lag. Some resolver somewhere is still serving the cached old record. Wait it out, or have the sender flush their local DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on Mac).

Multiple MX records with conflicting values

You added the new record but didn't delete the old one. Now you have two MX entries — one pointing to your new host at priority 10, one pointing to your old host at priority 20. Senders will try priority 10 first, but if it's slow or temporarily unreachable, they'll fall back to priority 20 (the old server). Delete the old record.

Preventing This on Future Migrations

A pre-migration checklist helps. Before any DNS move:

1. Export the current zone file or screenshot every record
2. Lower TTLs on MX and critical records to 300 seconds, 24 hours before migration
3. After migration, verify MX, SPF, DKIM (TXT records), and any CNAME/A records for webmail
4. Send test emails from three external accounts (Gmail, Yahoo, Outlook) to confirm delivery
5. Monitor the old mailbox for 72 hours
6. Raise TTLs back to normal values (3600 or higher) once confirmed stable

Total time investment: maybe an hour. Time saved not debugging "where did my email go" at 11 PM on a Sunday: infinite. Worth it every time.

For ongoing monitoring, tools like JustAnalytics can track domain health metrics, though for pure DNS monitoring there are dedicated services like DNSWatch or Updown.io.

Next Steps

Your MX is fixed. Mail is flowing to the right server. Now make sure the rest of your email infrastructure is solid:

• Verify SPF, DKIM, and DMARC — MX handles inbound routing, but authentication affects whether your outbound mail lands in inboxes or spam. Our custom domain email setup guide covers the full authentication stack.
• Set up monitoring — DNS changes can drift, especially if someone on your team makes edits without realizing the impact. Quarterly DNS audits catch issues before they become emergencies.
• Document your records — keep a copy of your expected MX, SPF, and DKIM values somewhere accessible. When the next migration happens, you'll thank yourself.

If you're managing email across multiple domains — agencies, multi-brand SaaS, portfolio sites — wrong MX records multiply fast. One migration mistake times ten domains equals a lot of lost mail. JustEmails handles unlimited domains under one account for $49/year, which at least keeps the "where is this domain's email hosted" question simple.

Questions about MX records or migration weirdness? Email support@justemails.app. Several MX records at the same priority from different providers make delivery unpredictable.

Frequently Asked Questions

Why is my MX record still pointing to my old email provider after DNS migration?

When you migrate DNS from one provider to another (GoDaddy to Cloudflare, for example), your existing DNS records don't automatically transfer. The new provider starts with a blank zone or imports only A/CNAME records. MX records often get left behind or imported with outdated values. You need to manually recreate them pointing to your current email host.

How do I check which server my MX record actually points to?

Run dig MX yourdomain.com +short on Mac/Linux or nslookup -type=MX yourdomain.com on Windows. The output shows your live MX records with priority numbers. Compare the hostnames to your current email provider's expected MX values. If you see your old provider's servers listed, the record needs updating.

What is split delivery and how do I know if it's happening?

Split delivery occurs when some mail servers have your new MX while others still have the old cached value. During this window, emails get delivered to both hosts depending on which DNS answer the sender's server received. Signs include sporadic missing emails (some arrive, some don't), emails appearing on your old host that should go to the new one, and users reporting "some people can reach me, others can't."

How long does it take for MX record changes to fully propagate?

DNS propagation depends on TTL (time-to-live) values. If your old MX had a TTL of 86400 (24 hours), some resolvers may cache that record for up to 24 hours after you make changes. Lower TTLs like 300 (5 minutes) propagate faster. Most changes are visible globally within 1-4 hours, but full propagation can take 24-48 hours for high-TTL records.

---

Try JustEmails

Unlimited custom domain email hosting for $49/year flat — unlimited domains, unlimited mailboxes, 10 GB storage, full IMAP/SMTP. Built for agencies, freelancers, and anyone managing email across more than one domain.

Start your 7-day free trial → · How it compares