Moving Business Email to Microsoft 365 Without Losing Mail: A Practical Checklist

A Microsoft 365 email migration involves more than creating mailboxes and changing one DNS record. The visible part of the job may take only minutes, but a reliable migration depends on preparation: knowing where the existing mail lives, preserving historical messages, controlling DNS changes and making sure every device can authenticate after the move.

This checklist focuses on the practical steps that reduce avoidable disruption for a small business.

Document the setup before your Microsoft 365 email migration

Before changing anything, identify the existing email provider and every address the business uses. Include individual mailboxes, shared addresses such as accounts@ or sales@, aliases, forwarding addresses and any website forms or applications that send email using the domain.

Record who needs access to each mailbox and which devices are currently connected. This sounds basic, but forgotten aliases and shared mailboxes are a common source of problems after a migration.

It is also worth documenting the domain registrar and DNS provider. They are not always the same company as the current email host. Our digital continuity checklist explains the other account details a business should keep on record.

Check the domain and DNS before the migration window

Microsoft 365 needs the business domain to be verified and its DNS records configured correctly. Do not start by deleting the existing mail records. First inspect the current zone and keep a copy of important records so there is a reference if something unexpected happens.

Pay particular attention to MX, SPF, DKIM and autodiscover-related records. Some businesses also have third-party systems that send email on their behalf, such as accounting software, newsletters, booking platforms or the website itself. Replacing an SPF record without accounting for those senders can affect delivery.

If DNS is unfamiliar, our Microsoft 365 DNS and MX troubleshooting guide explains what the main records do.

Create users, aliases and shared mailboxes before cutover

Set up the destination environment before directing live email to it. Users should have the correct Microsoft 365 licences, primary addresses and aliases. Shared addresses should be configured according to how staff actually use them rather than automatically turning every address into a separately licensed mailbox.

Test sign-in and multifactor authentication before the DNS cutover where possible. A mailbox that exists but cannot be accessed is not ready for production use.

This is also a good time to review old accounts. Do not migrate unknown or unnecessary administrator access simply because it existed in the previous system.

Plan historical data for your Microsoft 365 email migration

The right migration method depends on the source system, the amount of mail and the number of users. Historical messages may be copied using an appropriate migration method, imported from exported data or moved with a specialist tool. Whatever method is chosen, establish what will and will not be transferred before the live cutover.

Do not assume that seeing recent messages in Outlook means the historical migration is complete. Check folders, sent items and representative older messages. If calendars and contacts are part of the migration scope, verify those separately.

Plan the DNS cutover for your Microsoft 365 email migration

The MX record tells other mail systems where new messages for the domain should be delivered. When it changes, not every sender on the internet sees the new value at exactly the same moment because DNS information is cached.

That is why the old email service should normally remain accessible during the transition. Messages may continue arriving there for a period after the new Microsoft 365 MX record is published. Understanding DNS propagation helps explain why two people can temporarily see different results.

Avoid making unrelated DNS changes during the same window. Changing the website, nameservers and email platform simultaneously makes any fault much harder to isolate.

Configure SPF and DKIM carefully

SPF identifies systems authorised to send mail for the domain. DKIM adds a cryptographic signature that receiving systems can validate. Both contribute to mail authentication and should be considered as part of the migration rather than as optional cleanup weeks later.

A domain should not end up with multiple competing SPF TXT records. If other legitimate platforms send mail for the business, their requirements need to be incorporated correctly. Once Microsoft 365 is operating, enable and verify DKIM using the records supplied for the tenant.

If legitimate messages are landing in junk folders, see our guide to SPF, DKIM and email sending reputation.

Do not forget the website

Website contact forms are frequently overlooked during an email migration. A form may send through the web server, SMTP credentials or an API-based mail service. Changing the business mailbox or DNS can expose an existing configuration problem even though the website itself has not changed.

After cutover, submit every important form and confirm that the message reaches the correct Microsoft 365 mailbox. Check both the sender and reply-to behaviour. If a WordPress form reports success but no message arrives, work through the contact-form email troubleshooting guide.

Reconfigure computers and phones deliberately

Users may need to remove an old account profile or add the new Microsoft 365 account to Outlook and mobile devices. Saved passwords, old autodiscover information and duplicate profiles can create confusing symptoms.

Test sending and receiving from each user’s normal device. Also test Outlook on the web because it provides a useful comparison. If webmail works but a desktop application does not, the problem is more likely to be local configuration than mail flow. Our guide to email working on a phone but not a computer covers that distinction.

Verify mail flow from outside the business

Internal tests are not enough. Send a message from an unrelated external account to the migrated domain and reply to it. Then send outbound mail to an external address. This confirms both directions of mail flow and can expose DNS or authentication issues that internal Microsoft 365 messages do not reveal.

Check shared mailboxes and aliases separately. If an address is important enough to publish on the website or invoices, it deserves its own test.

Keep the old service until the migration is proven

Cancelling the old email account immediately after changing MX records removes a useful safety net. Keep it available long enough to confirm that historical data is present, new mail is reaching Microsoft 365, users can access their accounts and no important messages are still arriving at the previous provider.

Once the migration is stable, document the new tenant administration, recovery methods, DNS provider and licence ownership. That information becomes important months or years later when staff change or another technical issue occurs.

When specialist help makes sense

A straightforward one-user mailbox can be manageable. Risk rises when the business has multiple users, shared mailboxes, years of historical email, third-party senders, complex DNS or no clear record of the current setup.

TempWebz provides Microsoft 365 setup and technical support for businesses that want help planning the move, configuring DNS and checking mail flow. The goal is not merely to make Microsoft 365 accept the domain. It is to move the business without losing access to the email people rely on every day.

Record Microsoft 365 email migration acceptance

Keep a checklist for each important mailbox, alias and shared address. Record successful sign-in, inbound and outbound tests, historical folder checks and any device issue. Give each unresolved item an owner. Do not mark the whole migration complete because one account works.

Verify authentication for every legitimate sending service, not just staff mail. Microsoft’s email authentication guidance explains how SPF, DKIM and DMARC work together. Retain a clear record of the intended configuration without including passwords or secret keys.

Before cancelling the old service, ask the business owner to accept the verified results and any documented exceptions. Preserve required historical information and confirm who will handle follow-up support. This final decision should follow evidence of a working migration, not simply the end of the scheduled maintenance window.