Introduction

A mail migration can move mailbox delivery successfully while one alias address starts looping between the old and new environments. Messages may bounce with loop errors, sit in queues, or disappear because the alias, forwarder, or routing rule now points back into another rule chain instead of reaching a real mailbox.

Treat this as a routing-logic problem instead of a mailbox outage. Start by tracing the exact alias path for the affected address, because one stale forwarder or coexistence rule is often enough to make the same message circle repeatedly.

Symptoms

  • Messages to an alias bounce with a loop or too-many-hops error
  • The alias worked before migration, but now delivery never completes
  • Mail sent to one address keeps reappearing in the queue
  • The primary mailbox works while one alias or forwarder fails
  • Different senders see inconsistent delays or non-delivery reports for the alias
  • The issue started immediately after mail platform cutover or coexistence changes

Common Causes

  • The migrated alias points to another alias that now points back to it
  • A forwarder on the new platform still sends mail to the old environment
  • The old server still treats the domain as local and routes the alias back again
  • Coexistence rules were left active after migration
  • The alias was recreated differently on the destination platform than on the source system
  • A catch-all, transport rule, or gateway now re-injects the same message into the alias path

Step-by-Step Fix

  1. Identify the exact alias address and every destination it is supposed to reach, because you need the full intended routing chain before you can spot where the loop begins.
  2. Trace the current alias or forwarder targets on the destination platform, because a migrated alias often points to another object that no longer resolves the way it did on the old system.
  3. Check whether the old mail server still accepts mail for the same domain or alias path, because coexistence leftovers commonly send the message back into the new environment and create a loop.
  4. Review mail logs or bounce details for repeated recipients or handoff hops, because loop errors usually expose the exact addresses or systems handing the message back and forth.
  5. Confirm that the alias resolves to a real mailbox, external address, or final delivery endpoint instead of another circular alias chain, because an alias that never terminates will keep reprocessing the same message.
  6. Inspect catch-all rules, transport maps, or gateway forwarding that still touch the alias address, because one domain-wide rule can silently re-inject mail after the primary alias logic runs.
  7. Remove or rewrite one stale routing step at a time and retest with fresh messages, because changing multiple alias layers at once makes it harder to prove which rule caused the loop.
  8. Compare the broken alias with one working alias on the same domain if available, because differences in final targets or coexistence handling usually reveal the bad rule fastest.
  9. Document the final alias chain and remove any temporary coexistence routing once migration is complete, because loop-prone forwarding paths are easy to recreate during later mail moves.