What an MX record does
A sender's mail server looks up the recipient domain's MX record (mail exchanger) to find the server that accepts its mail. Today that record points to Google. At cutover it changes to point to Microsoft 365, and new mail moves there as other mail servers pick up the change.
“Any existing email stays at your previous email host” until it is migrated.
That is why migration and cutover are two separate jobs. Migration copies the mail that already exists. Cutover redirects new mail, as other mail servers pick up the change.
Before cutover day
1. Every address has somewhere to land
Microsoft's instruction is to add users and set up mailboxes for all email users on the domain before updating the MX record (Microsoft Learn). Other addresses receive mail too. List every address the domain accepts today: aliases, Google Groups, shared or role addresses (info@, billing@), and addresses that routing or catch-all rules handle. Before the switch, create the matching Microsoft 365 object for each one: a licensed mailbox, a shared mailbox, a group, an alias on an existing mailbox, or a mail contact.
Once Microsoft 365 receives the domain's mail and the domain is set as authoritative in Exchange Online, Microsoft 365 rejects a message to an address it does not know, even if the same address worked in Google. The outside sender gets 550 5.4.1 Recipient address rejected (Microsoft Learn: Directory-Based Edge Blocking). A related not-found bounce uses the code 550 5.1.10 (Fix NDR error 550 5.1.10). After the switch, send a test message to each address.
2. The domain is verified in Microsoft 365
Microsoft 365 asks for proof of ownership, usually a TXT record it generates, and verification can take up to 10 minutes, or up to 48 hours at some registrars (Microsoft Learn: Add a domain). Verifying the domain does not move mail. Mail moves when the MX record changes.
Watch the setup wizard. When the DNS host supports Domain Connect, the Microsoft 365 wizard can add every email record at once, including the MX record, and some hosts offer to delete the existing MX record in the same step. That moves mail on the day the domain is verified, not on cutover day. Microsoft's alternative is the Manual option, where each record is added by hand (Microsoft Learn).
3. The MX record's TTL is lowered a day or more ahead
Every DNS record carries a TTL (time to live): how long other servers may reuse the answer before asking again. With a long MX TTL, senders keep the old answer after the change.
Microsoft's guidance for a cutover migration is a TTL of 3,600 seconds (one hour) or less on each MX record before the migration starts, raised again after the final switch (Microsoft Learn: Cutover migration). Lower it at least one full old-TTL period before cutover, or the lower value has not reached everyone yet.
4. Everything that sends mail as the domain is listed
Google and Microsoft are rarely the only senders. Invoicing tools, customer relationship management (CRM) systems, marketing platforms, website forms, printers and scanners often send as @yourcompany.com. Each one keeps passing checks after cutover only if it passes DMARC, the check described under After cutover. That takes one of two results: SPF passes for a MAIL FROM domain that matches the visible From domain, or DKIM passes for a signing domain that matches it (Microsoft Learn: Set up SPF, Set up DMARC). Each service's own instructions say which it uses. Microsoft recommends putting services outside direct control on a subdomain such as marketing.yourcompany.com (Microsoft Learn).
5. One SPF record covers both systems
SPF (Sender Policy Framework) is a TXT record listing the servers allowed to send mail as the domain. During the overlap, while both Google and Microsoft may send, the record authorizes both. Google publishes this combination (Google Workspace Admin Help: Set up SPF):
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~allAdd a sender from step 4 to this record only when it uses yourcompany.com as its MAIL FROM domain. A sending subdomain gets its own SPF record. A service that passes DKIM with a signing domain matching the visible From domain needs no entry here (Microsoft Learn: Set up DMARC). Edit the existing record; never add a second one. Microsoft says not to create a new SPF record when one exists, and that multiple SPF records make SPF return permerror (Microsoft Learn, Set up SPF).
Cutover day
Point MX to Microsoft 365
Copy the MX value from the Microsoft 365 admin center (Settings, Domains, the domain, DNS records). It is specific to the domain, so it is copied, never typed from memory. It usually ends in mail.protection.outlook.com (Microsoft Learn). A domain set up with DNSSEC in Exchange Online points to a name ending in mx.microsoft instead (Microsoft Learn: How SMTP DANE works).
Microsoft recommends priority 0, the highest, because lower numbers win, and a TTL of 3,600 seconds (one hour). Exchange Online supports only TTL values under six hours (Microsoft Learn).
Then remove every MX record that does not point to Microsoft 365. For Google, that is smtp.google.com, or on a domain that started with Google Workspace before 2023, older values that start with aspmx. An MX lookup such as dig +short MX yourcompany.com confirms that only the Microsoft host remains. Google tells its own customers to remove other MX records, because old ones can stop mail working correctly (Google Workspace Admin Help: Set up MX records). Microsoft does not support more than one MX record for a domain enrolled in Exchange Online (Microsoft Learn).
Microsoft's domain setup page also lists a second option: keeping Google's records at a lower priority than Microsoft's, which means a higher number (Microsoft Learn). Avoid it for a cutover. A lower-priority MX record is a backup, so sending servers try it whenever Microsoft's servers do not answer, and mail keeps arriving in Gmail long after the switch, even after a final copy pass. Giving both the same priority is worse: senders pick between them, and mail splits across both systems (RFC 5321 §5.1).
Add the Autodiscover record, and plan desktops and phones
Autodiscover lets Outlook and phones find the new mailbox from an email address alone. It is a CNAME record named autodiscover; copy its value from the admin center (Microsoft Learn, Cutover migration).
Autodiscover works when an account is set up. Plan for each person to add their Microsoft 365 account in Outlook and on their phone, signing in and completing a multifactor prompt each time. Before cutover day, test one Outlook setup and one phone setup.
Mail in flight
Changing the MX record does not redirect everyone at once. Senders that looked up the domain recently keep their cached answer until its TTL runs out, and Microsoft notes it can take up to 72 hours for other mail systems to recognize the changed record (Microsoft Learn: Cutover migration). Google quotes the same 72 hours for MX changes (Google Workspace Admin Help).
So for up to three days, some mail still lands in the old Gmail mailboxes. Migrations deal with that late mail in one of two orders. When Microsoft's own Google Workspace migration runs in batches, completing a batch runs one more sync and adds forwarding from Google to Microsoft 365 (Microsoft Learn), and the MX record changes after every batch is complete (Microsoft Learn). Microsoft notes that a single cutover migration from Google Workspace does not need those forwarding addresses (Microsoft Learn). Other migrations change the MX record first and copy the late mail afterward. In either order, two things hold:
- People stop working in Gmail at the switch, including for mail between colleagues, so new messages start in Outlook.
- The Google accounts stay active until the late mail has been collected or forwarded, and checked. Mail that lands in a suspended or deleted mailbox cannot be collected.
When the late mail is copied after the switch, two more apply:
- The final mail pass runs after the window, not right after the switch. A pass an hour after the change cannot collect a message that lands in Gmail the next day. An early pass is useful, and the pass that closes the move comes once the 72 hours have passed. Microsoft's guide for a cutover migration from Exchange makes the same point: before the migration batch is deleted, each mailbox has synced at least once after mail started arriving directly (Microsoft Learn: Cutover migration).
- A closing check comes before Google is turned off, at least a day after the final pass. Two of its parts need no message opened: one more pass copies nothing, and the public MX record names only Microsoft. The other two are tested by hand: a test message from outside reaches every migrated address in Outlook and not in Gmail, and no connector, transport rule, forwarding rule or Google-side routing still sends mail to Google. A rule can send one person's mail to Google while everyone else's arrives, or apply only to a kind of message nobody has tested, so test messages alone do not prove the routing.
- SwitchThe new MX record is published.
- 72 hoursThe delivery window ends: senders have picked up the change.
- Final mail passAny time after the window, never before it.
- Closing checkAt least a day after the final pass: nothing new copies, MX names only Microsoft, test messages reach every address in Outlook, and no rule still routes mail to Google.
- Google turned offOnly after the closing check passes.
After cutover: sign and protect the mail
Once Microsoft 365 is sending the domain's mail, DKIM and DMARC help receiving mail systems check that a message really comes from the domain. DMARC uses the SPF and DKIM results to tell receivers how to treat mail that fails, and each receiving system decides what happens to it (Microsoft Learn: Set up DMARC).
DKIM: a signature on every message
DKIM (DomainKeys Identified Mail) signs each outgoing message with a key receivers check against DNS. Microsoft 365 uses two CNAME records, selector1._domainkey and selector2._domainkey, with values copied from the Microsoft Defender portal or Exchange Online PowerShell; the examples in Microsoft's own documentation are for illustration only (Microsoft Learn: Set up DKIM).
Publishing the records does not turn signing on. Once Microsoft 365 detects them, signing is switched on for the domain in the Defender portal (Microsoft Learn).
DMARC: the policy, and the reports
DMARC is a TXT record named _dmarc that tells receivers what to do with mail failing the domain's SPF and DKIM checks, and where to send daily reports. A message passes DMARC when SPF or DKIM passes and lines up with the domain in the visible From address (Microsoft Learn: Set up DMARC). Microsoft recommends tightening it in stages, reading the reports at each step:
1 · Report only, block nothing v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@yourcompany.com- 2 ·
p=quarantine, optionally steppingpct, the percentage of failing mail the policy applies to, up through 10, 25, 50, 75 and 100. - 3 ·
p=reject.
Microsoft also recommends a dedicated mailbox for the reports rather than a person's inbox (Microsoft Learn). The reports list the sending sources that participating receivers observed, which is how an invoicing tool missing from the step 4 list often turns up. They do not prove the sender list is complete.
Tidy up SPF
Once Google no longer sends mail for the domain, include:_spf.google.com comes out of the SPF record. Microsoft then recommends ending the record with -all (hard fail) rather than ~all (soft fail), because the DMARC policy is effectively ignored for an SPF ~all failure when the message has no DKIM signature (Microsoft Learn: Set up SPF). Switch to -all only once the sender list from step 4 is complete, since unlisted senders then fail outright.
The Google verification record
A google-site-verification= TXT record proves ownership to Google Workspace, and Google says it can be safely removed once verification is done (Google Workspace Admin Help: Verify your domain). Google Search Console also verifies domains with a DNS TXT record and says to keep it to stay verified (Search Console Help). Before removing a Google verification record, check whether Search Console still relies on it.
Common mistakes
- Letting the domain setup wizard add the MX record early
- What happensMail moves to Microsoft 365 before mailboxes and data are ready.
- Avoid it byUse the wizard's Manual option, and change MX by hand on cutover day.
- Two SPF records
- What happensSPF returns permerror, and mail can fail its checks.
- Avoid it byEdit the one existing record.
- An SPF record that needs more than 10 DNS lookups
- What happensSPF fails with a permanent error (permerror), and some receivers bounce the mail.
- Avoid it byCount every term that triggers a lookup, including those inside records the SPF record includes, and move extra senders to subdomains.
- Forgetting a third-party sender
- What happensIf neither SPF nor DKIM passes and matches the visible From domain, its mail fails DMARC, and receivers can send it to spam or reject it.
- Avoid it byBuild the sender list before cutover, then read the DMARC reports.
- Switching MX with a long TTL
- What happensMail keeps arriving at Google for longer than planned.
- Avoid it byLower the TTL at least one old-TTL period ahead.
- Google and Microsoft MX at equal priority
- What happensMail splits between both systems.
- Avoid it byRemove Google's MX records at cutover.
- Removing only some of Google's MX records
- What happensA leftover Google record, such as an older one starting with aspmx, keeps a delivery path into Gmail.
- Avoid it byRemove every MX record that does not point to Microsoft 365, then check with an MX lookup.
- Keeping Google's MX as a lower-priority backup
- What happensMail lands in Gmail whenever Microsoft's servers are briefly unreachable, after the last copy.
- Avoid it byRemove Google's MX records at cutover.
- Turning off Google accounts right after the switch
- What happensMail delivered to Gmail in the 72-hour window is stranded.
- Avoid it byKeep the accounts active until the late mail has been collected or forwarded, and checked.
- Publishing DKIM records but never enabling signing
- What happensMail goes out unsigned.
- Avoid it byTurn on signing in the Defender portal once the records are detected.
- Jumping straight to p=reject
- What happensLegitimate mail that fails DMARC can be rejected.
- Avoid it byStart DMARC at p=none and read the reports.
Sources: the sections above, and Set up SPF, Set up DKIM, Set up DMARC, Connect your domain (Microsoft Learn) and Set up MX records (Google).
How MigrationSanity handles cutover
Your administrator changes the records on this page. MigrationSanity has no access to your DNS and changes nothing there. The copying is planned around the switch, so the MX record changes once, on cutover day, and a final pass collects the mail that still lands in Gmail afterward.
Before the switch
- Most of the data is copied before the cutover date, while mail keeps arriving in Gmail. On a date you agree on, people stop changing files, calendars and contacts in Google.
- Cutover is scheduled after you approve the migration plan, whose section on the switch names who changes what and when. A dry run, which reads both sides and copies nothing, must also show that the mail copy has caught up.
- Your administrator receives the steps for their own checks before the switch.
After the switch
- An optional early mail pass, about a day after the switch, brings most late mail across.
- The final mail pass runs no earlier than 72 hours after the switch and no later than 12 days after it.
- At least a day after the final pass, MigrationSanity runs the closing check, and no message is opened: one more pass copies nothing, and the public MX record names only Microsoft. The MX record is read from four public DNS resolvers, not from a local cache.
- Two more checks are your administrator's own: a test message from outside reaches every migrated address in Outlook and not in Gmail, and no connector, transport rule, forwarding rule or Google-side routing still sends mail to Google.
- Once the closing check passes, you are told in writing that the Google accounts can be turned off.
How this order differs from Microsoft's own tools
When Microsoft's own Google Workspace migration runs in batches, each batch is completed before the MX change. Completing a batch runs one more sync and adds forwarding from Google to Microsoft 365 (Microsoft Learn), and the MX record changes after that (Microsoft Learn). With MigrationSanity, your administrator changes the MX record first. The final pass follows at least 72 hours later, then the closing check, and then written confirmation that the Google accounts can be turned off.
This section follows the How it works page and the cutover terms in each client's migration plan. Some Google features work differently in Microsoft 365, and Known Google limitations describes how each one is handled.
Vendor pages checked October 2026. Microsoft and Google change their admin screens often, and the linked pages are the reference.