Introduction

An MX record pointing to an old mail server can split delivery in confusing ways. Some senders continue delivering to the retired platform, others follow new records after cache refresh, and the team sees missing or delayed mail without a clear outage message. The fastest path to recovery is to verify the live MX answers, the target hosts they reference, and whether the migration left any hidden dependency on the old provider.

Symptoms

  • New email goes to the wrong inbox or never arrives after a mail migration
  • Different senders see different delivery behavior during the same window
  • DNS checks still show retired mail hosts for the domain
  • Mail flow broke after changing providers, nameservers, or DNS hosting
  • Autodiscover or other mail settings were updated, but inbound mail still follows the old path

Common Causes

  • The authoritative zone still publishes old MX targets after a migration
  • Changes were made in the wrong DNS provider after nameservers moved
  • The MX record was updated, but the referenced mail hostname still points at old infrastructure
  • TTL and cached resolver data prolong the old delivery path during cutover
  • Backup or lower-priority MX entries still send mail to the retired platform

Step-by-Step Fix

  1. Query the domain's live authoritative DNS to confirm which MX records are actually published right now.
  2. Compare those results with the intended mail provider settings and identify whether the wrong change target or wrong DNS host was edited.
  3. Verify every MX hostname resolves to the expected current mail platform rather than an old server still answering on the same name.
  4. Check all MX priorities, including backup entries, so no lower-priority path still routes to retired infrastructure.
  5. Review the migration sequence for leftover dependencies such as old smart hosts, forwarding rules, or hybrid connectors.
  6. Update the live MX records and any referenced A or CNAME targets that still point to the previous provider.
  7. Test delivery from an external sender after the change, and compare headers to confirm the receiving path is now correct.
  8. Monitor for straggling deliveries during TTL expiry instead of assuming every resolver updates at the same moment.
  9. Keep mail migration runbooks explicit about MX records and target hostnames so future cutovers do not stop halfway.