Introduction

When mail filters stop working after a mailbox migration, the mailbox itself may still be receiving messages normally. What usually breaks is the rule layer on top of delivery. Filters may not have migrated, folder targets may no longer exist, the destination platform may use a different server-side rule engine, or the migrated rules may still point at old mailbox paths.

Treat this as a mailbox-rule problem, not a generic receive problem. Start by confirming that mail is arriving in the mailbox before it should be filtered, then check whether the rules survived the move in a format the new platform still understands.

Symptoms

  • Messages arrive in the mailbox but are no longer sorted into folders automatically
  • Forward, copy, flag, or move rules that worked before migration stop triggering
  • Only new mail is affected while older filtered mail remains in the expected folders
  • Some filters still work, but others silently stop after the move
  • Mail starts landing in Inbox instead of target folders after cutover
  • The mailbox migration completed successfully, but server-side organization rules no longer behave as expected

Common Causes

  • The mailbox migration did not carry server-side filter rules to the destination platform
  • The destination server uses a different rule engine such as Sieve with incompatible syntax or capabilities
  • Target folders changed name, path, namespace, or delimiter during migration
  • Filters still reference folders or addresses that no longer exist on the new server
  • The account is now delivering mail through a different path before rules are applied
  • Client-side rules are being confused with server-side mailbox filters
  • Permissions, quota state, or folder subscription issues prevent filtered delivery to the target folder

Step-by-Step Fix

  1. Confirm that affected messages are reaching the mailbox first, because if mail is not being delivered at all, the real problem is upstream delivery and not the filter rules.
  2. Check whether the missing behavior depends on server-side mailbox filters or on a desktop client rule, because mailbox migration usually affects server-side rules while client-only rules live inside Outlook or another local app.
  3. Review the current filter list on the destination platform and compare it with the old mailbox or migration source, because many migrations move mail content successfully but leave the actual rules behind.
  4. Verify that every folder used by a rule still exists with the same name and path, because renamed folders, namespace changes, or recreated mailboxes often break move-to-folder actions after migration.
  5. Test one simple new filter on the destination mailbox as a control, because that quickly tells you whether the rule engine still works at all or whether only the migrated rules are broken.
  6. Check whether the new platform uses a different server-side filter system or supported condition set, because a rule that worked on the old host may not translate cleanly to the destination mail service.
  7. Inspect mailbox quota, permissions, and folder state if rules should move mail into specific folders, because a target folder that cannot be written cleanly can make the filter appear to fail while delivery to Inbox still works.
  8. Send controlled test messages that match one rule at a time and watch exactly where they land, because testing multiple overlapping rules at once makes it harder to identify whether the issue is rule order, folder targets, or unsupported conditions.
  9. Rebuild any broken filters manually once you know the destination platform’s working rule format, and document the final rule set before future migrations, because mailbox rules are commonly missed in post-cutover validation.