IT AdminEmail MigrationCompliance

A Sysadmin’s Checklist for Replacing Corporate Gmail: DNS, SSO, and Compliance

ttelework

2026-01-29

11 min read

Step-by-step sysadmin runbook to replace corporate Gmail in 2026: DNS, MX, SSO, migration tools, and compliance controls.

Stop guessing—start executing: a sysadmin’s technical runbook for moving your org off Gmail in 2026

If you’re reading this, you’ve likely been handed the unenviable task of moving corporate email off Gmail. Maybe it’s a policy decision after Google’s Jan 2026 product changes around AI data access, maybe it’s compliance, or maybe leadership wants a privacy-first provider. Whatever the trigger, this is a practical, step-by-step runbook built for hands-on IT teams: DNS, MX records, SSO, migration tools and compliance controls you must get right to avoid mail loss, outages, and regulatory risk.

Why 2026 is different: trends that affect your migration

In 2026 the email landscape has shifted in three important ways that should shape your plan:

Increased privacy scrutiny and vendor trust questions. After high-profile product changes from major providers in late 2025–early 2026, many organizations are demanding stronger data residency, explicit AI data usage policies, and customer-managed keys.
Passwordless & Zero Trust integration. SSO and device posture are now table-stakes for secure mail access; passkeys and FIDO2 are being rolled out in many IdPs.
More mature migration tooling and hosted alternatives. Privacy-first hosts and open-source stacks (Proton Mail Business, Fastmail, Mailcow, Zimbra) improved enterprise features and migration support—so you have real choices beyond Google or Microsoft.

Top-level migration strategy: Phased vs Big-bang

Choose the approach that matches your risk appetite and compliance obligations:

Phased (recommended for large orgs): Migrate department-by-department or use dual-delivery while verifying archives and retention controls.
Big-bang (small orgs with low risk): Lower complexity but requires flawless prep and a short maintenance window for cutover.

Pre-migration audit (the checklist you must finish before any cutover)

Run this audit first; missing items cause outages, lost mail, or compliance gaps.

Inventory mail assets: users, aliases, distribution lists, resources (rooms), shared mailboxes, delegated accounts, and service accounts. Export to CSV.
Mailbox size and feature mapping: measure mailbox sizes, labels vs folders, calendar usage, contacts, and Drive/Docs dependencies. Note features that may not map cleanly (e.g., Google Groups settings, chat history).
Compliance obligations: retention policies, legal holds, eDiscovery/Vault exports, HIPAA, GDPR/UK Data Protection, or sector-specific rules. Document locations of existing holds.
Apps and connectors: third-party apps with Gmail API access, SMTP relays, CI/CD notification addresses, forms, and mailing lists.
SSO and provisioning mapping: current IdP (Okta/Azure AD/JumpCloud/Keycloak), SCIM provisioning, MFA policy, and device posture checks.
DNS ownership and access: verify you have admin access to authoritative DNS and list all hosts that need updates.
Backup and rollback plan: take auditable backups (mailbox exports, Vault exports) and document rollback triggers.

DNS and MX planning: the heart of cutover

DNS changes are the single most visible risk. Get them right with precise sequencing.

1. MX records: design and test

Key points:

Lower MX TTLs early: Set MX TTL to 300 seconds (5 minutes) at least 48–72 hours before cutover so changes propagate quickly. Many teams reduce to 300 for 72 hours to make sure caches flush.
Dual-delivery during transition: Implement dual-delivery or split-routing so inbound mail delivers to both old and new systems while you sync mailboxes.
Order and priority: Ensure MX priorities reflect your inbound routing plan; lower numeric priority = higher precedence.

Practical rule: 48–72 hours before cutover, reduce MX TTL to 300 and confirm via dig or host lookups from multiple networks.

2. SPF, DKIM, DMARC: don’t break authentication

Authentication controls are critical to delivery. Your runbook should include:

SPF: Update your TXT SPF record to include the new email host (for example, include:spf.protonmail.ch or include:spf.fastmail.com) and phase out include:_spf.google.com only after all outbound flows move off Gmail SMTP. Keep SPF under 10 DNS lookups.
DKIM: Generate new DKIM keys on the new platform. Add the new selector TXT records before enabling signing. After signing, publish the new selector and phase out Google’s selectors once all outbound sends are verified.
DMARC: Start with p=none and reporting to collect RUA/RUF for 7–14 days. Then move to quarantine or reject based on telemetry. Make sure forensic reports (RUF) comply with privacy laws in your jurisdictions.
BIMI: Optional, but if you use BIMI, prepare the SVG logo and ensure DMARC policy is enforced.

3. Diagnostic checks

Before making public DNS changes, run:

dig +short mx yourdomain.com
dig +short txt yourdomain.com
MXToolbox.com checks for MX, SPF, DKIM, DMARC

SSO and provisioning: make identity the control plane

SSO is not optional. Matching how users authenticate and are provisioned keeps access controls consistent and reduces help-desk tickets.

SSO protocol choices: SAML vs OIDC

Most email providers support SAML or OIDC. Use whichever your IdP supports robustly. Key practical differences:

SAML is widely supported for classic SSO integrations (Okta, Azure AD, Keycloak). It’s stable and feature-rich for enterprise SSO.
OIDC is modern, supports mobile flows and passkeys better, and is a good choice if you want passwordless and FIDO2 integration.

SCIM provisioning and group sync

Automate user and group lifecycle with SCIM where possible. Verify these mappings:

userName → userPrincipalName / email
displayName, givenName, familyName
groups → access groups/mail lists

Test deprovisioning thoroughly: remove a user in the IdP and confirm the mail account is disabled and preserved per retention policy.

Conditional access and device posture

Implement conditional access rules that require compliant devices for mailbox access—especially for executives and sensitive mailboxes. In 2026 many platforms support device posture signals via Intune, Jamf, or endpoint posture services; tie those into your SSO policy.

Migration tools: which to choose and when

Pick tools according to scale, fidelity needs, and compliance requirements.

Open-source and free options

imapsync — reliable IMAP-to-IMAP sync, ideal for many mail hosts and for incremental syncs. Great for custom scripts and automation.
rclone — useful for Drive/Docs migrations; supports many backends. Not for mailbox metadata.
Mailcow/Zimbra scripts — if you self-host, these projects provide import tools and community guidance.

Commercial migration platforms (enterprise scale)

BitTitan MigrationWiz — mature, handles mail, archives, calendars, and public folders with strong reporting.
Transend / CloudMigrator — good for complex mapping and legacy data sources.
Vendor-provided tools — Proton, Fastmail, and others now provide business migration services (2025–2026 improvements focused on Vault and retention compatibility).

Choosing a tool

Ask:

Can it preserve flags, read/unread state, labels, folder hierarchy, calendar attendees and free/busy?
Does it support incremental syncs and delta-only migrations to reduce cutover window?
Does it provide a detailed audit trail for compliance?

Migration runbook (step-by-step)

Use this practical runbook during execution. Treat each step as a gated checkpoint.

Pre-cutover
- Notify stakeholders and schedule maintenance windows with escalation paths.
- Confirm backups: export mailboxes, Vault/ehold exports, and save to immutable storage.
- Lower DNS TTLs (MX/TTL=300).
- Set outbound SMTP routing from apps to new SMTP relay (test with a subset of apps).
Provision accounts
- Sync users via SCIM or bulk-create through API.
- Apply mailbox quotas, retention tags, and resource calendars.
Initial data sync
- Run full IMAP migration with imapsync or MigrationWiz. Start with pilot users.
- Validate message counts, attachments, calendar invites, and shared calendar permissions.
Testing
- Confirm DKIM signing for drafts and outbound mail. Send test messages to Gmail, Outlook, and spam traps.
- Validate authentication via SSO and conditional access on multiple device types.
- Verify retention holds and that archived mail is discoverable via eDiscovery tools.
Cutover
- Switch MX records to the new host (remember TTL already reduced).
- Monitor mail flow closely for 24–72 hours; watch queues, bounce rates, and DMARC reports.
- Run a second incremental sync to capture late-arriving messages.
Post-cutover
- Raise DMARC policy to quarantine/reject gradually based on error reports.
- Deprecate Google SMTP relays and remove the Google SPF include when safe.
- Rotate DKIM keys and retire Google selectors.
- Reinstate MX TTLs to normal (e.g., 3600) after 72 hours of stable operations.

Compliance, legal holds and data export: don’t assume parity

Migration is not just mail delivery. Compliance teams expect continuous preservation, auditable exports, and the ability to respond to legal holds.

Export & chain of custody

Document every export. For Google Workspace you may have used Vault; for the new host gather equivalent proof:

Signed export manifests and checksums.
Immutable storage for backup files.
Audit logs showing export and import operations.

Retention and legal hold parity

Map old retention policies to the new platform. If the new vendor lacks equivalent retention/hold features, use an archiving vendor (Proofpoint, Mimecast, or an on-prem archive) to enforce holds.

Security controls

Ensure the provider supports customer-managed keys (BYOK) if required.
Turn on server-side encryption and, where feasible, end-to-end encrypted mail for sensitive teams.
Maintain SIEM ingest / observability for mail logs and set alerts for suspicious outbound spikes.

Common pitfalls and how to avoid them

Missing aliases and forwards: Create a complete alias map before cutover—these are easy to overlook.
Emails from apps continue to send via old SMTP: Update all application SMTP credentials and cron jobs as part of pre-cutover.
Broken calendar shares: Verify attendee histories and resource permissions in pilot migrations.
SPF lookup limits: If you see SPF validation fails, check included mechanisms and DNS-lookup budgets.

Provider selection quick comparison (2026 lens)

High-level pros and cons for typical choices in 2026:

Proton Mail Business: Best for strong privacy, end-to-end encryption options, and European data residency. Migration tooling improved in 2025–2026 but check feature parity for advanced archival needs.
Fastmail: Excellent IMAP compatibility and developer-friendly APIs; good for mid-sized teams wanting a simpler hosted mail stack.
Microsoft 365: Enterprise feature parity (retention, eDiscovery) but obviously another large cloud vendor with different trust implications.
Self-hosted (Mailcow, Zimbra, Dovecot+Postfix): Maximum control and potential cost savings, but requires significant operational expertise and hardened security posture (spam filtering, DKIM management, HA, backups).

Monitoring and post-migration hygiene

After cutover, watch these metrics closely for 30 days:

Inbound mail volume and latency
Bounce and NDR rates
SPF/DKIM/DMARC failure rates and aggregate reports
Help-desk tickets for login or delivery issues

Advanced strategies for high-security environments

If you manage very sensitive data consider:

Client-side encryption to ensure provider cannot access message content.
On-premise or dedicated tenancy with strict network egress controls.
Immutable journaling to an external archive provider for legal hold assurance.
Periodic audits and red-team tests on the mail flow and provisioning pipelines.

Actionable takeaways: the 10-point checklist you can use now

Complete inventory of mail assets and compliance requirements.
Reduce MX TTL to 300 for 72 hours before cutover.
Set up SSO (SAML/OIDC) and SCIM provisioning pre-cutover and test deprovision flows.
Publish new DKIM selectors and verify signing before cutover.
Update SPF to include new provider but retain Google includes until outbound is moved.
Run incremental IMAP syncs with imapsync or MigrationWiz; validate message counts.
Switch MX, monitor queues, and perform a final delta sync within 24 hours.
Raise DMARC policy based on telemetry; publish reports (RUA) to your security mailbox.
Ensure legal holds and retention mapped and auditable.
Reinstate normal TTLs and document all changes with timestamps and checksums.

Final notes: governance, documentation and communication

Communication is as important as the technical work. Keep stakeholders updated, publish a runbook for help-desk staff, and maintain a living migration log with timestamps for DNS changes, exports, and imports. In 2026, auditors expect demonstrable evidence of chain-of-custody for exported mail—don’t skimp on manifest files and checksums.

Example resources to bookmark

MXToolbox for MX/SPF/DKIM/DMARC checks
imapsync documentation and scripts for incremental migrations
Your IdP’s SAML/SCIM guide (Okta, Azure AD, JumpCloud)
Vendor migration guides (Proton/Fastmail/Microsoft)

Closing: why meticulous planning wins

Moving an entire organization off Gmail in 2026 requires coordinated DNS choreography, identity controls, compliant exports, and robust testing. The technical details above are the playbook that prevents mail loss and legal exposure. If you follow the runbook—audit first, stage and test, cutover with low TTLs, and validate retention—you’ll reduce outages and keep compliance teams happy.

Ready to execute? Download the printable checklist, or schedule a 30-minute planning call with our migration team to map this runbook to your environment. Start your migration with confidence—don’t let a DNS typo or missing legal-hold derail the project.

telework

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.