Skip to main content
GOOGLE WORKSPACE

Google Workspace Gmail Migration: DNS, SPF, DKIM and DMARC

Plan Gmail migration with mail inventory, migration scope, MX changes, sender authentication and delta checks.

Content update:

Architecture and operating model

Inventory users, aliases, groups, shared addresses, forwarding, archives and external senders first. Messages, calendars, contacts, delegation and permissions are different objects. Verify the migration tool’s source and object support. Copying messages does not prove calendar permissions or legacy integrations migrated.

MX controls inbound routing, SPF authorised envelope-sender sources, DKIM signatures and DMARC alignment with visible From. They are not substitutes. Replacing SPF for Google alone without preserving CRM, scanners and newsletters can break legitimate mail. Avoid conflicting multiple SPF records for one domain.

Obtain current Gmail MX instructions from the admin console and official documentation; legacy multi-record examples are not mandatory for every new tenant. DNS caches and TTL can route messages to different targets during transition. Separate initial import, final delta and routing change, and track the latest arrivals on both sides.

Acceptance covers inbound/outbound mail, aliases/groups, replies, invitations and client sign-in. Tighten DMARC using actual sender reports. Rollback must preserve messages and calendar changes created on the new side; restoring old MX alone is not complete rollback.

  1. 1Mail and object inventory
  2. 2Pilot / initial import
  3. 3DNS and final delta
  4. 4Delivery and authentication acceptance
Accept MX cutover together with data migration and sender authentication.

Design parameters

Object and tool scope
Document source/target support for messages, calendars, contacts and permissions separately.
DNS control
Validate MX, SPF, DKIM selectors and DMARC through authoritative DNS and actual messages.
Delta and overlap
Pilot repeated imports for duplicates, updated data and delivery routes.
Outage and rollback
Define sending/delivery limits, rollback decisions and new-data preservation.

Worked example

Pilot five varied users out of 100 mailboxes: a large archive, mobile client, assistant, group member and CRM sender. Compare dates, attachments, folder/label mapping and selected records alongside counts. Validate calendars and contacts separately according to source support.

After MX cutover, send from an external test address to each alias and group. Inspect SPF, DKIM and DMARC in Authentication-Results. Compare final delta with the last delivery to the old system. Use controlled test accounts rather than sharing users’ mail or passwords.

Troubleshooting

ObservationLikely cause / distinctionVerification
Incoming mail reaches the old systemResolver caches or incorrect MX scope may apply.Check authoritative MX, TTL and recipient domain together.
SPF pass, DMARC failSPF may not align with From and DKIM may not qualify.Compare envelope identity, From and DKIM d= in actual mail.
Messages arrive but delegation is missingThe tool may not cover permission objects.Check supported scope and target delegation separately.

Acceptance checks

  1. Accept MX cutover together with data migration and sender authentication.
  2. Cover all legitimate senders with SPF/DKIM.
  3. Test alias, group and reply delivery.
  4. Validate calendars and permissions separately.
  5. Reconcile final delta with new source data.
  6. Test new-message preservation during rollback.

Related concepts

DNS caching and dependencies

DNS results depend on client and recursive-resolver caches as well as authoritative data. Changing a TTL does not retroactively shorten already cached answers. A/AAAA, CNAME, MX and TXT records serve different purposes. Test internal and external views separately; split DNS may intentionally return different results. Record resolver, response type, TTL and query time when troubleshooting. Successful access by IP address alone does not prove correct DNS configuration.

Authentication and sessions

Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new accesses are denied when the identity provider becomes unavailable.

Application consistency

A copy that boots does not prove application-data consistency. Operating-system caches, database logs and write ordering across disks or services affect the result. A crash-consistent copy resembles recovery after an unexpected shutdown; an application-consistent copy follows supported application preparation and write coordination. Validate transaction integrity, relationships between records and application behaviour after recovery, rather than only counting files. Confirm backup integration, application version and reported errors before assuming that consistency was achieved.

Dependencies and restart order

Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, not merely an equipment list. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.

Policy lifecycle

A policy needs management as its scope changes, not just when it is enabled. Separate drafting, observation, pilot deployment, enforcement and periodic review. Every exception needs an owner, reason, scope and expiry date. A successful pilot can still cause production false positives if test data does not represent real user behaviour. Identify affected users and applications before deploying with measurable acceptance criteria. A rollback path should identify who may reverse the change and under which conditions, rather than merely locating an interface button.

Telemetry and time correlation

Telemetry combines logs, metrics and events that explain system behaviour. A log describes an event, a metric shows behaviour over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.

Primary documentation

Editorial method

Prepared by the Doz Technology technical team using official vendor documentation. Scenarios and calculations illustrate the method; they are not completed customer tests. Before implementation, verify versions, licences, client support, security conditions and rollback in your environment. Select solutions against existing products and workload requirements.

Enterprise IT Product Sales, Licensing and Deployment
Enterprise IT Project & Solution Scenarios
View all related content
Text on WhatsApp
Copied!