Every Exchange to Microsoft 365 migration I’ve been involved in has hit at least one of these delivery problems. They don’t appear in the migration guides because they’re not data migration problems — they’re authentication problems that surface after cutover and look, from the outside, like “email is broken.”
Here’s what they are, why they happen, and how to fix them.
Problem 1: DKIM signatures break at cutover
On-premises Exchange doesn’t use DKIM by default. If you had DKIM configured — either through a third-party mail gateway or a custom Exchange Transport Agent — that signing happens at the server level. When you cut over to Microsoft 365 and decommission (or bypass) the on-premises server, the signing infrastructure disappears.
Microsoft 365 will sign outbound mail, but with its default onmicrosoft.com key — not your custom domain key. If your DMARC record requires DKIM alignment (it should), messages will now rely solely on SPF for DMARC alignment. That works until anyone forwards your mail.
What it looks like: DMARC reports showing dkim: fail or dkim: none from Microsoft IP ranges. Deliverability failures at providers that weight DKIM heavily. Forwarded mail failing DMARC.
The fix: Set up DKIM for your custom domain in Microsoft 365 Defender before the MX cutover. Publish the CNAME records, enable signing, verify it’s working with a test message. By the time you flip the MX record, DKIM should already be signing correctly. See the Microsoft 365 DKIM setup guide for the exact steps.
Problem 2: SPF includes pointing at your old server
Your SPF record probably includes a reference to your on-premises Exchange server — either a direct IP (ip4:203.0.113.25) or a hostname (include:mail.company.com.au). After migration, that server no longer sends your outbound mail. But it’s still in SPF.
This isn’t a delivery problem immediately — unused SPF includes don’t cause failures. The problem is that SPF has a hard limit of 10 DNS lookups during evaluation. Obsolete include: statements consume lookups. Combined with the includes needed for Microsoft 365 (include:spf.protection.outlook.com), SaaS platforms, CRM tools and other cloud services, you may already be close to the limit. An obsolete include that triggers multiple nested lookups can push you over.
When SPF exceeds 10 lookups, the result is permerror — which some receivers treat as a failure.
What it looks like: Intermittent delivery failures, particularly at providers that perform strict SPF validation. DMARC aggregate reports showing spf: fail from sources that should be passing.
The fix: After migration is confirmed stable, audit your SPF record. Remove IP addresses and includes that no longer send on your behalf. Use the email auth checker to see your current lookup count. The SPF 10-lookup limit article covers how to count and fix the issue.
Problem 3: Hybrid configuration mail routing loops or delays
If you’re running a staged migration (some mailboxes in Exchange, some in M365), hybrid configuration is required. Hybrid is Microsoft’s recommended approach for coexistence — but the mail routing it creates has failure modes that don’t appear in test environments.
The most common: outbound mail from M365 routing back through on-premises before going external. In a typical hybrid configuration, M365 sends outbound mail via an on-premises Connector that routes through your Exchange server to the internet. This adds latency, adds another potential point of failure, and means your on-premises server still needs to be healthy for all outbound mail to work.
If the on-premises server has a queue backup, certificate issue, or connectivity problem, your entire M365 organisation’s outbound mail is affected — even for mailboxes that have already moved to the cloud.
What it looks like: Delayed outbound delivery. NDRs from your own domain to external recipients. Queues building up on the on-premises server during normal M365 operation.
The fix: Evaluate whether centralised mail transport is genuinely needed for your environment. For most organisations, decentralised transport (M365 sends directly to the internet for migrated mailboxes) is simpler and more reliable. If you’re keeping hybrid for a short migration window, monitor the on-premises server’s outbound queue actively and have a plan to switch to direct send if it backs up.
Problem 4: Third-party sending services not updated for the new mail flow
Before the migration, your on-premises Exchange server was the hub. CRM systems, ERP applications, monitoring tools, and web applications sent mail through Exchange — either by relaying directly through it or by authenticating to it as an SMTP relay.
After cutover, those applications still have the on-premises Exchange server configured as their relay. If Exchange is being decommissioned, their mail simply stops sending. If it’s kept alive as a relay, you’ve created a dependency that makes decommissioning harder later.
What it looks like: Automated notifications stop arriving. Application-generated emails from your ERP or CRM disappear silently. Error logs show SMTP connection failures to the old server hostname.
The fix: Inventory every service that sends email through your infrastructure before the migration. For each one, document: what sends it, what SMTP server it points to, what authentication it uses, and what address it sends from. After migration, each service needs to be updated to relay through Microsoft 365 (using authenticated SMTP submission on port 587 or 465) or through a dedicated relay connector if the application doesn’t support authentication.
Don’t discover this list during the migration — the silence from application mail is hard to diagnose under pressure.
The fix checklist
Before you flip the MX record:
- DKIM configured and verified in Microsoft 365 Defender for your custom domain(s)
- Inventory of all services that send email on your behalf (with their current SMTP relay settings)
- SPF record reviewed — M365 include added, old server include flagged for removal post-migration
- DMARC aggregate reporting configured — you need the data from day one post-cutover
- Hybrid transport decision documented — centralised or decentralised
After MX cutover, within the first 48 hours:
- Review DMARC aggregate reports for failures (Google and Microsoft usually report within a few hours of receiving mail)
- Check application mail queues — anything still pointing at on-premises Exchange will fail
- Verify outbound delivery from M365 by checking SMTP headers on a received test message
- Confirm SPF evaluation is passing from Microsoft IP ranges
After migration is stable:
- Remove the old server’s IP and hostname from SPF
- Decommission or repurpose the on-premises Exchange server once no services depend on it
- Check your SPF lookup count — post-migration audits frequently find it’s closer to the limit than expected
Most migration guides stop at “mailboxes moved, Outlook connected.” The email delivery layer keeps running long after that — these problems can surface weeks after the migration is considered complete when someone finally notices application mail isn’t arriving.