Microsoft 365 Business email migration and authentication guide

Red Sift’s step-by-step setup for secure, reliable email migration to Microsoft 365 Business. 

Moving to Microsoft 365 (Exchange Online + Defender for Office 365) touches identity, mail flow, and authentication including Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC). 

A smooth cutover protects deliverability, prevents spoofing, and avoids business disruption. This guide provides a proven, security-first path with repeatable checklists.

This guide is particularly valuable for organisations migrating from Proofpoint to Microsoft 365, where email authentication and mail flow configuration become critical during the transition. For detailed Proofpoint-specific guidance, see our dedicated Proofpoint to Microsoft 365 migration section.

The purpose of this guide is to prepare you for the migration of email sending services and give you assurance that you will not have interruptions in email delivery due to missing email authentication configuration.

Out of scope for this guide is everything else that you may also be migrating to Microsoft 365 such as identity services, data including email, calendar and files, inbound anti-spam/anti-pushing, outbound data-loss protection, et cetera.

We recommend seeking support from Microsoft and their partners.

1. Discover and design: Inventory domains, senders, gateways, third-party SaaS, and compliance needs.
2. Prepare: Verify domains, set up Azure AD, baseline DNS, and pilot users.
3. Configure: Mail flow, connectors, accepted domains, anti-spam/anti-phish, transport rules.
4. Authenticate: Publish SPF; enable DKIM; deploy DMARC (p=none) and start monitoring.
5. Migrate: Data migration (IMAP/GWMMO/GWMT), staged/coexistence routing, client cutover.
6. Enforce and optimize: Raise DMARC to quarantine/reject, finalize routing, decommission legacy.

Expected outcome: Secure mail flow in Microsoft 365 with DMARC enforcement and minimal delivery risk.

Moving from Proofpoint Essentials or Proofpoint Email Protection to Microsoft 365 requires careful handling of email security layers that Proofpoint previously managed:

1. Mail flow reconfiguration: Update MX records from Proofpoint infrastructure to Microsoft 365's mail exchange servers, ensuring inbound filtering transitions smoothly to Defender for Office 365

2. Authentication dependencies: Proofpoint often handles SPF authentication through its own infrastructure. You'll need to replace Proofpoint SPF includes with Microsoft 365 equivalents while maintaining any third-party sender authorisations

3. DKIM signing transition: If Proofpoint was signing outbound mail with DKIM, configure Exchange Online to take over signing responsibilities—this typically involves generating new DKIM keys in Microsoft 365 and publishing the corresponding DNS records

4. Policy migration: Transport rules, attachment filters, content policies, and allow/block lists configured in Proofpoint need to be recreated in Exchange admin centre and Defender for Office 365

5. Archiving and compliance: If using Proofpoint Archive, plan data extraction and migration to Microsoft 365's native archiving or a third-party solution

6. Coexistence period: During parallel operation, carefully manage which system handles inbound vs outbound filtering to avoid double-scanning or security gaps

Most Proofpoint-to-Microsoft-365 migrations benefit from DMARC monitoring throughout the transition to catch authentication failures before they impact deliverability.

• Microsoft 365 tenant created and securely configured [https://learn.microsoft.com/en-us/microsoft-365/security/?view=o365-worldwide]
• Domains verified in M365; ownership proven.
• Inventory of all email sources: bulk/marketing, CRM, ticketing, product no-reply, on-prem apps, scanners/MFPs, gateways (Cisco, Proofpoint, etc.), and third-party SaaS.
• Current DNS exported; TTLs lowered (e.g., 3600s) to speed cutover.
• Change window and rollback plan agreed; stakeholders notified.

What you’re doing: Establishing an inventory of all email sending assets and baseline visibility of deliverability before, during and after the cutover.

As part of the pre-migration checklist you should have already created an inventory of all of your email sources. However, there may be gaps or differences that you are not aware of.

With DMARC reporting you will gain visibility into emails being sent on behalf of your domains thanks to feedback reports sent by practically all email receivers. 

Without Red Sift OnDMARC

Setup or extend the DMARC policy of your domains with an aggregate reporting address pointing to the email address you wish to receive the machine-readable XML reports at 

Example: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.tld

Frequently review the machine-readable XML reports looking out for legitimate senders to add to your inventory.

With Red Sift OnDMARC

• Setup or extend the DMARC policy of your domain with an aggregate reporting address pointing to OnDMARC, or optionally use OnDMARC’s Dynamic DMARC service to host your DMARC records to avoid having to manually edit DNS again in the future
• Use the intuitive and powerful UI to review the processed and enhanced output of the reports
• Mark legitimate senders as assets to build up a live inventory of your email sources based on real data

Success looks like: An improved, living inventory of legitimate active email sources based on at least 4 weeks of reporting data, a baseline of DMARC compliance & delivery status and an ongoing window of visibility into changes as the migration proceeds 

What you’re doing: Optimising email configuration for agility and reliability.

To speed up future modifications and reduce the likelihood of errors when changes to DNS are made, you can optionally choose to consolidate your SPF and DKIM configuration with OnDMARC’s Dynamic SPF and Dynamic DKIM services.

By keeping your configuration close to your living inventory of email sources and DMARC reporting you also ensure it is kept up to date.

Success looks like: SPF and DKIM configuration all in one place, cross-referenced with living email source inventory and real DMARC reporting data. 

What you’re doing: Enabling Exchange Online to send while you coexist.

Key configurations:

1. Connectors:
2. Outbound: Exchange Online → internet and/or → legacy gateway during coexistence.
3. Accepted domains and addressing: Authoritative vs. Internal Relay; address rewrite if needed.

• Carefully extend SPF record in DNS with include: spf.protection.outlook.com including taking care to not exceed 10 DNS lookups 
• Carefully add the provided DKIM CNAMEs to DNS
• Send test emails to a neutral provider and check headers manually to verify and debug

• Add include: spf.protection.outlook.com to Dynamic SPF without worrying about too many DNS lookups or mistakes
• Add the provided DKIM CNAMEs to Dynamic DKIM
• Send test emails to Investigate tool to validate or easily debug

Success looks like: Test mail loops succeed

What you’re doing: Setting up and validating assets that send email out through the previous infrastructure to send through Microsoft 365

Typical sequence: For each asset that is sending email through the previous infrastructure

1. Prepare credentials for asset to send through Microsoft 365
2. Send test emails, validate, debug
3. When ready, make configuration permanent
4. Monitor DMARC Reports for deviations

At this point you have

• Setup visibility into your email deliverability with DMARC reporting
• Built an inventory of email sources based on real DMARC reporting data
• (optionally) Consolidated your SPF & DKIM configuration
• Setup and tested outgoing email from Microsoft 365
• Setup, tested and migrated assets that were sending from your previous infrastructure to Microsoft 365

You are ready to continue with the remainder of your Microsoft 365 migration.

What you’re doing: Continuously monitor compliance & deliverability

Validation checks:

• Monitor email volume & compliance rates for regressions
• SPF/DKIM alignment for key domains and high-volume senders

Clean up:

• Lock down legacy routes; decommission unused connectors/gateways.

• Hidden senders (marketing, CRM, scanners) surface late → Use OnDMARC discovery early; contact vendors for DKIM/SPF details before cutover.
• SPF lookup limit (>10) → Use includes wisely; consider flattening/managed SPF via Dynamic DNS, available through Red Sift OnDMARC.
• DKIM not aligned (wrong d= domain) → Match d= with From: domain or enable alignment options where supported.
• Forwarding breaks SPF → Rely on DKIM; consider ARC/SRS for heavy forwarding scenarios.
• Policy gaps after removing legacy gateway → Recreate critical transport rules, allow/block lists, TLS requirements in Exchange/Defender.

• One-click authentication guidance: Clear steps to enable SPF/DKIM for Microsoft 365 and third-party platforms.
• Automated discovery: Finds shadow IT senders so they don’t derail cutover.
• SPF optimization: Manage lookup limits; prevent brittle records during vendor changes.
• Safe policy progression: Data-driven move from none → quarantine → reject in weeks, not months.
• Executive reporting: Show progress and risk reduction to stakeholders during each migration wave.
• Back by AI: Red Sift Radar finds and fixes security vulnerabilities 10x faster, without reducing headcount. Once your setup, use Radar to continually monitor.
• Award-winning customer success: Our team of dedicated engineers and success managers support you every step of the way. Ranked 4.9/5 on G2, Red Sift OnDMARC is #1 in Europe.

For comprehensive guidance on email authentication protocols, see:

• Complete DMARC implementation guide
• SPF and DKIM configuration best practices
• Email authentication for Microsoft 365 environments