Migrating email to Google Workspace or Microsoft 365

Moving to Google Workspace or Microsoft 365 is really three moves: incoming mail (your MX records), outgoing mail (SPF and DKIM) and the contents of the existing mailboxes. Mail gets lost at the seams — in the hours when the MX records change, and in systems that still send through the old server because nobody remembered them. This guide goes through the DNS side in the order you need it.

Step 1: take an inventory

Before you touch DNS, write down:

• Every address that receives mail: users, aliases, groups and distribution lists, shared mailboxes, catch-all and forwarding rules. Each one must exist at the new provider before you switch MX. Microsoft’s documentation says to add users before updating the MX record; an address that doesn’t exist at the new provider bounces.
• Every system that sends with your domain: web shop, CRM, invoicing, helpdesk, newsletter service, scanners, monitoring scripts. Those that use the old provider’s SMTP server stop working when it is switched off and need new settings.
• Your current DNS records: MX, SPF, DKIM selectors (selector._domainkey), _dmarc, _mta-sts and verification records. Save a copy of the zone to compare against later.
• Who can change DNS on the day of the switch.

Step 2: lower the TTLs in advance

Resolvers cache a record for as long as its TTL says. If your MX records have a TTL of 86400 seconds (one day), some senders will keep using the old servers for up to a day after you change them.

At least one full TTL before the switch — usually a day before — lower the TTL of the MX and SPF records to about 300 seconds. The current value is in the second column:

$ dig +noall +answer MX example.com
example.com.  86400  IN  MX  10  mx.old-provider.example.

Wait until the old TTL has expired before changing the records themselves.

Step 3: prepare the new provider

1. Add and verify the domain. Both providers give you a TXT record that proves you own it. It doesn’t affect mail flow.
2. Create the users, groups and aliases from your inventory.
3. Start copying existing mail. Google offers a data migration service in the Admin console; Microsoft documents migrations from Exchange Server, from IMAP systems and from Google Workspace. Copy the bulk before the switch and run a final pass afterwards.

Step 4: switch the MX records

Google Workspace

Google’s current MX setup is a single record:

example.com.  3600  IN  MX  1  smtp.google.com.

Domains set up before 2023 may use the older values — several records whose names start with aspmx. Google still supports them, so a working setup doesn’t need to change. When the record is in place, click Activate Gmail for the domain in the Admin console (Account > Domains > Manage domains). Google says it can take up to 72 hours for new MX records to be recognized.

Microsoft 365

Don’t compose the value yourself — copy it from the Microsoft 365 admin center (Settings > Domains, select the domain, then DNS records). For many domains it has this form, where example-com is the MX token: your domain with the dots replaced by hyphens.

example.com.  3600  IN  MX  0  example-com.mail.protection.outlook.com.

Domains with DNSSEC enabled in Exchange Online use a host name under mx.microsoft instead, in the form <MX token>.<subdomain>.mx.microsoft. Whatever the admin center shows for your domain is the right value. Microsoft asks for the highest priority (typically 0) and notes that Exchange Online only supports TTLs shorter than six hours.

Microsoft 365 also uses an autodiscover CNAME to autodiscover.outlook.com, so Outlook finds the mailbox by itself.

Replace the old records — don’t keep them alongside

Google tells you to remove other MX records. Microsoft also allows giving them a lower priority, but then senders deliver to the old system whenever the new one can’t be reached — exactly the messages you will miss later. With equal priorities, senders pick a host at random and mail is split between the two systems.

Remove the old records and check the result with the MX lookup, which warns when hosts of different providers are mixed.

Step 5: SPF — one record for both systems

During the migration both the old and the new system send mail, so SPF has to authorize both. Keep one SPF record and add the new provider’s include to it:

; Google Workspace
example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.old-provider.example ~all"

; Microsoft 365
example.com.  TXT  "v=spf1 include:spf.protection.outlook.com include:spf.old-provider.example -all"

Google recommends ending with ~all; Microsoft’s examples use -all. What matters more is that there is a single v=spf1 record — Microsoft says explicitly not to create a second one. With two records, every SPF check fails with permerror.

Each include costs DNS lookups, and SPF allows ten. Run the SPF checker after every change; near the limit, see SPF: too many DNS lookups.

Step 6: DKIM in each admin console

DKIM is what usually makes DMARC pass, so set it up before outgoing mail moves, if you can.

Google Workspace. In the Admin console go to Apps > Google Workspace > Gmail > Authenticate email. After Gmail is turned on you may have to wait 24–72 hours before you can generate a key. Choose a 2048-bit key if your DNS host supports it, keep the default selector google and publish the TXT record Google shows at google._domainkey.example.com. Only then click Start authentication. According to Google, it can take up to 48 hours after you add the record for DKIM authentication to start working.

Microsoft 365. Microsoft’s documentation says mail from custom domains isn’t DKIM-signed with your domain until you configure it. In the Microsoft Defender portal open Email & collaboration > Policies & rules > Threat policies > Email authentication settings, tab DKIM, and select your domain. The portal shows two CNAME records to publish, in this form:

selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.<initial>.<partition>-v1.dkim.mail.microsoft.
selector2._domainkey.example.com.  CNAME  selector2-example-com._domainkey.<initial>.<partition>-v1.dkim.mail.microsoft.

<initial> is the first part of your onmicrosoft.com domain and <partition> a single character assigned by Microsoft; copy the exact values from the portal. (Domains added before May 2025 keep an older form ending in <initial>.onmicrosoft.com.) Once Microsoft detects the records, turn on Sign messages for this domain with DKIM signatures.

Leave the old provider’s DKIM records in place: selectors have different names, so they coexist, and the old system’s mail stays verifiable until it stops. Check each selector with the DKIM checker — google for Google, selector1 and selector2 for Microsoft; the checker needs the selector name. Background: How DKIM works.

Step 7: DMARC

If your domain already has a DMARC record, leave it unchanged during the migration, but know what it does:

• With p=none, nothing is blocked; the aggregate reports show whether the new provider’s servers pass.
• With p=quarantine or p=reject, mail from the new provider passes DMARC only if SPF or DKIM passes and is aligned with your domain. Publish the SPF include and turn on DKIM before users start sending from the new system.

If you don’t have DMARC yet, finish the migration first and then follow How to configure DMARC.

The switch and the coexistence period

On the day of the switch:

1. Confirm that every mailbox, alias and group exists at the new provider.
2. Replace the MX records.
3. Check them with the MX lookup and against a public resolver (dig @1.1.1.1 MX example.com).
4. Send test messages from an outside account to several addresses.

For the next few days, mail can still reach the old system: from senders whose resolvers cached the old records, and from messages queued for a retry — RFC 5321 says senders’ give-up time generally needs to be at least 4–5 days. Keep the old mailboxes running at least that long, and run a final copy (or set up forwarding) so nothing stays behind.

Moving users in batches

If you move people in groups rather than all at once, both systems must accept mail for the domain at the same time and pass on mail for users who aren’t there yet:

• Google Workspace calls this split delivery: Gmail delivers to its own users and routes the rest to the other server. Google recommends trying it with a small group first.
• Microsoft 365 documents a pilot in which MX stays with the old provider, which forwards the pilot users’ mail to Microsoft 365; the domain is set to Internal Relay in the Exchange admin center, with a connector back to the existing server. For on-premises Exchange Server, a hybrid deployment fills this role.

Check that everything works

Right after the switch, and again a few days later:

1. MX lookup — only the new provider’s hosts, all resolving.
2. SPF checker — one record, under ten lookups.
3. DKIM checker — a valid key under each new selector.
4. DMARC checker — the policy you expect.
5. A real message — send one from the new system to an external mailbox and paste its headers into the email header analyzer. You want spf=pass, dkim=pass for your own domain and dmarc=pass.

Clean up afterwards

When the old system has received nothing for a while and nothing sends through it any more:

• remove the old include from SPF and the old provider’s DKIM records;
• remove the old MX host from the MTA-STS policy;
• change any device or application that still points to the old SMTP server;
• raise the TTLs back, for example to 3600;
• only then cancel the old service.