MX Record Points to Wrong Server: Find and Fix It

Your mail can vanish because one DNS value is stale

A bad MX record is quiet. Your website still loads. Outbound mail may still send. But replies, invoices, password resets, and support mail can land at an old provider no one checks.

MX records tell other mail servers where to deliver inbound email for a domain. If they point to the wrong host, senders will try that host because DNS says it is responsible for your mail. They do not know that you moved from Google Workspace to Microsoft 365, left a trial mail host behind, or copied a value from another domain.

Start by checking the live MX records for the exact domain that receives mail. Look for the provider name, the priority number, and any old hosts. Lower priority numbers are tried first. If you use one mail provider, all MX records should usually match that provider's setup page. If you see two providers mixed together, that is a common cause of lost mail, delayed mail, or mail split between systems.

• Run an MX lookup for your domain, such as example.com, not www.example.com.
• Compare every returned host with your current mail provider's official DNS instructions.
• Remove old MX records from a former host, registrar parking service, website builder, or cPanel mailbox.
• Use the provider's exact target value. Microsoft 365 uses a domain-specific mail.protection.outlook.com host. Google Workspace uses the MX values shown in Google's setup instructions.
• Keep backup MX records only when your provider tells you to. Random backup hosts can accept mail and hide the real problem.

Fix the record in the right DNS zone

The right value in the wrong dashboard changes nothing. Edit the DNS zone served by the domain's authoritative nameservers.

Find the domain's nameservers, then edit MX records where those nameservers are managed. Delete the wrong MX values and add the correct ones from your current provider. Keep the priority values exactly as the provider gives them. A trailing dot at the end of a host name is normal in many DNS tools, but some dashboards add it for you.

After saving, wait for the old TTL and resolver cache to age out, then check again from more than one resolver. New lookups should show only the expected provider. Then send a test from Gmail, Outlook, and one other outside mailbox. Reply to that message too. That tests the path real users take.

If you want a quick outside check, run the domain through the free InboxRadar scorecard. It reads live MX, SPF, DKIM, and DMARC records and shows the exact record that looks wrong.

Recheck authentication after a mail move

MX handles inbound routing. SPF, DKIM, and DMARC help receivers decide whether mail claiming to be from your domain can be trusted.

SPF is a TXT record that authorizes servers for the envelope sender or HELO domain checked by SPF. Publish only one SPF record at each DNS name. Use the includes or IP ranges your sending providers give you. Stay under the SPF 10 DNS-lookup limit in RFC 7208. End with ~all while testing or -all when you have confirmed every real sender is covered.

DKIM signs outgoing mail. Turn it on inside the service that sends your mail, then publish the selector records it gives you. A selector is part of the DNS name, such as selector1._domainkey. The receiver uses that selector and signing domain to find the public key. If you change providers, old selectors may stay in DNS, but the new provider must sign mail with its own active selector.

DMARC uses the visible From domain. A message passes DMARC when SPF passes and aligns with that From domain, or when DKIM passes and aligns with it. Start with p=none and a rua address so you can read aggregate reports. Move to p=quarantine or p=reject after your real mail streams are passing. Use the free DMARC report reader to read aggregate reports without guessing.

Gmail, Outlook, and other mailbox providers weigh many signals, including authentication, user complaints, sending history, message quality, and sometimes blocklist data. Wrong MX records break inbound delivery. Broken SPF, DKIM, or DMARC can push outbound mail to spam or make it fail sender rules for high-volume mail.

Keep AI search crawl rules separate

Email DNS does not decide whether AI search engines can read your site, but DNS changes often happen during a wider domain audit.

If your help center or status page should appear in AI answers, check robots.txt and server access. The crawlers tied to live AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews through the normal Search index, and Applebot for Apple Intelligence. There is no separate Google AI Overviews opt-out crawler. Disallowing these in robots.txt removes you from that engine's live search path.

GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not remove you from live AI-search visibility. Google-Extended and Applebot-Extended are robots.txt control tokens with no separate crawl user-agent.

Robots.txt is a stated policy, not proof of behavior. Perplexity-User and Bytespider have been reported to ignore it, so use server logs before claiming what a bot did. Only Googlebot documents JavaScript rendering. If key content exists only after client-side JavaScript runs, treat that as a risk for other AI crawlers. You can check crawl rules with the free AI visibility checker.

When mail still fails

If MX is now correct and mail still goes missing, the failure is usually somewhere after DNS.

• Check that the mailbox exists at the new provider and has the right aliases.
• Look for forwarding, catch-all, quarantine, or transport rules that move mail after delivery.
• Confirm the domain is verified inside the provider admin panel.
• Check the bounce message. It may name the old server, a missing mailbox, or a policy block.
• Check blocklists when your server rejects inbound mail or your outbound mail is filtered.
• Review related deliverability guides at InboxRadar guides when the issue is spam placement rather than routing.

Keep a screenshot or export of the old records before you delete them. If something breaks, that gives your provider enough context to spot a missing value fast.