emailmigrationdevops

Email Migration Sprint: A DevOps-Style Playbook After Google's Gmail Decision

ppyramides

2026-01-26

9 min read

A DevOps-style 48–72h playbook for migrating mail after Google's 2026 Gmail decision — with DNS, SPF/DKIM/DMARC, scripts and rollback plans.

Hook: You need a migration sprint—fast, safe, and automated

If Google’s January 2026 Gmail decision left your organization rethinking addresses, data access, or vendor risk, you’re not alone. Security teams worry about expanded AI features that may access mail content, admins worry about OAuth tokens and third-party integrations, and DevOps teams need a plan that won’t break production. This playbook is a DevOps-style sprint to move users to a new email domain or provider quickly and safely, with automation scripts, DNS checks and authentication updates you can run now.

Executive summary — what this sprint delivers (48–72 hours)

In a compact migration sprint you will: discover mail assets, stage authentication (SPF/DKIM/DMARC), prepare DNS (TTL, MX), set up dual delivery to avoid message loss, migrate mailboxes in parallel, validate mailflow and authentication, and decommission the old setup or keep it as a fallback. The playbook focuses on repeatable automation and rollback-safe steps so technical teams can execute under pressure—use a portable, auditable IaC approach and follow secure collaboration workflows for approvals and change control.

Why migrate now (2026 context)

Google’s change to Gmail in early 2026 — and the expanded AI features that may access mail content — accelerated an already growing trend: organizations are revisiting email ownership, privacy and vendor lock-in. Recent late‑2025 and early‑2026 trends include faster adoption of MTA-STS, TLS-RPT, and DMARC enforcement in larger providers, plus stricter regulatory focus on data portability. If you’re concerned about automated access, compliance, or wanting to control your mail routing, a carefully executed migration sprint is the right tactical move.

Source context: Forbes and other publications reported on Google’s January 2026 Gmail changes and the resulting surge in migration planning.

Overview: Sprint phases and timeline

Discovery & inventory (0–8 hours)
Design & staging (8–24 hours)
Cutover & migration (24–48 hours)
Validation & monitoring (48–72 hours)
Cleanup & decommission (after 72 hours)

Phase 1 — Discovery & inventory (automation first)

The fastest failures happen when you don’t know what you’re moving. Focus on a full inventory: users, aliases, groups, forwarding rules, delegated access, OAuth apps, third-party SMTP senders (CI systems, CRMs), and DNS records that reference your domain.

Essential commands and tools

Google Workspace: GAM (Google Apps Manager) to list users and aliases
```
gam print users > users.csv
gam print aliases > aliases.csv
```

Microsoft 365 / Exchange PowerShell

Connect-ExchangeOnline
Get-Mailbox -ResultSize Unlimited | Export-Csv mailboxes.csv -NoTypeInformation

IMAP mailbox counts (quick check with imaplib or dovecot’s doveadm)
```
doveadm mailbox status -u user@example.com all
```

DNS and MX checks

dig +short MX example.com
dig +short TXT example.com
host -t mx example.com

Export lists to CSV and tag rows: critical services, service accounts, and high‑volume senders. Prioritize these in your migration waves.

Phase 2 — Design & staging (prepare DNS and auth)

Authentication and DNS changes are the riskiest part. Reduce TTLs early, stage SPF/DKIM/DMARC, and prepare MX change plans with clear rollback. Use infrastructure as code for DNS (Terraform, Pulumi) so changes are auditable and reversible.

DNS best practices for the sprint

Lower MX TTL to 300 seconds at least 24–48 hours before cutover.
Publish staged SPF records that include both old and new providers during dual delivery.
Generate new DKIM keys for the new provider and publish public keys in DNS before switching MX.
Use DMARC policy p=none during cutover and increase to quarantine/reject after observing reports.

Sample DNS record templates

MX:

@  IN MX 10 mx1.newmail.example.com.
@  IN MX 20 mx2.newmail.example.com.

SPF (stick to 255 char chunks if needed):

@  IN TXT "v=spf1 include:oldmail.example.com include:newmail.example.com -all"

DMARC (start with monitoring):

_dmarc  IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100"

DKIM (example selector mail2026):

mail2026._domainkey  IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Automation: a simple bash check for DNS and propagation

#!/bin/bash
DOMAIN=example.com
echo "MX records:"
dig +short MX $DOMAIN

echo "SPF (TXT):"
dig +short TXT $DOMAIN | sed 's/"//g'

echo "DMARC:"
dig +short TXT _dmarc.$DOMAIN | sed 's/"//g'

Run this from multiple locations (CI runners, cloud instances in different regions) to verify global propagation—use distributed runners and edge hosts described in the edge hosting playbook for better coverage.

Phase 3 — Migration strategies and tools (mailflow continuity)

Choose a migration pattern depending on risk appetite and scale. For fast, low-risk migration consider dual delivery or split delivery for a short validation window. For full cutover, a coordinated MX swap with mailbox sync is typical.

Dual delivery (recommended for 48‑hour sprints)

Configure old provider to forward or relay a copy to the new provider for each user.
Start mailbox sync in parallel (imapsync or provider migration APIs) to copy existing mail into new inboxes.
After verifying new mailboxes and delivery, swap MX and reduce reliance on the old provider.

imapsync example for parallel mailbox migration

imapsync --host1 imap.olddomain.com --user1 user@olddomain.com --password1 'OldPass' \
         --host2 imap.newdomain.com --user2 user@newdomain.com --password2 'NewPass' \
         --syncinternaldates --maxsize 500M --nofoldersizes --split1 10

Use per-user parallelism with careful throttling and logging. For Google Workspace use the Data Migration API or GAM where available.

Provider APIs and automation examples

Bulk update primary email addresses using GAM:

# CSV: old_email,new_email
while IFS=, read old new; do
  gam update user $old email $new
done > gam_update.log

Exchange / Microsoft 365 PowerShell to set primary SMTP:

Import-Csv users.csv | ForEach-Object {
  Set-Mailbox -Identity $_.OldPrimarySmtpAddress -PrimarySmtpAddress $_.NewEmail
}

Phase 4 — Validation and monitoring (test everything)

After cutover, validate inbound and outbound, authentication results, and monitoring. Get DMARC reports and inspect them for SPF/DKIM alignment issues. Pair your monitoring data with a short-term forecasting and alerting approach so you can detect trends quickly.

Quick validation commands

Check MX: dig +short MX example.com

SMTP STARTTLS test with OpenSSL:

openssl s_client -connect mx1.newmail.example.com:25 -starttls smtp -crlf

Send a test message and verify headers show DKIM-Signature and SPF pass.

Use swaks to test send and authentication headers:

swaks --to user@newdomain.com --from test@external.com --server mx1.newmail.example.com --timeout 30

DKIM verification with dkimverify/dkimpy or online checkers.

Automated validation script (bash)

#!/bin/bash
DOMAIN=newdomain.com
MX=$(dig +short MX $DOMAIN | sort | head -n1)
if [ -z "$MX" ]; then
  echo "No MX found for $DOMAIN"; exit 1
fi

# Test SMTP connectivity via swaks (requires swaks installed)
swaks --to ci-test@$DOMAIN --from test@external.com --server $(echo $MX | awk '{print $2}') --timeout 20

# Verify SPF
dig +short TXT $DOMAIN | grep "v=spf1" || echo "No SPF"

# Check DMARC
dig +short TXT _dmarc.$DOMAIN || echo "No DMARC"

Phase 5 — Rollback criteria and quick recovery

Plan explicit rollback triggers before you touch MX: catastrophic delivery loss, authentication failures that cannot be fixed in 60 minutes, or major apps failing to authenticate. Because you reduced TTL earlier, a rollback is a DNS change and a quick switch of MX back to the old provider. Make sure your runbook includes an approval flow and audit trail per the secure collaboration guidelines.

Rollback steps: publish old MX, revert SPF to old includes, disable DKIM selector on new provider if necessary.
Keep old provider running for at least 7–14 days as mail-forward fallback.

Common issues and troubleshooting

SPF failures: missing include mechanisms for third-party senders — add them to staged SPF.
DKIM mismatches: ensure correct selector and TXT record formatting (no extra quotes/newlines).
DMARC enforcement spikes: keep p=none during cutover and inspect rua reports before tightening policy.
OAuth & API integrations: some apps rely on user@domain for tokens — plan token rotation and update service accounts; align your consent and token lifecycles with the consent capture playbook.

Automation scripts: DKIM key generation and DNS update example

Generate a DKIM keypair and print DNS record to paste into your DNS provider:

#!/bin/bash
SELECTOR=mail2026
DOMAIN=example.com
openssl genrsa -out ${SELECTOR}.private 2048
openssl rsa -in ${SELECTOR}.private -pubout -out ${SELECTOR}.public
PUB=$(openssl rsa -in ${SELECTOR}.private -pubout -outform PEM | sed -ne '1!p' | tr -d '\n')

echo "DNS TXT record for ${SELECTOR}._domainkey.${DOMAIN}:"
echo "v=DKIM1; k=rsa; p=${PUB}"

For programmatic DNS updates, use your DNS provider’s API or Terraform provider to apply the generated TXT record and keep the private key on the mail signing server (OpenDKIM, provider admin panel, etc.). Consider running updates from distributed CI runners and edge hosts described in the edge hosting guide to reduce single-region propagation blind spots.

2026 trends & future-proofing your email architecture

Looking forward into 2026, expect wider adoption of MTA-STS, TLS-RPT, and stricter DMARC enforcement. Zero-trust mail flows, stronger API governance, and vendor-neutral routing are becoming standard for enterprises. Key actions:

Automate DNS and email configuration with IaC (Terraform) and GitOps for auditability.
Rotate DKIM keys regularly and enable selector rotation automation.
Use MTA-STS and TLS reporting to harden SMTP transport security.
Manage OAuth app access centrally and plan token revocation as part of migration—align token lifecycle with the continuous authorization model.

Case study: 500-user migration in 48 hours (concise)

A SaaS company with 500 mailboxes used the sprint model and accomplished cutover in 48 hours. Highlights:

24 hours discovery and TTL reduction to 300s.
24 hours of staged DKIM publication and dual-delivery configuration.
Parallel imapsync jobs (50 concurrent workers) for mailbox sync.
Cutover at 02:00 UTC with MX swap and monitoring for 4 hours; visible message loss = 0; 12 OAuth apps needed reauthorization.
DMARC tightened to p=quarantine after 7 days and to p=reject after 30 days.

Actionable playbook checklist (copyable)

Inventory users, aliases, and third‑party senders (GAM/PowerShell/imapsync reports).
Reduce MX TTL to 300s (24–48h before cutover).
Publish staged SPF including both old and new providers.
Generate DKIM keys and publish public records prior to MX swap.
Keep DMARC at p=none and agree monitoring emails for rua/ruf.
Configure dual delivery or forwarding from old to new during interim.
- Start mailbox sync in parallel (imapsync or provider APIs).
Perform MX swap and monitor with swaks, openssl, and DKIM/SPF checks.
Verify delivery from external senders (CI systems, CRMs) and update SPF/MTA as needed.
Keep old provider as a fallback for 7–14 days and only decommission when stable.
Tighten DMARC and rotate DKIM selectors after monitoring a stable period.

Final notes — experience, risks, and governance

A sprint-style email migration is high-pressure but repeatable when backed by automation, clear rollback triggers, and observability. Keep stakeholders informed: security, compliance, SRE and desktop support must be aligned. Log all changes in a shared runbook and record the DNS transaction IDs and timestamps for audits.

Takeaways — what to do next (immediate)

Start an inventory export (GAM or PowerShell) now.
Lower MX TTL and prepare staged SPF/DKIM records.
Schedule a 48–72 hour sprint window with weekend or low-traffic hours.
Download and adapt the included automation scripts to your CI system.

Call to action

Ready to run this sprint with a proven checklist and automation pack? Download our migration script bundle, sample Terraform DNS modules, and a prebuilt validation suite — or book a 2‑hour sprint coaching session with our engineers to execute a secure, fast cutover. Click to get the resources and schedule help.

pyramides

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.