Every migration plan is drawn as a clean line: old system on Friday, new system on Monday, one MX cutover in between. The reality is rarely a line. It's a window — days or weeks where some mailboxes have moved and some haven't, where mail leaves through the new tenant and the old one, and where both have to authenticate correctly at the same time.
That window is the part of a migration that isn't on the plan, and it's where deliverability quietly fails.
Why coexistence happens at all
You almost never move everyone at once. A 200-mailbox company moves in batches: a pilot group, then a department, then the rest. During that period, sales@ might be on the new Google Workspace or Microsoft 365 tenant while accounts@ is still on the old system. Both are sending as the same domain. Both are being judged against the same SPF, DKIM, and DMARC records.
Even a small org hits this. The invoicing tool, the CRM, the helpdesk — third-party systems that send as your domain don't cut over on your migration weekend. They keep sending through whatever they were configured to use until someone reconfigures each one, and that reconfiguration lags the mailbox move.
The two things that break in the window
SPF can only authorize one path, and now you have two.
During coexistence your record has to authorize the old sender and the new one simultaneously:
v=spf1 include:_spf.google.com include:old-provider.net ~all
That looks harmless, but it's the exact moment SPF tips over the ten-lookup limit — you've added the new provider without removing the old, because you can't remove the old one yet; it's still sending. If the combined chain resolves past ten lookups, the whole record is discarded and both systems start failing SPF. The migration didn't break one path. It broke the record.
DKIM alignment splits. Mail from the new tenant is signed with the new tenant's key; mail from the old system is signed with the old one — assuming both were set up, which during a rushed migration they often aren't. If DMARC is already enforcing, any system whose signing you haven't finished lands as a failure. The half of the company that moved is authenticated; the half that hasn't is silently failing, or the reverse.
The window is where DMARC earns its keep
This is the migration state that makes aggregate reports non-optional. During coexistence, the reports are the only place you can see both systems at once: which sources are sending, which are aligned, which aren't yet. You read them daily, and you don't advance a batch — or tighten DMARC — until the sources you've already moved show clean aligned passes.
The mistake is treating enforcement as a setting you flip on migration day. In a coexistence window, enforcement should be the last thing you tighten, not the first — after every batch has moved and every third-party sender has been re-pointed and confirmed aligned. Enforce in the middle of the window and you reject the half of your own mail that hasn't caught up yet.
Plan the window, not just the cutover
A migration plan that lists only the MX cutover is planning the easy hour and ignoring the hard fortnight. The window is where the work actually is: keeping SPF valid while it has to cover two systems, getting DKIM signing live on both, re-pointing every third-party sender, and reading DMARC reports the whole time so you know when it's safe to move the next batch and, finally, to enforce.
Before you start, know exactly what your records say today, so you can tell what the migration changes: check your domain. The clean line on the plan is fiction. The window is the migration.