Google Workspace Email Migration Checklist: Verify SPF, DKIM, and DMARC Before You Go Live

Email migrations fail in predictable ways. The most common post-migration problem isn't lost data — it's deliverability failures caused by authentication records that were never set up on the new platform.

The safe principle is simple: authenticate first, cut over second, verify third. This checklist follows that order. Work through each section before proceeding to the next.

The Zero-Downtime Principle

Never update your MX records until authentication is configured and propagated. Your old and new mail systems can coexist during migration — mail continues flowing to your old platform while you set up and verify authentication on Google Workspace.

Cutting over before authentication is ready is the most common source of post-migration spam filtering.

Phase 1: Pre-Migration Audit

Before touching anything on the new platform, document what you currently have.

Authentication Audit

Run a free Full Audit on your current domain — record your existing SPF, DKIM, and DMARC configuration
Note your current DMARC policy level (p=none, p=quarantine, or p=reject)
Identify every third-party tool that sends email from your domain (marketing platform, CRM, support system, billing tool)
Confirm which of those tools currently pass SPF and DKIM on your existing platform

DNS Preparation

Log in to your DNS provider and confirm you have access to create and edit TXT and CNAME records
Check your current MX record TTL — set it to 300 seconds (5 minutes) at least 48 hours before your planned cutover date. This ensures MX changes propagate quickly when you're ready to cut over.
Note your current MX record values — you'll need them if you need to roll back

Phase 2: Google Workspace Authentication Setup

Complete this phase while your old platform is still active. Do not change MX records yet.

SPF Setup

Check whether an SPF TXT record already exists at your root domain

If one exists, edit it. Don't create a second — having two SPF records makes both invalid.

Add the Google Workspace SPF include to your existing record:

include:_spf.google.com

A minimal Google Workspace-only SPF record looks like:

v=spf1 include:_spf.google.com ~all

If you use other sending tools, include them as well. Keep the total DNS lookup count under 10. See how to add third-party senders to your SPF record for platform-specific include strings and how to manage the lookup limit.

Save the SPF record
Wait 24–48 hours for propagation
Verify using a free SPF checker — confirm the record is valid and includes _spf.google.com

DKIM Setup

Log in to Google Admin Console (admin.google.com)
Navigate to Apps → Google Workspace → Gmail → Authenticate email
Select your domain
Click Generate new record
Copy the TXT record Google provides — it will look like:
- Host: google._domainkey.yourdomain.com
- Value: v=DKIM1; k=rsa; p=MIIBIj... (long public key)
Add this TXT record to your DNS
Wait 24–48 hours for propagation
Return to Gmail settings in Admin Console
Click Start authentication to enable DKIM signing

Important: Do not enable DKIM signing before the DNS record has propagated. Google will verify the record is live before activating signing.

Verify DKIM is active: send a test email to a Gmail address and check the headers for DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com

DMARC Setup (if not already present)

If you don't have a DMARC record, add one now:

Create a TXT record in DNS:
- Host: _dmarc.yourdomain.com
- Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
- TTL: 3600

Start with p=none — monitoring mode. This doesn't affect delivery and begins populating aggregate reports once you start sending through Google Workspace.

If you already have a DMARC record from your previous platform, it will continue to function. Review it after cutover — see DMARC policy progression for when to move to enforcement.

For detailed DMARC setup steps, see the full DMARC setup guide for Google Workspace.

Phase 3: Pre-Cutover Verification

Do not change your MX records until all of these pass.

Authentication Verification Checklist

SPF check passes for your domain (free SPF checker)
DKIM signature present in test email headers
DMARC record exists at _dmarc.yourdomain.com
Run a free Full Audit — confirm SPF, DKIM, and DMARC all pass
Domain is not on any email blacklist (free blacklist check)

Red Flags — Do Not Cut Over Until Resolved

SPF record is invalid or exceeds 10 DNS lookups
DKIM TXT record hasn't propagated yet (check with a DNS lookup tool)
DKIM signing not activated in Google Admin Console
Any active blacklist listing on your current domain
Third-party senders not yet added to SPF

Phase 4: MX Cutover

Only proceed once Phase 3 is complete and verified.

MX Record Update

Log in to your DNS provider
Update MX records to Google Workspace values:

Priority	Mail server
1	`aspmx.l.google.com`
5	`alt1.aspmx.l.google.com`
5	`alt2.aspmx.l.google.com`
10	`alt3.aspmx.l.google.com`
10	`alt4.aspmx.l.google.com`

Save changes — propagation time depends on your TTL (should be fast if you set it to 300s in Phase 1)
Send a test email from an external account (Gmail, Outlook) to your domain — confirm it arrives in Google Workspace

Keep Old MX Records Available

Where possible, don't delete old MX records immediately. Leave the cutover window open for 24–48 hours to catch any email that routes to the old system during propagation. Forward or redirect any email that arrives at the old platform during this window.

Phase 5: Post-Migration Verification

Run these checks 24–48 hours after cutover.

Run a Full Audit again — confirm SPF, DKIM, and DMARC still pass after MX cutover
Verify DKIM is signing outbound mail from Google Workspace (send test, check headers)
Confirm all third-party senders are in your SPF record and passing authentication
Check that no new blacklist listings have appeared
Confirm DMARC aggregate reports are arriving at your rua address
Remove old MX records once you're confident cutover is complete

Third-Party Sender Verification

Each tool that sends email from your domain needs to be verified post-migration:

Marketing platform (Mailchimp, HubSpot, Klaviyo, etc.)
CRM (Salesforce, HubSpot CRM)
Support platform (Zendesk, Intercom, Freshdesk)
Billing and invoicing tools

Send a test email through each platform and confirm it shows spf=pass and dkim=pass in the headers. See how to add third-party senders to your SPF record if any fail.

Planning DMARC Enforcement Post-Migration

If your DMARC policy is p=none (monitoring only), plan to progress to enforcement after migration is stable. The recommended timeline:

Weeks 1–4 post-migration: Monitor DMARC aggregate reports. Identify all sending sources. Confirm pass rates.
Weeks 4–8: Move to p=quarantine once all legitimate senders pass consistently.
Weeks 8–12: Move to p=reject once no false positives appear at quarantine.

For the complete guide to DMARC policy progression, including how to read aggregate reports and what to look for before moving to enforcement, see our DMARC policy explainer.

If you're setting up Microsoft 365 instead of or alongside Google Workspace, the Microsoft 365 authentication guide covers the equivalent setup steps.

For a full overview of SPF, DKIM, and DMARC and why all three are needed, see the authentication explainer.

Why Migrations That Skip This Break

The pattern is consistent. A business migrates to Google Workspace, their IT person updates the MX records and calls it done. SPF still points to the old platform. DKIM is never enabled on Google Workspace. DMARC stays at p=none indefinitely.

Three months later: deliverability issues, emails landing in spam, a spoofing incident the business can't explain.

The fix is an hour of DNS work done in the right order. This checklist is that order.

Get a free Full Audit PDF — verify your Google Workspace email is fully authenticated post-migration at EmailAudit.io

Checks SPF, DKIM, DMARC, blacklists, and MTA-STS. Delivers a branded PDF report you can share with stakeholders. No account required.