Avoid email loss while migrating between Office365 tenants


A common use case involves the transition between (or within) email providers. For example, Microsoft's guide to migrating email accounts between Office365 tenants includes the following instruction:

Change your primary MX record from Office 365 to domain that is not reachable, i.e. "unreachable.example.com". Internet mail servers attempting to deliver new mail will queue the mail and attempt redelivery for 24 hours. Using this method, some email may return a non-delivery report (NDR) depending on the server attempting to deliver the email. If this is a problem use an MX record backup service. There are many third party services that will queue your email for days or weeks. Once your migration is complete, these services will deliver the queued mail to your new Office 365 tenant.


If non-delivered email is unacceptable, DuoCircle's Tenant Migration Service can be employed to temporarily queue all emails during the tenant transition. The destination mail server has pre-configured to defer all inbound connections and will cause your email to queue until your new tenant is online, at which time you can update your delivery preferences and delivery your email without any message loss.


Requirements

  1. Ability to modify DNS settings

  2. Update the TTL of your MX record to 600 seconds at least 48 hours prior to the migration

  3. Update the firewall rules on your Tenant to allow connections from our IP addresses. The queued email may contain spam and we do not want Office 365 blocking delivery from our IP's.

  4. Two hours prior to migration add the custom MX record and ensure that some messages are queuing

  5. Download our Tenant Migration Checklist attached to this KB.


48 hours before migration

Roughly 48 hours prior to the planned migration, execute and confirm the following:

  1. Updated DNS time-to-live (TTL) value for existing MX records on domain as low as possible or 600 seconds. This will ensure when you do make a DNS change that it updates quickly across the Internet.
  2. Updated the IP allow list rules on tenant to allow connections from our DuoCircle IP ranges, and ensured that Enable safe list is checked.
  3. Back up or screenshot your existing MX records. You'll may need to recreate theses after the migration.
  4. Evaluated whether spam/virus filtering should be enabled in client portal (enabled by default)

At this point, your email is still being delivered to the existing tenant, but the elements of the migration which rely on expiry or cache time have been prepared for the switch.


2 hours before migration:

2 hours prior to the planned migration, execute and confirm the following:

  1. Login to the client portal and check that the destination mail server is set to migration.mailhop.org (the expected value)
  2. Update your DNS record and set your custom mailhop.org MX to lowest preference.
  3. Confirmed that email is being queued, but not delivered (blue arrow icon) in client portal
  4. Removed ALL MX records other than your custom mailhop.org MX.

At this point, no new email is being delivered to the existing tenant. 2 hours grace is allowed for propagation of DNS records. We suggests DNS Checker to monitor the DNS updates.


Just Prior to migration

Before performing the migration, execute and confirm the following:

  1. Review message log in client portal to confirm that email is queuing and not being deliver to your existing tenant. If there are no blue icons, or you see black icons in the client portal. Stop and contact support for help.
  2. Send a test message, and ensure that email is queuing with a blue icon. Your email will queue for 30 days which is more than enough time to execute a migration.

At this point, the migration can commence.


Post-migration

Once you are notified that the new tenant has been created and your settings have been validated, execute and confirm the following:

  1. Telnet from your computer to port 25 of your new MX record or host name and ensure that the SMTP server is responding. telnet your.mx.record 25 and ensure you get a response from the server.
  2. Confirmed that mailhop IP's are listed in your trusted networks, per step #2 above (in case the migration altered these)
  3. Ensure that your users, groups, mailing lists and other settings in your tenant are accurate prior to attempting deliver to your new tenant.
  4. Delete migration.mailhop.org as destination server in the client portal, and replaced it with your provider MX record or host name.
  5. Verify that queued email is now being delivered (green arrow icon) - it may take up to an hour for all queued email to be delivered. Continue to test by sending a new email, it should be delivered almost immediately.
  6. Update your MX records in your DNS provider based on the new tenant information, remove mailhop.org mx record. Email may still flow into your migration account while DNS updates, this should stop in a few hours and all mail should be going to your new tenant.

At this point, email queued during the migration should have been automatically delivered, and all subsequent emails are delivered directly to your tenant (bypassing our service)


24 hours after post-migration

24 hours after successful migration, remove the unnecessary DuoCircle by executing and confirming the following:

  1. Review the message logs in the client portal that no further email has been recieved via the mailhop custom MX.
  2. Remove custom mailhop.org MX record from DNS

At this point, migration has concluded, and the tenant migration service is no longer required. If you run into any technical challenges please contact us.


Conclusion

The above is a common use case for the backup MX service, when normal delivery to a provider is undesirable for a period.

The methodology described above can also be used to manage the transition between email providers (say, from an on-premises Exchange Server to Office365)