A migration to Google Workspace or Microsoft 365 is usually sold as moving your mailboxes. The messages, the folders, the calendars — copied from the old system to the new one, cut over on a weekend. That part is well-trodden and usually goes fine.
What moves with the mailboxes is the visible half. The invisible half — the DNS records that tell the world your mail is legitimately yours — does not move unless someone moves it, and it is where migrations quietly break.
The half that gets forgotten
Your mail flowing correctly depends on three things that live in DNS, not in the mail server:
- MX — where mail for your domain is delivered.
- SPF — which servers are allowed to send as you.
- DKIM — the signature that proves a message really came from you.
A migration changes all three, and they change at different times, controlled by different people. The MX cutover is the one everyone remembers, because if you get it wrong, mail stops arriving and the phone rings within the hour. SPF and DKIM fail more quietly. Mail still goes out. It just starts failing authentication at the receiving end, and lands in spam — with nobody getting a phone call, because the sender's outbox looks normal.
What actually goes wrong
SPF still points at the old sender. Your record authorizes the previous mail system and not the new one, or it authorizes both and now exceeds the ten-lookup limit because you added the new provider without removing the old. Either way, mail from your new Google Workspace tenant is unauthenticated.
v=spf1 include:_spf.google.com include:old-mail-provider.com ~all
Both included, nobody removed the old one, and if the chain now resolves to more than ten lookups the whole record is discarded.
DKIM was never turned on. Google Workspace does not sign your mail by default. You have to generate a DKIM key in the admin console and publish the public half in DNS under a selector Google gives you. Skip it, and every message leaves unsigned — which, on a domain with an enforcing DMARC policy, means it fails.
DMARC is now stricter than your new setup can pass. If you moved to enforcement before the migration and your new tenant isn't authenticating yet, your own DMARC policy rejects your own mail. The protection you built is now working against you.
The order that keeps mail flowing
The safe sequence is the opposite of the tempting one. The temptation is to cut over the MX first, because that is the migration everyone pictures. But the authentication should be ready before the mail starts flowing through the new system:
- Turn on DKIM signing in the new tenant and publish the key. Confirm it validates.
- Update SPF to authorize the new sender, and remove the old one so you stay under the lookup limit.
- Only then cut over the MX.
- Watch DMARC reports for a week. Anything failing is a sender you missed — fix its authentication before it becomes a delivery problem.
Most of a migration done this way is waiting and watching, not switching. The switching is fast. The watching is what stops you from discovering, three weeks later, that half your invoices have been going to spam since the weekend you moved.
Before you start, it is worth knowing exactly what your current records say, so you can tell what changed: check your domain.