How to migrate email from Google Workspace to Microsoft 365

Moving from Google Workspace to Microsoft 365 is two projects in one: copying mailbox data with Microsoft's migration tool, and moving mail routing and authentication DNS records without losing a message. This guide follows Microsoft's documented process at the time of writing (October 2026), with the portal path and the PowerShell equivalent for each step, and the DNS order that keeps mail flowing.

What does Microsoft's Google Workspace migration move?

Microsoft's built-in Google Workspace migration copies mail and rules, calendar, and contacts from Gmail into Exchange Online mailboxes, in batches of users (Microsoft Learn). It doesn't change anything in DNS. You switch the MX record yourself at the end.

Microsoft also warns that its tool "is currently unaware of tools enforcing messaging records management (MRM) or archival policies", so items those policies move show up as "missing". It "strongly recommends disabling all MRM and archival policies" before migrating. Google Workspace migration isn't available for GCC High or DoD tenants.

Which migration method should you choose?

Microsoft offers three ways to run the same migration: automated through the Exchange admin center (EAC), manual through the EAC, and Exchange Online PowerShell. The automated EAC flow creates the Google project, service account and key and enables the Gmail, Calendar and Contacts APIs for you; you still paste a ClientID and Scope into Google's API controls. PowerShell suits repeatable batches and scripted checks.

You also choose between a cutover (everyone at once, MX switched the same day) and a staged move (batches over days or weeks). Staged moves need routing subdomains so mail reaches each person wherever their mailbox currently lives. Microsoft's documented process is built around batches and lists both routing subdomains as prerequisites, so plan to create them even if you move everyone in one batch.

What do you need before you start?

Complete these in order. They come from Microsoft's prerequisites page.

1. Verify your domain in Microsoft 365. Add it in the Microsoft 365 admin center under Settings > Domains and add the verification TXT record. Don't change MX yet.
2. Get the right roles. In Microsoft 365, at minimum the Recipient Management role group. In Google Cloud, the migration admin needs project creation and service account creation rights (Microsoft names Project Creator and Create Service Accounts).
3. Create the Microsoft 365 routing subdomain (staged only). In the Google Admin console (Menu > Account > Domains > Manage domains), select Add a domain and enter one such as o365.example.com as a User alias domain. Point its MX at Microsoft 365 and add it as an accepted domain in Microsoft 365.
4. Create the Google routing subdomain (staged only). Add g.example.com (Microsoft's example is gsuite.fabrikaminc.net) as a user alias domain with Google's MX records. Google may take up to 24 hours to apply it.
5. Provision mail users in Microsoft 365. Each person needs a mail user with the same primary address, an ExternalEmailAddress pointing to their Google routing address (will@g.example.com), and a proxy address on the Microsoft 365 routing domain (will@o365.example.com).
6. Allow forwarding on both sides. The migration sets SMTP forwarding in Gmail, so Google must allow users to forward. If you use non-default transport settings in Microsoft 365, Microsoft says your default remote domain, or a remote domain for the Google routing domain, must have automatic forwarding enabled.
7. Turn off MRM and archive policies for migrating users until they're done.

Watch the outbound spam policy

Microsoft 365 may block automatic external forwarding by default. The default outbound spam policy setting, Automatic - System-controlled, has meant Off since 2021 for new organizations and for existing ones that weren't actively using it; a few older tenants still treat it as On (Microsoft Learn). During a staged move, mail for not-yet-migrated users is forwarded from Microsoft 365 back to Google. If forwarding is blocked, senders get 5.7.520 Access denied, Your organization does not allow external forwarding. Our 550 5.7.520 page explains the fix. Scope any exception to the migrating users, and remove it afterward.

How do you run the migration in the Exchange admin center?

1. In the Exchange admin center, go to Migration and select Add migration batch.
2. Name the batch and keep Migration to Exchange Online as the path. Select Next.
3. Choose Google Workspace (Gmail) migration as the migration type.
4. Under Automate the configuration of your Google Workspace for migration, select Start and sign in to Google. A JSON key file downloads, and the EAC shows a ClientID and Scope.
5. Open the API access link, select Add new in Google's API controls, paste the ClientID and Scope, and select Authorize.
6. Create a migration endpoint: give it a name, keep or change Maximum concurrent migrations (default 20) and Maximum concurrent incremental syncs (default 10), then enter the Google admin address and import the JSON key.
7. Import a CSV with an EmailAddress column (and Username if the Gmail address differs).
8. Select the Target delivery domain, your Microsoft 365 routing subdomain, and choose what to migrate: Mail, Calendar, Contacts and Rules.
9. Save. When the batch status changes from Syncing to Synced, complete the batch.

The PowerShell equivalent

In Exchange Online PowerShell, the same flow is (example values):

Test-MigrationServerAvailability -Gmail -ServiceAccountKeyFileData $([System.IO.File]::ReadAllBytes("C:\mig\key.json")) -EmailAddress admin@example.com
New-MigrationEndpoint -Gmail -ServiceAccountKeyFileData $([System.IO.File]::ReadAllBytes("C:\mig\key.json")) -EmailAddress admin@example.com -Name gmailEndpoint
New-MigrationBatch -SourceEndpoint gmailEndpoint -Name gmailBatch1 -CSVData $([System.IO.File]::ReadAllBytes("C:\mig\batch1.csv")) -TargetDeliveryDomain "o365.example.com"
Start-MigrationBatch -Identity gmailBatch1
Complete-MigrationBatch -Identity gmailBatch1

New-MigrationBatch also takes -ExcludeFolder to skip folders or labels and -SkipRules to leave Gmail filters behind.

Licensing timing

Microsoft is specific: when a batch starts, mail users are converted to mailboxes, and "the Microsoft 365 or Office 365 Exchange license must be assigned only after this moment. You have 30 days to assign the license." Assign licenses right after the batch starts, not before.

What happens to mail during a staged migration?

During a staged move, the MX record keeps pointing at Google, and forwarding moves each person's mail to the right side (Microsoft Learn):

• While a batch syncs, users still work in Gmail. Mail sent to them inside Microsoft 365 is forwarded back to Google through the Google routing subdomain.
• When you complete the batch, a final incremental sync runs, the Microsoft 365 forwarding is removed, and Gmail forwarding is added so new mail for migrated users goes to Microsoft 365 through the routing subdomain.
• After all batches, "a manual MX record update" points the domain at Microsoft 365, and the routing domains and extra aliases can be removed.

Forwarded mail can fail SPF at the receiving side, so check a few test messages in the Email Header Analyzer. Our guide to forwarding, SPF and ARC explains why.

Which DNS records change at cutover?

Change records in this order, using the exact values the Microsoft 365 admin center shows for your domain.

• SPF. Keep one record that lists both providers until nobody sends from Google, then remove Google. Microsoft's DNS reference shows one merged record as correct and two records as incorrect. Use ~all or -all to match your current record; our softfail vs hardfail guide helps you choose. Check it with the SPF Checker.
• DKIM. Publish the two CNAMEs, then enable signing in the Defender portal at Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, or with Set-DkimSigningConfig -Identity example.com -Enabled $true (Microsoft Learn). Our DKIM setup guide walks through it.
• MX. Microsoft says the Exchange Online MX should have a priority "lower than any other MX records", and that you should remove MX records pointing to your old system once mail flows. Lower the TTL a day ahead, as in our MX change checklist.
• DMARC usually stays the same. Watch DMARC reports for the first week: Microsoft 365 should appear as a passing source.

If a spam filter sits in front of Gmail

If your MX already points at a filtering service, you don't change MX at all. Instead, change the filter's delivery destination from Google to your Microsoft 365 host, and set up a Partner inbound connector with Enhanced Filtering for Connectors first. Our Microsoft 365 filtering setup guide covers each screen, and block direct-to-tenant bypass covers the lockdown afterward.

What should you check after the move?

1. Inbound: send from two or three outside providers and confirm the last hop is Exchange Online.
2. Outbound: send to an outside mailbox and confirm SPF, DKIM and DMARC pass. Our guide to checking authentication results shows where to look.
3. Rules: ask users to review migrated rules before turning them on.
4. Devices: remove Google accounts from phones and Outlook profiles, then add Microsoft 365.
5. Security settings: rebuild allow and block lists, forwarding restrictions and anti-phishing policies. Start with Microsoft 365 anti-spam policies.
6. Google tenant: keep it until the final syncs are done and no new mail arrives there, then remove the routing domains and aliases.

Next steps

• Copy your current MX, SPF, DKIM and DMARC records with the free Email Health Check before you change anything, as your rollback plan.
• Going the other way? See migrating from Microsoft 365 to Google Workspace.
• Run a one-user pilot batch to test the routing subdomains and forwarding before you move everyone.
• If you want filtering and outage spooling in front of Exchange Online after the move, see how iBlockSpam works with Microsoft 365, or use the guided migration plan.

Browse our other migration guides.