Email Provider Migration: The Correct MX Record Sequence to Avoid Losing Email
Switching email providers is one of the most common causes of lost email. Here's the correct migration sequence (never update MX first), how Google Workspace, Microsoft 365, and Zoho Mail configure their MX records, and how to verify after migration.
By sadiqbd Β· June 10, 2026
Switching email providers is one of the most common causes of lost email β and most of it is preventable
Google Workspace, Microsoft 365, Zoho Mail, Fastmail β migrating corporate email between providers involves a sequence of DNS changes that must happen in the right order. Getting the order wrong, or forgetting to update any one record, causes incoming email to go missing, sometimes permanently, while the problem is diagnosed.
How the major providers configure MX records
Google Workspace
Google Workspace requires five MX records with specific priorities:
yourdomain.com. IN MX 1 ASPMX.L.GOOGLE.COM.
yourdomain.com. IN MX 5 ALT1.ASPMX.L.GOOGLE.COM.
yourdomain.com. IN MX 5 ALT2.ASPMX.L.GOOGLE.COM.
yourdomain.com. IN MX 10 ALT3.ASPMX.L.GOOGLE.COM.
yourdomain.com. IN MX 10 ALT4.ASPMX.L.GOOGLE.COM.
Priority 1 is the primary; priorities 5 and 10 are backup servers. Google's infrastructure is globally distributed β these records route incoming mail to the nearest available Google data centre.
Verification step: after updating DNS, use the Google Admin console's DNS verification tool, or perform an MX lookup from sadiqbd.com to confirm all five records are present.
Microsoft 365
Microsoft 365 uses a single MX record with a tenant-specific hostname:
yourdomain.com. IN MX 0 yourdomain-com.mail.protection.outlook.com.
The hostname is based on your domain with dots converted to hyphens, plus .mail.protection.outlook.com. You can find the exact hostname in the Microsoft 365 admin centre under DNS settings.
A common mistake: copy-pasting the MX record from Microsoft's documentation with a placeholder domain. The actual hostname must match your specific domain.
Zoho Mail
yourdomain.com. IN MX 10 mx.zoho.com.
yourdomain.com. IN MX 20 mx2.zoho.com.
yourdomain.com. IN MX 50 mx3.zoho.com.
Zoho requires additional TXT records for SPF and DKIM. The admin portal provides specific records during setup.
Fastmail
yourdomain.com. IN MX 10 in1-smtp.messagingengine.com.
yourdomain.com. IN MX 20 in2-smtp.messagingengine.com.
The correct migration sequence to avoid lost email
The wrong order: update MX records first, then set up the new provider. This causes a window where email is being delivered to the new provider's servers before mailboxes are configured β email is rejected or bounced.
The correct order:
- Set up mailboxes at the new provider β create all user accounts, distribution lists, aliases
- Configure authentication at the new provider β DKIM selector published in DNS, SPF updated to include new provider
- Verify the new provider is receiving β send a test email directly to the new provider's inbound infrastructure (some providers allow this via a direct connection)
- Lower TTL on existing MX records β change from 3600 to 300 seconds, wait for current TTL to expire
- Update MX records β switch to new provider's records
- Monitor β check both old and new provider's delivery logs for 24β48 hours
- Remove old provider's MX records β after confident the new records are propagated and working
- Remove old provider from SPF β after removing their MX records (they may still need to be in SPF temporarily if any mail still routes through them)
- Disable old mailboxes β after the migration window, not before
Dual MX records during migration (split delivery)
For large organisations migrating gradually, dual MX records with different priorities allow split delivery:
# New provider: priority 5 (preferred)
yourdomain.com. IN MX 5 mail.newprovider.com.
# Old provider: priority 20 (fallback only)
yourdomain.com. IN MX 20 mail.oldprovider.com.
Mail will attempt delivery to the new provider first; only fall back to the old provider if the primary is unavailable. This is a transitional state β not a permanent dual-delivery setup.
The null MX for domains that don't receive email
For domains used only for outbound (websites, API services) that should not receive email, the null MX prevents spam delivery attempts and produces clean bounces:
yourdomain.com. IN MX 0 .
The period as the exchange value signals "no mail accepted here." Senders receive an immediate authoritative negative response rather than repeatedly trying to connect to non-existent mail servers.
Verifying after migration
Immediate checks:
- MX lookup confirms new records are in place
- Send test email from an external account (Gmail, Outlook) and verify delivery
- Send test email from your own domain and verify outbound works
- Check DMARC alignment β new provider's DKIM should be signing with your domain
First-week monitoring:
- Old provider's delivery logs β any email still routing to old servers?
- New provider's delivery logs β all expected senders reaching the new server?
- Bounce reports β any unexpected NDRs?
How to use the MX Lookup on sadiqbd.com
- Enter your domain
- Verify the records match your provider's requirements β priority values and hostname format
- Check during migration β confirms propagation is complete
- Use post-migration β periodic verification that records haven't changed unexpectedly
Frequently Asked Questions
How long does an MX record change take to propagate? MX records propagate based on the TTL of the previous record. At TTL 300 (5 minutes), most changes propagate within 10β15 minutes. At TTL 3600 (1 hour), the change propagates within 1β2 hours for most resolvers.
Should I have backup MX records? For Google Workspace and similar enterprise providers, backup MX records are already built into the provider's primary record set. For self-hosted mail servers, backup MX records pointing to a secondary server provide resilience if the primary is temporarily unavailable.
Is the MX Lookup free? Yes β completely free, no sign-up required.
Email migration failures are almost always preventable with the right sequence. The MX records are the final step, not the first β setting up the new provider completely before touching MX records ensures continuity throughout the transition.
Try the MX Lookup free at sadiqbd.com β verify MX records for any domain, with priority values and target hostname resolution.