Preparing the mail flow for the Office 365 migration

This article is part of my migration journey from my old Office 365 to my new Microsoft 365 Tenant. This article is about mail traffic during the migration and how to avoid data loss.

In May 2015 I have already written the article “Migration from one Office365 Tenant to another Office365 Tenant“. I will adopt and adapt the relevant parts from the old article here.

A special feature of Office365 mailboxes

The good thing about Office 365 mailboxes is that they all have an internal ID. This consists of the tenant name and the username. An example is “spam_me@niesenf.onmicrosoft.com”, we use these addresses later, for both the new and the old environment.

Types of migration

The next thing to consider is which is the right approach for mail migration.

The Big Bang Migration

A case of “Admins meet on weekends and migrate everything”. This may still be possible for small companies, for most of them it is not. The big advantage, it is the easiest way. Migrating, finished, is basically quite simple.

The Coexistence

Now it’s already getting harder, if the migration cannot be done in one shot, then most IT departments will have a tough time. Then coexistence is needed, which means both worlds work with each other. That is not easy when both Office365 environments. Also, both worlds must know which mailbox is located where and must communicate with each other correctly. This often leads to problems, especially with appointments and answers to emails. In my experience, the coexistence of two Office 365 environments without third-party solutions is only possible with a huge effort and knowledge. You need to write a couple of scripts to configure the environments accordingly.

If coexistence is needed, my recommendation is to look for an appropriate solution provider or solution vendor.

Background of the challenges of coexistence is the internal addresses like in some cases X400 or X500, depending on the history of your environment. Also, the old environment may consider itself responsible, although the user is already on the new one or vice versa. Accordingly, forwarding must be maintained in both systems. Another problem can be authorizations and authentication. This mainly involves shared access. For example, availability information for calendars, availability of meeting rooms and resources, or mailbox permissions for representatives or assistants.

The respective steps depend on the tool and the concept of coexistence and would go beyond the scope here.

Accordingly, in this article, I will focus on the “big bang” migration.

Forwarding of the mails

Since changes in the DNS always take a while, it is not only important to reduce the lifetime (TTL) of DNS entries. You also must think about the mail flow in the meantime. In general, mail servers send an email again if it could not be delivered. The only people who normally don’t do this are spammers who have hijacked systems, so many servers today also support greylisting. The only problem is that neither the interval nor the duration of the attempt is standardized. Many servers try it every hour for 24 hours. And now the special characteristic of the Microsoft environment comes into play. Due to the complex infrastructure, especially with the protection of the systems, it can take up to 24 hours until a mail domain is detached from a Microsoft Office 365 environment and possibly even as long to add it again. These are numbers that Microsoft once communicated as “up to”. During my migration, the time for removal was less than an hour. To be on the safe side, you should add some extra waiting time for subsequent systems.

So that no mails are lost now, we use a third server. In my case the mail server of the web hosting which has nothing else to do. What we must build is a small chain.

For this purpose, all mail addresses are set up on the webserver and forwarding to the corresponding mailbox at the @new.onmicrosoft.com address is configured. For this, the mailboxes in the new world must already exist with the onmicrosoft address. As soon as the forwarding has been set up and tested, the MX and TXT with the Sender Policy Framework (SPF) entries can be switched to the interim mail server. If you want to, you can add the new MX with a lower priority in step 1 and change it when the time comes.

If the MX entry was changed to the new server, mails can still be delivered to the old system until the TTL expires. Until then the domain should not be removed in Office 365! I won’t mention again how important the TTL is for DNS entries at this point.

Sender Policy Framework (SPF)

A few more words about SPF, this entry, which is necessary for spam fighting, I usually adjust with the TTL. This entry tells other mail servers which servers can send mail for the domain. Mails coming from other systems are either marked as spam or directly discarded, depending on the configuration of the recipient mail server. You should be accordingly careful with this entry. Microsoft recommend “v=spf1 include:spf.protection.outlook.com -all”, I use “v=spf1 a MX include:spf.protection.outlook.com -all” for the migration. The “a” means that all systems that have a host entry in the DNS are allowed to send mails. The entry “MX” means that all mail servers, including the interim mail server, can send mails. To avoid rejection in case of overlaps I adjust the entry as early as possible.

Transition after setting up the new Office 365

Once the domains have all been transferred to the new Office365 and the corresponding mail aliases have been configured there, the MX can be set up for the new Office 365 environment. Please note that the wizard will warn you about wrong DNS entries when adding the domain. You must ignore this! If you change the entries as requested, the MX will point to the new environment before the mailboxes have your aliases, so mails might be rejected as undeliverable. After the change, you should at least wait for the TTL again before you reverse the temporary mail server. Personally, I still wait a few days before I lose another mail from a server that hasn’t implemented the DNS query properly. This has happened to me before during a migration where the temporary server was protected with greylisting and the sending server did not check the DNS again but sent it to the internally stored address. Shouldn’t happen, but…

As all mails So this is also no security risk. It would look different if you had classified the Interim Server as particularly trustworthy during the migration.

Possible pitfalls

There are some things that can lead to complications. Here are a few examples that should be considered accordingly:

• Safe transmitter configuration in Office 365, is the Web server for internal processes or services in the old environment enabled separately? Then it probably must be in the new environment. This can have an impact on forwarding security and virus and spam protection.
• Are there still internal systems that send mail? If so, how is the mail flow? Defined IP or hostname or MX-query? This could be for example scanner / multifunction printer or internal scripts, for example, a WSUS cleanup script or a user creation script.
• Security configurations with partners or customers in the old Office 365 environment, such as connectors with certificate verification
• Faulty DNS configuration, which prevents the entries from becoming public. An example was a customer who maintained the wrong DNS server. Therefore check the entries with the Heise DNS Tools, for example, so that the answer cannot be falsified by internal systems or DNS forwarding.