Microsoft 365 Email Migration Checklist

Use this checklist when migrating to Microsoft 365 Exchange Online from on-premises Exchange, another hosted provider, or a Linux mail platform. The most common migration failures come from skipping the pre-migration authentication audit and cutting MX before verifying DKIM is configured.

Pre-migration audit

Complete this before any migration work begins.

Existing environment:

• Document all mail flows: inbound, outbound, internal relay, and application mail (printers, line-of-business apps, monitoring alerts)
• List all domains on the current mail platform
• Check current SPF record — identify every sending source that will need to remain covered post-migration
• Check DKIM status for each domain
• Check current DMARC policy and review recent aggregate reports
• Check all sending IPs against blacklists — don’t migrate a blacklisted reputation

Run a full email auth and blacklist check →

Target M365 environment:

• Microsoft 365 tenancy is provisioned and licences are assigned
• All domains are added and verified in Microsoft 365 Admin Center
• MX records are not pointed to M365 yet — keep on the current platform during setup

Authentication setup — before MX cutover

• SPF: add include:spf.protection.outlook.com to your SPF record. Remove old mail server IPs that won’t be sending after migration. Verify the lookup count stays at 10 or fewer.
• DKIM: in Exchange Admin Center → Email authentication → DKIM, select each domain and generate CNAME records. Publish the CNAME records to DNS. Once published, click Enable. Verify both selectors return valid public keys before proceeding. Do not cut MX until DKIM is confirmed working.
• DMARC: if your current policy is p=reject or p=quarantine, consider moving temporarily to p=none during migration to prevent legitimate mail failing while authentication is being reconfigured. Restore enforcement after the migration is complete and verified.
• Connectors: if you use a third-party gateway or relay (a Linux filtering layer, for example), configure inbound and outbound connectors in Exchange Admin Center before MX cutover.

Parallel run (recommended for any migration with >10 mailboxes)

• Configure M365 as a secondary MX destination with a higher priority number (lower preference) — this routes some external traffic to M365 for testing without affecting primary flow
• Send test messages from external addresses and verify M365 is receiving correctly
• Verify outbound mail from M365 is signed by DKIM and passing DMARC alignment
• Test application mail relay — configure line-of-business applications to relay through M365 (port 587 with SMTP AUTH, or a dedicated relay connector)
• Test all other mail flows: support desk, CRM, monitoring alerts

MX cutover

• Confirm DKIM signing is active for all domains in Exchange Admin Center
• Confirm SPF is updated and includes M365’s sending ranges
• Set the MX record TTL to 300 seconds (5 minutes) at least 24 hours before cutover
• Schedule cutover during low-traffic hours
• Change MX record to point to M365 (yourdomain-com.mail.protection.outlook.com)
• Monitor the old mail platform — messages queued before the MX change will still attempt delivery to the old server; let the queue drain before decommissioning
• Verify inbound mail is arriving in M365 mailboxes within 10 minutes of MX cutover

Post-migration

• Restore SPF to -all if you softened the policy during migration
• Restore DMARC to previous enforcement level if you relaxed it
• Update rua= reporting address to a mailbox you actively monitor
• Wait 48 hours and review DMARC aggregate reports — look for any legitimate sources still failing
• Decommission the old mail server only after at least 72 hours of clean M365 operation
• Set MX TTL back to 3600 or higher
• Add DKIM signing status checks and DMARC report review to your regular monitoring schedule

Application mail relay options

M365 doesn’t allow unauthenticated SMTP relay by default. For applications that need to send email, three options:

SMTP AUTH (port 587): configure each application with an M365 service account. Requires an Entra ID account with SMTP AUTH enabled per-mailbox. Simplest for applications that support modern auth.

Direct send (port 25): applications on static IPs can send directly to M365’s MX without authentication. No M365 configuration required, but your outbound IP must be static.

Relay connector: for applications that can’t use AUTH and don’t have static IPs, configure a partner connector in Exchange Admin Center that accepts relay from specific IP ranges.

Document which option is used for each application before decommissioning the old relay host.