# How to migrate email from Google Workspace to Microsoft 365

URL: https://iblockspam.com/blog/migrate-google-workspace-to-microsoft-365-email
Last updated: 2026-10-22
Published: 2026-10-22
Topic: Switching & migration
Author: iBlockSpam Team

> Move Gmail to Exchange Online with Microsoft's migration tool: routing subdomains, mail users, EAC and PowerShell steps, then MX, SPF, DKIM and autodiscover.

## Short answer

Use the Google Workspace migration built into the Exchange admin center (Migration > Add migration batch > Google Workspace (Gmail) migration) or Exchange Online PowerShell. Create routing subdomains and mail users first, migrate users in batches, complete each batch, then point MX to Microsoft 365, update SPF, turn on DKIM and add the autodiscover record.

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](https://learn.microsoft.com/en-us/exchange/mailbox-migration/perform-g-suite-migration)). It doesn't change anything in DNS. You switch the MX record yourself at the end.

| Data | Migrated? | Limits Microsoft lists |
|---|---|---|
| Mail | Yes | Vacation and automatic reply settings aren't migrated. The largest single message follows your tenant's transport limit, [default 35 MB](https://iblockspam.com/blog/email-attachment-size-limits) |
| Gmail filters | Yes, as Outlook rules | Rules arrive turned off; users should check them before enabling |
| Calendar | Yes | Shared calendars and event colors aren't migrated |
| Meeting rooms | No | Room bookings aren't migrated |
| Contacts | Yes | Up to three email addresses per contact; Gmail tags, contact URLs and custom tags aren't migrated |

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](https://learn.microsoft.com/en-us/exchange/mailbox-migration/google-workspace-migration-prerequisites).

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](https://learn.microsoft.com/en-us/defender-office-365/outbound-spam-policies-external-email-forwarding)). 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](https://iblockspam.com/smtp-errors/550-5-7-520) 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](https://admin.exchange.microsoft.com/), 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](https://learn.microsoft.com/en-us/exchange/mailbox-migration/perform-gspace-migration-powershell), the same flow is (example values):

```powershell
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](https://learn.microsoft.com/en-us/exchange/mailbox-migration/how-it-all-works-in-the-backend)):

- **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](https://iblockspam.com/tools/email-header-analyzer). Our guide to [forwarding, SPF and ARC](https://iblockspam.com/blog/email-forwarding-breaks-spf-dmarc-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.

| Order | Record | Google Workspace value (example) | Microsoft 365 value (example) |
|---|---|---|---|
| 1 | SPF (TXT at root) | `v=spf1 include:_spf.google.com ~all` | During overlap: `v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all` |
| 2 | DKIM | `google._domainkey` TXT | `selector1._domainkey` and `selector2._domainkey` CNAMEs |
| 3 | MX | `MX 1 smtp.google.com.` | `MX 0 example-com.mail.protection.outlook.com.` |
| 4 | Autodiscover | none | CNAME `autodiscover` to `autodiscover.outlook.com` |
| 5 | Cleanup | Remove Google's SPF include and DKIM key | Final SPF: `v=spf1 include:spf.protection.outlook.com ~all` |

- **SPF.** Keep one record that lists both providers until nobody sends from Google, then remove Google. Microsoft's [DNS reference](https://learn.microsoft.com/en-us/microsoft-365/enterprise/external-domain-name-system-records) 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](https://iblockspam.com/blog/spf-softfail-vs-hardfail) helps you choose. Check it with the [SPF Checker](https://iblockspam.com/tools/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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure)). Our [DKIM setup guide](https://iblockspam.com/blog/dkim-setup-microsoft-365-google-workspace) 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](https://iblockspam.com/blog/change-mx-records-without-losing-email).
- **DMARC** usually stays the same. Watch [DMARC reports](https://iblockspam.com/blog/how-to-read-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](https://iblockspam.com/blog/microsoft-365-third-party-spam-filter-enhanced-filtering) covers each screen, and [block direct-to-tenant bypass](https://iblockspam.com/blog/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](https://iblockspam.com/blog/check-if-email-passed-spf-dkim-dmarc) 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](https://iblockspam.com/blog/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](https://iblockspam.com/tools/email-health-check) before you change anything, as your rollback plan.
- Going the other way? See [migrating from Microsoft 365 to Google Workspace](https://iblockspam.com/blog/migrate-microsoft-365-to-google-workspace-email).
- 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](https://iblockspam.com/platforms/microsoft-365), or use the [guided migration plan](https://iblockspam.com/migrate).

Browse our other [migration guides](https://iblockspam.com/blog/topic/migration).

## Frequently asked questions

### Does Microsoft's migration tool copy Gmail filters?

Yes. Gmail filters are migrated as Outlook rules, and they stay turned off until someone checks and enables them. Microsoft advises users to verify the rules in Outlook first. In PowerShell, -SkipRules leaves filters out, and -ExcludeFolder skips named folders or Gmail labels you don't want to copy.

### When should I change the MX record when moving from Google Workspace to Microsoft 365?

After all migration batches are complete. In Microsoft's staged design, MX stays on Google Workspace throughout, and forwarding through routing subdomains carries mail to users who have already moved. Once every batch is complete, a manual MX update points the domain at Microsoft 365.

### Do I need to license users before the Gmail migration starts?

No. Microsoft asks you to provision migrating users as mail users first. When the batch starts, they're converted to mailboxes, and Microsoft says the Exchange license must be assigned only after that moment. You then have 30 days to assign it.

### What doesn't move in a Google Workspace to Microsoft 365 migration?

Microsoft lists vacation and automatic reply settings, room bookings, shared calendars and event colors, contact URLs, Gmail tags and custom tags, and contact email addresses beyond the third. Its migration tool covers mail, calendar and contacts only, so plan Drive files and other data separately.

### Do I need routing subdomains for a small Gmail to Microsoft 365 move?

Plan on it. Microsoft lists both routing subdomains as prerequisites, and the Microsoft 365 one is the target delivery domain each batch asks for. If everyone moves in one batch and you switch MX the same day, forwarding only matters for a short window, but the subdomains and mail users still need to exist.

## Sources

- [Microsoft Learn: Perform a Google Workspace migration to Microsoft 365 or Office 365](https://learn.microsoft.com/en-us/exchange/mailbox-migration/perform-g-suite-migration)
- [Microsoft Learn: Google Workspace migration prerequisites in Exchange Online](https://learn.microsoft.com/en-us/exchange/mailbox-migration/google-workspace-migration-prerequisites)
- [Microsoft Learn: Perform an automated Google Workspace migration in the EAC](https://learn.microsoft.com/en-us/exchange/mailbox-migration/automated-migration-neweac)
- [Microsoft Learn: Perform Google Workspace migration using Exchange Online PowerShell](https://learn.microsoft.com/en-us/exchange/mailbox-migration/perform-gspace-migration-powershell)
- [Microsoft Learn: Overview of the Google Workspace migration process](https://learn.microsoft.com/en-us/exchange/mailbox-migration/how-it-all-works-in-the-backend)
- [Microsoft Learn: External Domain Name System records for Microsoft 365](https://learn.microsoft.com/en-us/microsoft-365/enterprise/external-domain-name-system-records)
- [Microsoft Learn: How to use DKIM for email in your custom domain](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure)
- [Microsoft Learn: Control automatic external email forwarding](https://learn.microsoft.com/en-us/defender-office-365/outbound-spam-policies-external-email-forwarding)

## Free tools for this guide

- [MX Lookup](https://iblockspam.com/tools/mx-lookup): See where your mail is delivered, spot unfiltered backup MX and broken hosts.
- [SPF Checker](https://iblockspam.com/tools/spf-checker): Count real DNS lookups, find PermErrors, loops and risky "all" settings.
- [DKIM Checker](https://iblockspam.com/tools/dkim-checker): Validate DKIM keys by selector, including key type and strength.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.

---

Source: iBlockSpam, https://iblockspam.com/blog/migrate-google-workspace-to-microsoft-365-email (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt