If your DNS MX record cutover is planned separately from BitTitan mailbox job completion, you may be introducing a mail routing gap.

Changing the MX record is the moment new inbound mail begins routing to the destination tenant mail server. If that MX change happens before BitTitan mailbox migration jobs have completed for all users, then mail for users still in the migration queue can begin arriving in the destination mailbox while their historical content is still being migrated from the source.

That split creates a gap: older mail remains in the source mailbox under active migration, while new inbound mail lands in the destination mailbox. Once BitTitan finishes, the historical data arrives in the destination and both streams coexist without issue. If the migration is delayed and the source mailbox continues to receive new inbound mail after the MX record change, the source tenant must still handle and forward that inbound mail to the destination or mail routing becomes ambiguous.

To avoid this, time the MX record update for after BitTitan migration jobs have completed their final pass for all users in the wave. Also reduce DNS TTL for the MX record to 300 seconds or less, 24 to 48 hours before cutover, to limit propagation delay once the change is made.

Is your BitTitan mailbox migration job completion coordinated with your DNS MX record cutover timing?

#BitTitan #MigrationWiz