Three weeks after moving our DNS from GoDaddy to Cloudflare, a client emailed me asking why I never replied to their proposal. I checked my inbox. Nothing. Checked spam. Nothing. Then I logged into the old GoDaddy email dashboard we'd abandoned — and there it was. Their email, plus seven others from the past week, all sitting in a mailbox nobody was monitoring.

The MX record migration had failed silently. Or rather, I'd failed to migrate it at all. The domain was resolving through Cloudflare, the website was live, but email was still routing to a server we'd stopped checking.

This happens constantly. 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:

Provider	Expected MX Record
JustEmails	`mx.justemails.app`
Google Workspace	`ASPMX.L.GOOGLE.COM` (plus alternates)
Microsoft 365	`yourdomain-com.mail.protection.outlook.com`
Zoho Mail	`mx.zoho.com` (or regional variants)

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 I always verify MX records 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. Ask me how I know.

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. (I once spent 40 minutes convinced my DNS change hadn't saved. It had. My ISP's resolver was just being slow.) If you're managing infrastructure across multiple projects, tools like DevOS can help track DNS changes as part of your deployment workflow.

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:

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

For JustEmails, add:

Type	Name	Priority	Value
MX	@	10	`mx.justemails.app`

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 mx.justemails.app. with a trailing dot, good. If your provider shows the value as mx.justemails.app.yourdomain.com after saving, you entered it wrong. The value should be the mail server hostname, not a subdomain of your domain. I've made this exact mistake more than once — it's embarrassing how long it took me to notice.

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 — I've seen them 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:

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.
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.
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. I've seen people miss invoice payments, job offers, and support requests because of this gap. One client missed a $12,000 contract renewal email. It's why I always tell people: 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:

Did it arrive in your inbox on the new provider? Not spam, not missing — actually in the inbox.
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 mx.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.

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

Look, I'm not the most organized person. But I keep a pre-migration checklist in Notion because I got burned enough times. Before any DNS move:

Export the current zone file or screenshot every record
Lower TTLs on MX and critical records to 300 seconds, 24 hours before migration
After migration, verify MX, SPF, DKIM (TXT records), and any CNAME/A records for webmail
Send test emails from three external accounts (Gmail, Yahoo, Outlook) to confirm delivery
Monitor the old mailbox for 72 hours
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. We've seen the edge cases. The one where a domain had three MX records from three different providers, all with priority 10? Mail was basically playing roulette. That was a fun afternoon. (It wasn't.)

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

Fix MX Record Pointing to Wrong Server After DNS Migration