MX record pointing to the wrong host: how to diagnose it in 5 minutes
TL;DR: A wrong MX record sends mail to a server that either no longer processes it, silently drops it, or bounces it back, and the symptom is usually confusing because it looks intermittent or provider-specific rather than obviously broken. Checking the actual current MX record against what it should be, directly via a lookup tool rather than through your email client, confirms or rules this out in under five minutes and is the correct first step before troubleshooting anything else.
Why this specifically happens after migrations
MX (Mail Exchange) records are a distinct DNS record type from the A records that point your website to a server, and this separation is exactly why a website migration can succeed perfectly while email quietly breaks, or vice versa. It is entirely possible to update your A record to point your domain's website at a new host while the MX record, still pointing at the old provider's mail servers, or at a mail service that was never actually migrated, continues sending mail to the wrong place indefinitely, since nothing about updating the A record touches MX at all.
This is especially common when a domain moves between hosts and the person handling the migration focuses on getting the website working (the visible, immediately-testable part) while email, easy to forget since it does not visibly "break" the same way a website does, gets missed until someone notices messages are not arriving.
It also happens when switching to a third-party email provider (Google Workspace, Microsoft 365) independently of any hosting change, where the MX record needs to point specifically at that provider's mail servers rather than at your web host's default mail handling, a step that is easy to get partially right (adding the new records) without fully completing (removing or correctly prioritizing against old, conflicting records).
The five-minute diagnostic
Step 1: Look up the domain's current MX records directly, using a dedicated MX record lookup tool rather than checking through your email client or webmail interface, since those show you what your specific mail service is configured to send from, not what the domain's public DNS is actually telling the world to deliver to. This distinction matters because your email client working normally for outgoing mail tells you nothing about whether incoming mail is being routed correctly.
Step 2: Compare what you see against what your actual current email provider requires. Every major provider (Google Workspace, Microsoft 365, a hosting company's own mail service) publishes the specific MX records they expect for correct configuration; check your provider's documentation for the exact expected values, since even a correct-looking record with a wrong priority number or a typo in the hostname will misroute mail despite looking approximately right at a glance.
Step 3: Check for duplicate or conflicting MX records. A common half-completed migration leaves both the old provider's MX records and the new provider's MX records published simultaneously, with mail servers then choosing between them based on priority values, which can result in some mail correctly routing to the new provider while other mail, depending on which record a given sending server's resolver happens to pick, keeps going to the old one, producing exactly the "it works sometimes" pattern that makes this hard to diagnose from symptoms alone.
Step 4: Confirm via a real test, not just a records check. Send a test email from an external account (not one hosted on the same domain) and confirm it arrives, since a correct-looking MX record combined with a misconfigured mail server on the receiving end can still fail delivery even when DNS itself is technically pointing to the right place.
What a correct MX setup looks like
A correctly configured MX setup has one or more MX records, each specifying a mail server hostname and a priority number (lower numbers indicate higher priority, the opposite of what the term intuitively suggests to many people), with all records pointing exclusively to your current, intended mail provider's servers, and no leftover records from a previous provider still present. Multiple MX records to the same provider (common with Google Workspace, which typically specifies several records at different priorities for redundancy) is normal and expected; multiple MX records pointing to entirely different, unrelated providers is the pattern that indicates a leftover misconfiguration.
Common wrong-MX patterns and what caused each
| Pattern observed | Likely cause |
|---|---|
| MX still points entirely to old host/provider | MX was never updated during migration |
| Mix of old and new provider's MX records | Migration added new records but did not remove old ones |
| MX points to new provider but priority values are wrong | New records added incorrectly, wrong priority ordering |
| MX points to a typo'd or non-existent hostname | Manual entry error during setup |
| MX record exists and looks correct, but mail still fails | Not an MX problem; check SPF/DKIM or the receiving server's own inbox configuration |
The fix, and the propagation wait after it
Once you have confirmed the actual cause, correcting MX records is usually a straightforward DNS edit: remove any leftover records from the previous provider and ensure the current provider's exact required records (hostname and priority) are published precisely as their documentation specifies, since even small deviations, an extra trailing character, an incorrect priority, can cause silent partial failures rather than an obvious error.
After correcting the records, expect the same propagation timing considerations that apply to any DNS change, governed by the TTL on the MX record specifically, which is often left at a longer default than web-facing records since MX changes are less frequent. Our DNS propagation guide covers the general timing mechanics; the practical guidance here is the same: lowering MX-specific TTL in advance of a planned change compresses the window meaningfully.
Avoiding a mail gap during the fix
If the old mail server referenced by the incorrect MX record still exists and is reachable (rather than fully decommissioned), mail sent during the propagation window after your fix may still route there for stragglers, so checking that old mailbox for a period after the fix, rather than assuming it is now irrelevant, prevents losing messages that arrived during the transition. If the old server has already been fully decommissioned or is unreachable, mail sent to it during the affected period is likely permanently lost or bounced back to the original sender, which is worth communicating proactively to important contacts if you know a significant gap occurred, rather than assuming they will notice and resend.
FAQs
My website works fine but I'm not receiving email. Could this be the cause?
Yes, this is exactly the classic symptom, since website (A record) and email (MX record) routing are entirely independent DNS configurations, and a migration or DNS change that correctly updated one while missing the other produces precisely this pattern.
I checked MX records and they look correct, but email is still failing. What else could it be?
Confirm the mail server the MX record points to is actually configured to accept mail for your domain specifically (a mismatch here, particularly common with shared or misconfigured mail hosting, produces a rejection even with correct DNS), and separately check SPF, since a receiving server rejecting mail due to failed sender authentication is a different problem from a misrouted MX record and requires a different fix.
How do I know which MX records are correct for my provider?
Check your specific email provider's official documentation directly (Google Workspace and Microsoft 365 both publish exact required MX values), rather than relying on a general guide or a value copied from another site's configuration, since exact hostnames and priorities can differ between provider account types and regions.
Can I have MX records from two different providers at the same time temporarily during a migration?
It is possible but risky, since mail servers may distribute delivery across all published records rather than exclusively using the intended one, particularly if priority values are equal or ambiguous, meaning some mail may go to a provider you are actively trying to move away from during the overlap period. A cleaner approach is completing the switch in one coordinated change rather than leaving both live for an extended period.
Does a wrong MX record affect outgoing mail too?
No, MX records govern incoming mail routing only, determining where mail addressed to your domain gets delivered; outgoing mail is controlled by your mail client or service's own outgoing (SMTP) configuration, which is separate and unaffected by MX record accuracy.
How long after fixing MX records will email start working again?
This follows standard DNS propagation timing for that specific record's TTL; a record with a shorter TTL clears from caches faster, while one left at a long default TTL can take up to that full duration for all resolvers to pick up the correction, which is why checking and setting a reasonable TTL on MX records specifically is worth doing as routine DNS hygiene, not just during an active fix.
Is there a way to test this without waiting for someone to email me?
Yes, an MX record lookup tool checked against multiple DNS resolver locations shows you the current state directly without waiting for a real message to test it, and combining that with a test send from an external account you control (rather than waiting on someone else) gives a faster, more controllable confirmation than waiting passively.
Conclusion
A wrong MX record is one of the fastest DNS issues to confirm and one of the easiest to overlook during a migration, precisely because email routing is invisible until it fails, unlike a website that visibly breaks the moment something is wrong. Checking the actual published MX record directly, rather than inferring from your email client's behavior, is the correct and fastest first step whenever email problems follow any domain, hosting, or provider change.
Look for leftover records from a previous provider specifically, since a half-completed migration that added new records without removing old ones is the single most common real-world pattern behind this failure, and it produces intermittent, confusing symptoms rather than an outright obvious break.
HostCloud's free MX Record Lookup tool checks your domain's current mail routing directly against multiple resolvers, and our migration support includes MX configuration as a standard step, not an afterthought. Try it at https://hostcloud.in/tools.