How to Fix DNS and Mail Flow Issues During Google Workspace to Microsoft 365 Migration

Posted at 16:49h in Blog, Microsoft 365, Migration by Nithin DG 0 Comments

Whether you’re mid-migration or just starting to plan your Google to Microsoft migration, one thing is certain: DNS is where most migrations succeed or fail. A misconfigured MX record, a forgotten SPF entry, or a rushed DNS cutover can trigger email outages, bounce messages, or authentication failures that erode user trust and business continuity.

Why Does DNS Matter So Much in a Google Workspace Migration?

DNS (Domain Name System) is the backbone of every email interaction. When you migrate Google Workspace to Microsoft 365, you’re essentially redirecting your domain’s email infrastructure from Google’s servers to Microsoft Exchange Online. Every DNS record you change—MX, SPF, DKIM, DMARC, and Autodiscover—tells the internet where to route your email, how to authenticate it, and how clients like Outlook connect.

Get DNS right, and your migration is invisible to end users. Get it wrong, and you’re facing:

Emails bouncing or silently dropping

NDRs (Non-Delivery Reports) flooding user inboxes

Outlook failing to auto-configure

Spam filters rejecting outbound mail

Teams or SharePoint integrations breaking

What DNS Records Are Involved in a Microsoft 365 Migration?

DNS Record	Purpose in M365 Migration
MX	Routes inbound email to Exchange Online mail servers.
Autodiscover (CNAME)	Enables Outlook to automatically configure email profiles.
SPF (TXT)	Authorizes Microsoft 365 servers to send email on behalf of your domain.
DKIM (CNAME/TXT)	Cryptographically signs outbound email to prevent spoofing.
DMARC (TXT)	Enforces SPF/DKIM policies and provides reporting for email abuse.
SRV	Supports Skype for Business/Teams federation and service discovery.
Additional CNAMEs	Required for Exchange ActiveSync, MDM enrollment, and Microsoft Teams integration.

MX Records

The MX record is the most critical change in any Migrate Google to Microsoft project. Before cutover, your MX points to Google (aspmx.l.google.com). After cutover, it must point to your Exchange Online tenant
(yourdomain-com.mail.protection.outlook.com). Until this record changes—and propagates—all inbound email continues routing to Google.

SPF Records

A common error: organizations delete their Google SPF entry and replace it with Microsoft’s include:spf.protection.outlook.com but forget to remove conflicting Google entries. The result is an SPF record with too many DNS lookups, causing a “PermError” that fails authentication silently. Your final SPF record should look like:

v=spf1 include:spf.protection.outlook.com -all

Remove all include:_spf.google.com references after cutover is complete.

DKIM

Microsoft 365 DKIM requires you to publish two CNAME records in your DNS pointing to Microsoft’s signing infrastructure. Until you enable DKIM in the Microsoft 365 Defender portal and validate those CNAMEs, outbound mail will either be unsigned or signed with the default .onmicrosoft.com domain, which can cause deliverability issues with strict-filtering recipients.

DMARC

DMARC doesn’t block mail on its own, but a misconfigured DMARC policy during migration—especially P=reject—can cause legitimate mail to be silently dropped if SPF or DKIM alignment fails during the transition window. Start with p=none during migration, then tighten to p=quarantine or p=reject post-migration after verifying reports.

How Does Email Routing Work Before, During, and After Migration?

Before Migration (Google Workspace Active)

All MX records point to Google. SPF includes Google’s servers. DKIM is signed by Google. No Microsoft DNS records are published yet.

During Migration (Coexistence/Hybrid Phase)

This is the most complex phase of a Google Workspace to Microsoft 365 migration. Some mailboxes have been migrated to Exchange Online, while others remain in Google Workspace. Mail must route correctly to each user regardless of where their mailbox lives.

Common coexistence approaches:

Dual MX routing: Keep Google MX active; add Exchange Online connectors to forward mail to migrated users. Risk: spam filters may penalize dual-MX configurations.
Exchange Online as primary inbound: MX points to Microsoft; a connector forwards unmigrated users’ mail back to Google. Requires precise connector configuration.

Third-party migration platforms: Tools like MigrationWiz or BitTitan can manage coexistence routing, reducing manual connector complexity.

After Migration (Microsoft 365 Active)

MX records point exclusively to Exchange Online. SPF references only Microsoft servers. DKIM CNAMEs are live. DMARC is enforced. Autodiscover resolves to Microsoft. Google DNS entries are removed.

What Are the Most Common DNS Misconfigurations That Break Mail Flow?

1. Updating MX Too Early

If you switch MX to Exchange Online before mailboxes are migrated, inbound mail arrives at Microsoft with nowhere to deliver—generating NDRs or bouncing messages back to senders.

Fix: Only update MX after the majority of mailboxes are migrated, or use connector-based routing during coexistence.

2. Forgetting to Remove Google's SPF Entry

Dual SPF entries create lookup failures. Most email systems perform a maximum of 10 DNS lookups per SPF evaluation. Leaving both Google and Microsoft entries can push you over this limit.

Fix: After cutover, audit your SPF record with tools like MXToolbox or Dmarcian and consolidate to a single, streamlined record.

3. Not Publishing DKIM CNAMEs Before Sending

If users begin sending email from Exchange Online before DKIM is configured, outbound mail is either unsigned or signed with the default on the onmicrosoft.com domain, raising red flags for recipient spam filters.

Fix: Publish DKIM CNAMEs and enable DKIM signing in Microsoft 365 Defender before switching MX.

4. Autodiscover Conflicts

If your old Autodiscover CNAME or SRV record still points to Google’s autodiscovery service, Outlook clients will fail to configure or will continuously prompt for credentials.

Fix: Update the Autodiscover CNAME to autodiscover.outlook.com as part of DNS cutover.

5. Split-Brain DNS

Organizations with internal DNS servers that don’t mirror external DNS changes will have on-premises clients resolving to old Google records while external senders reach Microsoft correctly—creating confusing, intermittent mail flow failures.

Fix: Audit both internal and external DNS zones and synchronize changes.

How Do DNS Propagation Delays Impact Migration Timelines?

DNS propagation isn’t instant. TTL (Time to Live) values determine how long DNS resolvers cache your records before checking for updates. If your MX record has a 24-hour TTL and you make a change, some mail servers won’t see the new record for up to 24 hours.

Best practice: Lower your TTL values to 300–600 seconds (5–10 minutes) at least 48 hours before your DNS cutover. After migration is confirmed stable, reset TTLs to normal values (3,600+ seconds).

During the propagation window, you’ll experience split routing where some senders reach Exchange Online while others still route to Google. This is normal and expected — it’s why maintaining coexistence routing during this window is critical.

Step-by-Step: How to Troubleshoot Mail Flow Issues After Migration

Step 1: Identify the Failure Type

Use Microsoft 365’s Message Trace (Exchange Admin Center > Mail flow > Message trace) to determine whether mail is being received, rejected, or silently dropped. Filter by sender, recipient, or time range to isolate the issue.

Step 2: Validate DNS Records

Run DNS lookups against your domain using:

MXToolbox.com — MX, SPF, DKIM, DMARC, and Autodiscover checks

Google Admin Toolbox (toolbox.googleapps.com) — DNS propagation checker

nslookup / dig (command line) — Precise record inspection from specific DNS resolvers

Step 3: Run Microsoft 365 Diagnostics

In the Microsoft 365 Admin Center, use the Support and Recovery Assistant (SARA) or built-in diagnostic tools to test:

Mail flow from/to specific addresses

Connector health

Exchange Online Protection (EOP) filter decisions

Step 4: Check Connector Configuration

If you used connectors for coexistence routing, verify they are disabled or removed post-migration. Residual connectors pointing to Google’s SMTP servers after cutover can cause mail loops, duplicate delivery, or routing failures for specific sender/recipient combinations.

Step 5: Validate Email Authentication

In the Microsoft 365 Defender portal (security.microsoft.com):

Navigate to Email & Collaboration > Policies & Rules > Threat Policies > DKIM

Confirm DKIM is enabled and both selectors show as “valid.”

Test inbound email headers to verify SPF pass, DKIM pass, and DMARC alignment

How to Resolve Specific Mail Flow Problems

Bounced Emails / NDRs After Migration

Likely cause: MX was updated before mailboxes were migrated, or the recipient mailbox doesn’t exist in Exchange Online.

Fix: Verify the recipient mailbox exists in Exchange Online using the Exchange Admin Center. Check if licenses are assigned. If migrating in batches, ensure all active users are fully migrated before DNS cutover.

Emails Going to Spam After Migration

Likely cause: SPF or DKIM not yet configured for the new sending domain, or DMARC is overly restrictive during transition.

Fix: Verify SPF includes spf.protection.outlook.com, enable DKIM in Defender, and set DMARC to p=none temporarily while monitoring aggregate reports via DMARC analyzers.

Outlook Not Connecting After Migration

Likely cause: Autodiscover CNAME not updated, or old Outlook profiles cached Google server settings.

Fix: Update Autodiscover CNAME to point to autodiscover.outlook.com. Ask users to remove and re-add their email accounts in Outlook, or use the Microsoft Support and Recovery Assistant to repair the profile.

Duplicate Email Delivery

Likely cause: Active connectors are forwarding copies of mail to Google while Exchange Online also receives it via MX.

Fix: Disable all Google Workspace inbound connectors in Exchange Online immediately after DNS cutover is confirmed.

Need Expert Help to Fix DNS and Mail Flow Issues During Your Migration?

Ensure a seamless Google Workspace to Microsoft 365 migration with expert guidance. We help you resolve DNS, mail flow, authentication, and email delivery issues while minimizing downtime and business disruption.

Post-Migration DNS Validation Checklist

Use this checklist within 24–48 hours of DNS cutover to confirm a successful Migrate Google Workspace to Microsoft 365 project:

MX records point exclusively to Exchange Online (*.mail.protection.outlook.com)

SPF record updated — Google entries removed, Microsoft entries present

DKIM selectors (selector1 and selector2) show as valid in Microsoft 365 Defender.

The DMARC record is published and monitoring is active.

The Autodiscover CNAME resolves to autodiscover.outlook.com

No residual Google Workspace DNS records remaining (old SPF, DKIM, MX)

Workspace DNS records remaining (old SPF, DKIM, MX)

Test inbound email received and delivered correctly

Test outbound email to pass SPF, DKIM, and DMARC at the recipient

Outlook profiles auto-configure without manual server entry

Teams and SharePoint integrations are functional.

Message trace shows no unexpected routing decisions.

TTL values restored to production levels

Common Migration Mistakes and How to Avoid Them

Avoid these frequent migration errors:

Updating DNS before migration completes.
Forgetting to reduce TTL.
Publishing multiple SPF records.
Leaving Google MX records active.
Ignoring DKIM activation.
Misconfiguring transport connectors.
Skipping validation testing.
Not monitoring Message Trace.
Removing Google services too early.
Failing to document DNS changes.

Preventing these mistakes significantly improves migration success rates.

Organizations with Complex Environments: When to Seek Expert Help

Many IT teams successfully manage smaller Google Workspace migrations in-house, but organizations with shared mailboxes, distribution lists, large user bases, third-party email security gateways (like Proofpoint or Mimecast), custom mail flow rules, or on-premises Exchange servers face significantly higher risk of DNS and mail flow complications.

In these scenarios, engaging certified Google Workspace to Microsoft 365 migration services providers ensures that DNS planning, coexistence routing, connector configuration, and post-migration validation are handled with the precision and experience that complex environments demand.

Frequently Asked Questions (FAQs)

How long does DNS propagation take during a Microsoft 365 migration?

Propagation time depends on your current TTL settings. If TTL is set to 3,600 seconds (1 hour), changes may take up to 1 hour to fully propagate worldwide. If TTL is 24 hours (86,400 seconds), expect up to 24 hours of split routing. Best practice is to lower TTL to 300 seconds at least 48 hours before your planned DNS cutover.

Why are some users still receiving email in Gmail after migration?

This usually indicates old MX records are still active, DNS propagation is incomplete, or coexistence routing has not been fully removed.

Summary: The Importance of DNS Planning in Your Migration

A successful Google Workspace to Microsoft 365 migration service isn’t just about moving mailboxes—it’s about the careful orchestration of DNS records that control how email flows before, during, and after the transition. Every MX change, SPF update, DKIM configuration, and Autodiscover redirect must be planned, validated, and executed in the right sequence.

The organizations that experience zero email disruption during migration are the ones that:

Lower TTLs well before cutover
Publish and validate DKIM before switching MX
Maintain coexistence routing during the propagation window
Run post-cutover DNS validation checklists within the first 24 hours
Monitor DMARC reports continuously in the weeks following migration

For organizations with complex environments, multi-domain tenants, or hybrid mail flow requirements, working with experienced Microsoft 365 migration specialists can mean the difference between a seamless transition and a week of troubleshooting email outages.