Introduction

A mail migration can look complete while some messages still land on the old server because the backup MX was never updated. Primary mail flow may already use the new platform, but deferred or fallback delivery can still route to the legacy host when senders cannot reach the main destination.

Treat this as a secondary-routing problem instead of a normal MX cutover delay. Start by checking whether the domain still publishes any lower-priority MX record that points to the old server or to infrastructure tied to it.

Symptoms

  • Most mail reaches the new platform, but some delayed mail still lands on the old server
  • Mail behavior differs when the primary server is busy or temporarily unavailable
  • The old server still receives inbound mail even after migration
  • Normal MX checks look mostly correct, but fallback delivery is wrong
  • Only some senders or retry attempts reach the legacy environment
  • The issue started after mail server migration or provider change

Common Causes

  • A lower-priority backup MX record still points to the old mail server
  • The secondary MX host was not updated during the migration
  • A mail gateway or backup relay still forwards queued mail to the previous environment
  • The old server still accepts mail for the domain and makes the backup path appear healthy
  • DNS was updated for the primary MX only while fallback records were missed
  • Mail-routing documentation covered the main cutover but not the secondary delivery path

Step-by-Step Fix

  1. Review the full MX record set for the domain and identify every priority level in use, because backup MX problems are easy to miss when you only verify the primary mail host.
  2. Check whether any lower-priority MX still points to the old server or to infrastructure tied to it, because fallback delivery will continue using that path until it is removed or updated.
  3. Confirm how the backup MX is supposed to behave on the new platform, because some environments still need secondary acceptance while others should stop using a separate fallback host entirely.
  4. Verify whether the old server still accepts mail for the domain, because a legacy host that remains active can keep masking the bad secondary route after migration.
  5. Inspect any gateway, relay, or backup-queue service associated with the secondary MX, because one hidden handoff can still forward deferred mail into the previous environment.
  6. Update or remove the stale backup MX path and retest with the intended fallback design, because changing only the primary MX leaves the old secondary route intact.
  7. Send controlled tests while simulating the primary path being unavailable if your environment allows it, because backup MX problems usually appear only when the normal route fails.
  8. Compare live mail logs on the new and old platforms after the DNS change, because fallback delivery can linger unnoticed unless you verify where delayed mail actually lands.
  9. Document every MX priority and fallback mail path after recovery, because backup routes are commonly forgotten during future mail migrations.