Introduction

A mail migration can look complete while unmatched addresses still route to the old server. This usually happens when the domain’s catch-all behavior did not move with the mailbox platform. MX records may already point to the new environment, normal mailboxes may work, and only mail sent to non-existent or alias-like addresses keeps landing on the old host. That is not a generic delivery failure. It is usually a default-recipient routing problem.

Start by proving where unmatched mail is supposed to go on the new platform, then check whether the old server is still handling part of the domain or whether the catch-all setting itself was never recreated after migration.

Symptoms

  • Regular mailbox addresses work on the new server, but unknown addresses still route to the old one
  • Catch-all mail disappears, loops, or lands in an unexpected legacy mailbox after migration
  • Some senders hit the new platform while unmatched addresses behave as if the old server is still active
  • Mail sent to mistyped or non-existent addresses follows the pre-migration routing path
  • The issue started immediately after DNS cutover or mailbox platform migration
  • Only default-address behavior is wrong while named mailboxes appear healthy

Common Causes

  • The catch-all or default recipient rule was not recreated on the destination platform
  • The old server still handles part of the domain through stale routing or coexistence settings
  • Local mail routing on the new server is incorrect, so unmatched mail never reaches the new default address logic
  • The domain still exists as an active local mail domain on the old host
  • MX cutover is incomplete across all senders or relays
  • The new platform intentionally disables catch-all behavior unless configured differently
  • A forwarder, transport map, or mail gateway still sends unmatched mail to the old environment

Step-by-Step Fix

  1. Confirm how the catch-all address was supposed to work before migration, because you need to know whether unmatched mail should go to a mailbox, be forwarded elsewhere, or be rejected on the new platform.
  2. Test delivery to one valid mailbox and one clearly non-existent address on the same domain, because comparing those two paths quickly shows whether the issue is specific to default-recipient handling.
  3. Check whether the new mail platform actually has a catch-all or default address configured for the domain, because many migrations move named mailboxes but skip the domain-wide fallback rule.
  4. Verify whether the old server still treats the domain as local mail and can still receive or route messages for it, because that is a common reason unmatched mail keeps following the legacy path after cutover.
  5. Review MX records, inbound gateways, and any coexistence routing still in place, because a partial migration can leave one part of inbound mail flowing through the old environment even when the main mailbox traffic looks correct.
  6. Check control panel or server-side mail routing settings on the new host, because a domain that is not being handled as expected locally can make the catch-all rule appear missing even when the rule exists.
  7. Inspect forwarders, transport rules, or edge filtering services for stale domain-wide handling, because unmatched mail is often redirected before it ever reaches the new platform’s default-recipient logic.
  8. Retest from an external sender after each correction using fresh messages to invalid addresses, because catch-all behavior is easy to misread if you only test named mailboxes or reused messages.
  9. Document the final catch-all behavior and any platform-specific limitation after the fix, because default-address handling is often forgotten during migrations and can quietly break again on the next move.