How to cut over email DNS without losing mail
Every email migration ends with the same DNS changes. This runbook puts them in a safe order, with TTL planning, record-by-record checks and the rules that stop mail bouncing or landing in junk.
Your migration plan
This is the DNS (the internet's address book for your domain) part of any email provider change, including the domain step of a Microsoft 365 tenant-to-tenant move. You lower TTLs (how long other servers cache a record), add the new provider's records alongside the old ones, switch the MX record (the setting that tells the internet where to deliver your email) once the new mailboxes are ready, then tighten the sender checks: SPF, DKIM and DMARC. Plan for a day of lead time before the switch and at least 72 hours of overlap after it, because Microsoft allows up to 72 hours for other mail systems to see a new MX.
Users find their mail history on day one, and the old service keeps syncing, so mail from senders still using the old MX is not lost.
Other options and when to use them
- Staged coexistence with routing subdomains: You are moving from Google Workspace to Microsoft 365 in batches over days or weeks.
- Switch MX first, copy history afterwards: A very small office wants a clean break and can live without old mail for a short time.
Change the records that do not move mail first, switch MX only when every mailbox is ready, and tighten sender checks last. In that order mail is never delivered to a mailbox that does not exist, and never rejected for failing a check you have not finished setting up.
- DNS host access and a saved copy of every recordYou cannot change anything without access, and the saved copy is your rollback point.
- DMARC in monitoring mode, and a list of every system that sends as your domainA week of reports shows every sender before you tighten anything.
- Lower TTLsOther servers only pick up the shorter time after the old one runs out, so this must happen a day or more ahead.
- Verification, SPF and DKIM records for the new providerNone of these changes where mail goes, so they can be done days early.
- Switch MXNew mail goes to the new service from this moment, so every mailbox must exist first.
- Autodiscover, internal DNS and old client recordsOutlook finds the new mailbox once these point at it.
- DKIM signing on, old provider out of SPF, DMARC towards enforcementTightening before every sender passes sends real mail to junk.
- Old service closed after a quiet 72 hoursSome senders keep using the old MX they cached for up to 72 hours.
Built-in and third-party tools treat these differently. Tick each one off once you have decided.
Download this checklist (Excel)How each tool handles it
Built-in methodDNS sits wherever your nameservers (NS records) point: often the registrar, Cloudflare, the web host or the old email provider, not where the domain was bought. Your mail provider cannot change it for you without that access.Tip: If DNS sits with the email host you are leaving, move DNS first as its own change.
Amazon Route 53: Why new DNS settings are not in effectHow each tool handles it
Built-in methodSome DNS hosts offer a zone export; others need screenshots and lookups of every MX, TXT, CNAME and SRV record.Tip: Record every value with its TTL in the DNS cutover record sheet. It is your rollback point.
How each tool handles it
Built-in methodMicrosoft recommends an MX TTL of 3,600 seconds (one hour) or less before you start. Lowering it on the day does not help servers that already cached the old, longer value.Tip: Read the current TTL from your nameserver and lower it at least that long before the switch. Raise TTLs again once stable.
Amazon Route 53: Migrating DNS service for a domain that is in useHow each tool handles it
Built-in methodMicrosoft 365 verifies a domain with an MS=ms TXT record, which does not affect mail. Choosing "I'll add the DNS records myself" stops Microsoft 365 changing MX for you.Tip: Add and verify the domain days before the switch.
Microsoft Learn: Add a domain to Microsoft 365How each tool handles it
Built-in methodSPF (the list of services allowed to send as your domain) allows one record per domain. A second record, or more than 10 DNS lookups in one, makes SPF fail for every message.SPF Surveyor (dmarcian)Free web tool that expands each part of the record, counts the lookups and warns when you pass 10.Tip: Remove includes for services you no longer use, and move bulk senders to a subdomain with its own SPF.
Microsoft Learn: Set up SPFHow each tool handles it
Built-in methodDKIM keys (signatures that prove mail is really from you) are published under named selectors, so old and new keys can sit side by side. Microsoft 365 uses two CNAME records, selector1._domainkey and selector2._domainkey.Tip: Publish both CNAMEs days ahead, and turn signing on as soon as the first mailbox sends from the new service.
Microsoft Learn: Set up DKIMHow each tool handles it
Built-in methodDMARC (your policy telling receivers how to treat mail that fails checks) should start at p=none with a report address. Microsoft suggests moving to p=quarantine in steps, then p=reject once reports show every legitimate sender passes.parsedmarcOpen source parser that turns DMARC reports into tables or dashboards of sending servers with their SPF and DKIM results.Tip: Stay at p=none until the old service is closed and reports are clean.
Microsoft Learn: Set up DMARCHow each tool handles it
Built-in methodYour mail provider does not handle these. Each system must be listed in SPF or sign its mail with its own DKIM, or a stricter policy sends its mail to junk or rejects it.parsedmarcOpen source parser that turns DMARC reports into tables or dashboards of sending servers with their SPF and DKIM results.Tip: Read a week of DMARC reports before the switch to find senders nobody mentioned.
Microsoft Learn: Set up DMARCHow each tool handles it
Built-in methodMicrosoft says to add users and mailboxes before changing MX. From the moment MX changes, new mail goes to the new service.Tip: Check every address in your inventory has a licensed mailbox, shared mailbox or alias at the new provider.
How each tool handles it
Built-in methodMicrosoft allows up to 72 hours for other mail systems to see a new MX, so some mail still reaches the old service.Tip: Keep the old service syncing until it has received nothing new for a few days, and check its billing renewal date first.
Microsoft Learn: Migrate other types of IMAP mailboxesHow each tool handles it
Built-in methodFor Microsoft 365, Outlook finds the mailbox through a CNAME named autodiscover pointing to autodiscover.outlook.com. Delete any old autodiscover record first.Tip: Remove old webmail, IMAP and autoconfig records once users have moved, and note each removal.
How each tool handles it
Built-in methodInternal DNS, often on domain controllers, is a second copy of the zone. Public changes do not touch it, so domain-joined PCs can keep finding the old server.Tip: Look in DNS Manager for a zone named after your public domain, and update MX and Autodiscover there too.
How each tool handles it
Built-in methodIf MX points at a third-party filter, Microsoft 365 sees the filter as the sender, so SPF and DMARC checks judge the wrong server and DMARC reports are not sent. Microsoft recommends Enhanced Filtering for Connectors.Tip: Decide before the switch, and if you keep the filter, configure Enhanced Filtering on the inbound connector.
Microsoft Learn: Set up DMARC
- 1
Get ready
One week beforeWatch out: DNS is often held by the web developer, a reseller or the old email host, and finding out on the night stops the project.
Ways around it
- If DNS sits with the email host you are leaving, move DNS first as a separate change.
Watch out: Senders missing from SPF or DKIM have their mail junked or rejected, and DMARC reports are slow to read by hand.
Ways around it
- Read a week of DMARC reports to find every sender, then add each one to SPF or turn on DKIM in that service.
Tools that can do it
- parsedmarcOpen source parser that turns DMARC reports into tables or dashboards of senders and their results.
Check your DNS records before and after the change
Show the detailed steps (3) → - 2
Lower TTLs
At least a day beforeShow the detailed steps (3) →Watch out: Lowering the TTL on the day does nothing for servers that already cached the old, longer value.
Ways around it
- Read the current TTL from your nameserver and lower it at least that long before you switch.
- 3
Pre-stage records
Days before the switchShow the detailed steps (4) →Watch out: A second SPF record, or more than 10 DNS lookups in one, makes SPF fail for every message.
Ways around it
- Keep a single SPF record, remove includes for services you no longer use, and move bulk senders to a subdomain.
Tools that can do it
- SPF Surveyor (dmarcian)Free web tool that counts your SPF lookups and warns when you pass 10.
- 4
Switch MX
Once every mailbox is readyWatch out: Microsoft allows up to 72 hours for other mail systems to see a new MX, so some mail still reaches the old service.
Ways around it
- Keep the old service and its sync running for at least 72 hours, and check its billing renewal date first.
Watch out: If a filtering service sits in front of Microsoft 365, sender checks judge the filter, not the real sender.
Ways around it
- Decide before the switch whether to keep the filter, and if so configure Enhanced Filtering for Connectors.
Turn this phase into dated tasks with the cutover planner
Show the detailed steps (4) → - 5
Update Autodiscover
Show the detailed steps (3) →Watch out: With internal DNS, domain-joined PCs can keep finding the old server even when public DNS is right.
Ways around it
- Check DNS Manager for a zone named after your public domain, and update MX and Autodiscover there too.
- 6
Tighten sender checks
Once mail flows through the new serviceShow the detailed steps (3) →Watch out: DMARC at reject with the old provider gone from SPF makes switching back hard.
Ways around it
- Stay at p=none until the old service is closed and reports are clean.
- 7
Check and close
A few days after the 72-hour windowShow the detailed steps (3) →Watch out: Closing the old service is the point of no return, and changing MX back does not move mail already delivered to the new one.
Ways around it
- Keep your record sheet so any record can be restored, and close the old service only after final checks.
- Public resolvers return only the new MX, and the new provider's health check shows no errors.
- Test mail from several outside providers arrives at the new service and none at the old one.
- Outgoing mail and every other sending system pass SPF, DKIM and DMARC, with one SPF record under 10 lookups.
- Outlook finds the new mailbox through Autodiscover inside and outside the network.
Tools named in this plan are independent third-party products, not endorsed by the platform vendor and not paid placements. Check the tool's own documentation and run a pilot first.
Detailed steps
Open a part when you reach it in the plan. Each step says where to go, what to do and what you should see.
About this migrationWhat it covers, limits at a glance
Mail is delivered to whatever server your MX record names. If you change MX before the new mailboxes exist, or turn off the old service before every sender has picked up the new record, mail is lost or bounced. Change SPF, DKIM or DMARC in the wrong order and mail is delivered but lands in junk.
This runbook works for any provider change. Examples use Microsoft 365, a common target for small businesses. The mailbox copy itself is covered in the IMAP, Google Workspace and Exchange guides.
1What you need before step one
| Need | Details | Where to get it |
|---|---|---|
| DNS host sign-in | An account that can edit records at whoever hosts the zone (registrar, Cloudflare, web host or IT provider). | Find the host with the NS lookup in Step 1 |
| New provider admin access | Microsoft 365 Global Administrator or Domain Name Administrator to read the domain's DNS records page. | Microsoft 365 admin center, https://admin.microsoft.com |
| Mailboxes ready | Every mailbox created and licensed at the new provider, with the mail copy running. | Your mailbox migration guide |
| DNS lookup tools | nslookup is built into Windows; dig on macOS and Linux. | Included with the operating system, or BIND tools from https://www.isc.org/download/ |
| Exchange Online PowerShell (optional) | For the DKIM commands. | Install the module and connect |
| Record sheet | A place to save every record before and after. | DNS cutover record sheet template |
2Record every current DNS record3 steps
- 1
Find out who hosts your DNS
Where: Command Prompt on Windows (or Terminal on macOS or Linux) on your admin PCDNS is often hosted somewhere other than email or the website: the registrar, Cloudflare, the web host or an IT provider. Look up the nameservers; the domain in the answer (for example a name ending in cloudflare.com) tells you which company to sign in to. Find the account and confirm you can edit records.
nslookup -type=ns contoso.com dig NS contoso.com +shortYou should see: Two or more nameserver names, and you can sign in to that provider and open the domain's DNS records page. - 2
Export or screenshot the zone
Where: Your DNS host's control panel > your domain > DNS records (export or zone file option if offered), plus Command Prompt on Windows (or Terminal on macOS or Linux) on your admin PCRecord MX, all TXT records, any CNAMEs for autodiscover, selector._domainkey and _dmarc, and SRV records. Use the host's zone export if it has one; otherwise screenshot the list and run the lookups below. Save everything in your DNS cutover record sheet. This is your rollback point.
nslookup -type=mx contoso.com nslookup -type=txt contoso.com nslookup -type=txt _dmarc.contoso.com nslookup -type=cname autodiscover.contoso.comYou should see: The record sheet lists every record with type, name, value, priority and TTL. - 3
List everything that sends as your domain
Where: Your Network and DNS worksheet, filled in with the owners of each systemWebsites, CRMs, invoicing systems, newsletters, scanners and helpdesks often send email as your domain. Each needs to stay in SPF or have its own DKIM. Ask each system owner and compare with the includes in your current SPF record.
You should see: Every sending service is listed with the SPF include or DKIM setting it needs.
3Lower TTLs before the change3 steps
- 1
Lower the MX TTL
Where: Your DNS host's control panel > your domain > DNS records > MX record > EditMicrosoft recommends setting the MX TTL to 3,600 seconds (one hour) or less before you start the migration, on every MX record. Do it at least one current TTL period before cutover, so resolvers have dropped the old long value. Full steps: lower DNS TTL before a migration.
nslookup -debug -type=mx contoso.com 8.8.8.8 dig @8.8.8.8 contoso.com MX +noall +answerYou should see: The TTL returned is 3600 or lower. - 2
Lower the other records you will change
Where: Your DNS host's control panel > your domain > DNS records > Edit (SPF TXT, autodiscover CNAME and other CNAMEs)Do the same for SPF, Autodiscover and any CNAMEs you plan to edit. Do not change their values yet.
You should see: Each record you will change shows the shorter TTL in the record list. - 3
Raise TTLs again afterwards
Where: Your DNS host's control panel > your domain > DNS records > Edit (same records)Once the new records are stable, set TTLs back to normal values, such as your host's default or the values in your record sheet. Put a reminder in the runsheet.
You should see: Lookups return the new values with the normal TTL.
4Pre-stage records that do not move mail4 steps
Several records can be published days before cutover because they do not change where mail is delivered.
- 1
Verify the domain with the new provider
Where: Microsoft 365 admin center (admin.microsoft.com) > Show all > Settings > Domains > Add domain, then Your DNS host's control panel > your domain > DNS recordsAdd the provider's verification TXT record. For Microsoft 365 this looks like
MS=msXXXXXXXX. It does not affect mail. Follow add a domain to Microsoft 365 and choose I'll add the DNS records myself so MX is not changed for you.You should see: The domain shows as verified in the new provider while MX still points to the old service. - 2
Add the new provider to SPF
Where: Your DNS host's control panel > your domain > DNS records > the TXT record starting v=spf1 > EditEdit your single SPF record to include both old and new senders during the overlap. Never publish a second SPF record: Microsoft notes multiple SPF records cause a permanent SPF error. See set up an SPF record.
v=spf1 include:spf.protection.outlook.com include:old-provider.example -allYou should see: nslookup -type=txt contoso.com 8.8.8.8 returns exactly one v=spf1 line containing both includes. - 3
Publish DKIM CNAMEs for the new provider
Where: PowerShell on your admin PC, connected with Connect-ExchangeOnline (or Microsoft Defender portal > Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM), then Your DNS host's control panel > your domain > DNS recordsDKIM selectors are named, so new and old keys can sit side by side. For Microsoft 365, create the signing config, then add two CNAME records named
selector1._domainkeyandselector2._domainkeypointing to the values it reports. Enable signing after cutover. Full steps: set up DKIM.New-DkimSigningConfig -DomainName contoso.com -Enabled $false Get-DkimSigningConfig -Identity contoso.com | Format-List Selector1CNAME,Selector2CNAMEYou should see: nslookup -type=cname selector1._domainkey.contoso.com returns the Selector1CNAME value. - 4
Check DMARC reporting
Where: Your DNS host's control panel > your domain > DNS records > Add record (TXT, name _dmarc)If you have no DMARC record, publish one in monitoring mode now so you can see failures during the move. See set up DMARC.
_dmarc.contoso.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@contoso.com"You should see: nslookup -type=txt _dmarc.contoso.com returns the v=DMARC1 value, and reports start arriving within a day or so.
5Switch MX4 steps
- 1
Confirm mailboxes exist and are licensed
Where: Microsoft 365 admin center > Users > Active users (Licenses column)Microsoft's DNS guidance is clear: add users and mailboxes before changing MX. Once MX changes, new mail goes to the new service. Check every address in your inventory has a licensed user, shared mailbox or alias. See assign licences.
You should see: Every address in your inventory resolves to a mailbox in the new service. - 2
Replace the MX records
Where: Microsoft 365 admin center > Settings > Domains > your domain > DNS records tab (copy the value), then Your DNS host's control panel > your domain > DNS recordsCopy the exact MX value from the new provider (for Microsoft 365, the Points to address or value in the Microsoft Exchange section, such as
contoso-com.mail.protection.outlook.com). Add it with priority 1, then remove the old provider's MX records, or give them a lower priority (higher number) than the new one. Full steps: change MX records.You should see: The DNS host lists only the new MX record (or the old ones at a higher number). - 3
Keep syncing the old mailbox
Where: Your migration batch (Exchange admin center > Migration) or sync toolSome senders keep using the old MX until their cache expires. Keep the migration batch or sync tool running so anything that lands on the old service is copied. Microsoft says to allow at least 72 hours.
You should see: The batch keeps showing successful incremental syncs after the MX change. - 4
Check propagation
Where: Command Prompt on Windows (or Terminal on macOS or Linux) on your admin PC, and https://toolbox.googleapps.com/apps/dig/Query public resolvers and your provider's own tools, such as Microsoft 365 admin center > Settings > Domains > your domain > Check health. Send test messages from several external providers. More checks: check DNS propagation.
nslookup -type=mx contoso.com 8.8.8.8 nslookup -type=mx contoso.com 1.1.1.1You should see: Both resolvers return only the new MX value, and test messages arrive in the new mailboxes.
6Update Autodiscover and client records3 steps
- 1
Point Autodiscover at Microsoft 365
Where: Your DNS host's control panel > your domain > DNS records > Add record (CNAME)Create a CNAME with the alias
autodiscoverpointing toautodiscover.outlook.com. Outlook uses it to find the new mailbox. Delete any old autodiscover A or CNAME record first.autodiscover.contoso.com CNAME autodiscover.outlook.comYou should see: nslookup -type=cname autodiscover.contoso.com returns autodiscover.outlook.com. - 2
Check internal DNS too
Where: DNS Manager (dnsmgmt.msc) on a domain controller, if you run internal DNSIf you run your own internal DNS or still have Exchange Server, the record must point to Microsoft 365 internally as well, or domain-joined PCs keep finding the old server. Look for a forward lookup zone named after your public domain.
You should see: nslookup autodiscover.contoso.com run on a domain-joined PC returns autodiscover.outlook.com. - 3
Remove old client records
Where: Your DNS host's control panel > your domain > DNS recordsRemove SRV or CNAME records for the old provider's webmail, IMAP or autoconfig names once users are moved. Note each removal in the record sheet.
You should see: Only records for services you still use remain.
7Turn on DKIM and tighten SPF and DMARC3 steps
- 1
Enable DKIM signing
Where: PowerShell connected with Connect-ExchangeOnline, or Defender portal > Email authentication settings > DKIM > your domainOnce mail is flowing through Microsoft 365, enable signing (in the portal, turn on Sign messages for this domain with DKIM signatures). If the CNAMEs are not found, the command returns the values to publish.
Set-DkimSigningConfig -Identity contoso.com -Enabled $trueYou should see: The status shows Signing DKIM signatures for this domain, and test message headers show dkim=pass. - 2
Remove the old provider from SPF
Where: Your DNS host's control panel > your domain > DNS records > the v=spf1 TXT record > EditAfter the overlap, remove the old include so you stay within the lookup limit. Microsoft recommends
-allfor Microsoft 365 domains that also use DKIM and DMARC.v=spf1 include:spf.protection.outlook.com -allYou should see: nslookup -type=txt contoso.com returns one SPF record without the old include. - 3
Move DMARC towards enforcement
Where: Your DNS host's control panel > your domain > DNS records > _dmarc TXT record > EditMicrosoft suggests starting at
p=none, moving top=quarantinewith increasingpct=values, thenp=rejectonce reports show legitimate senders pass.v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@contoso.comYou should see: Reports show no legitimate mail failing at each step before you raise it.
8Verify and close the old service3 steps
- 1
Check headers on test mail
Where: Gmail and Outlook.com test mailboxes in a browserSend to Gmail and Outlook.com accounts. In Gmail open the message, select More next to Reply and choose Show original. Check the headers show SPF, DKIM and DMARC pass for your domain.
You should see: Authentication-Results shows spf=pass, dkim=pass and dmarc=pass. - 2
Check the old service is quiet
Where: The old provider's webmail or admin consoleConfirm no new mail is arriving at the old provider before you stop syncing or cancel it. Check again a few days after the 72-hour window.
You should see: No new messages have arrived in the old mailboxes since the MX change settled. - 3
Record the final state
Where: Your DNS cutover record sheetSave the new zone in your DNS record sheet with dates, so the next change starts from an accurate list.
You should see: The sheet shows every record's final value, TTL and the date it changed.
Expert notes
The detail behind the plan: options compared, and what experienced engineers check first. Tap any item.
Compare all the ways to do this3 options
Copy first, then switch MX
Medium effortBest for: Most provider changes: mailboxes are copied and kept in sync, then MX moves in one change window
- Users find their mail history in place on day one
- The old service keeps syncing, so mail from senders with a cached MX is not lost
- SPF, DKIM and verification records can be pre-staged days ahead
- Both services run side by side for at least 72 hours after the change
- Needs a migration tool that keeps syncing until cutover
Staged coexistence with routing subdomains
High effortBest for: Larger moves from Google Workspace to Microsoft 365 where users move in batches over days or weeks
- Each side forwards mail to the other, so mixed groups of users can work during the move
- MX changes once, after the last batch
- More DNS and mail-flow set-up on both platforms
- Forwarding rules must be allowed and tested in both directions
Switch MX first, copy history afterwards
Low effortBest for: Very small offices that want a clean break and can live without old mail for a short time
- A single short change window
- No long period of two systems receiving mail
- Users see empty or partial mailboxes until the history is copied
- Every mailbox must exist and be licensed before MX changes, as Microsoft's DNS guidance requires
- Mail still landing at the old host must be collected separately
Use copy first, then switch MX unless you have a reason not to: it is the pattern this runbook follows and the one least likely to lose mail. Use routed coexistence only when users must move in batches. Whichever you choose, lower TTLs a day ahead, and if DNS is hosted by the email provider you are leaving, move DNS as a separate change first (change nameservers).
Lower TTL a full day ahead, not on the daySaves time
Resolvers keep the old answer until the old TTL runs out. Lowering the TTL at the same moment as the change does nothing for resolvers that already cached the long value; many zones use a day.
Read the current TTL from your authoritative nameserver (dig @ns1.yourhost contoso.com MX +noall +answer), lower it at least that long before cutover, and only then schedule the change.
Find every service that sends as your domain before touching SPFReduces risk
Invoicing, CRM, newsletter and website contact forms often send as your domain. If they are missing from SPF and not DKIM-signed, a stricter SPF or DMARC policy sends their mail to junk or rejects it.
Publish DMARC at p=none with an rua address a week before the cutover and read the reports to see every sender. Add each legitimate sender to your single SPF record or turn on DKIM in that service.
DMARC aggregate reports arrive as compressed XML files from each receiving provider and are slow to read by hand. A report parser turns them into tables or dashboards of sending IP addresses with their SPF and DKIM results, so unknown senders stand out.
- parsedmarcOpen source parser that reads rua reports from a mailbox over IMAP, Microsoft Graph or the Gmail API and outputs JSON or CSV, or feeds premade Kibana and Grafana dashboards.
Count SPF lookups after adding the new providerReduces risk
During the overlap your SPF record carries both providers. Each include can contain further includes, and more than 10 DNS lookups makes SPF fail with a permanent error for every message.
Before you publish the overlap record, expand each include (for example nslookup -type=txt spf.protection.outlook.com) and count the lookups. Remove includes for services you no longer use, and move bulk senders to a subdomain with its own SPF.
Counting lookups with nslookup is slow and easy to get wrong when includes are nested. SPF Surveyor expands each mechanism, shows the DNS queries each one needs, and warns when the record exceeds the 10-lookup limit.
- SPF Surveyor (dmarcian)Web tool in dmarcian's free DMARC tools. Enter the domain after you publish the overlap record to see the lookup count.
Publish the new DKIM selectors days before cutoverReduces risk
DKIM selectors are named, so the new provider's keys can sit beside the old ones without conflict. Waiting until after MX changes leaves a gap where mail from the new system is unsigned.
Create the Microsoft 365 signing configuration disabled, publish both selector CNAMEs early, and turn signing on as soon as the first mailbox sends from Microsoft 365.
Keep the old service running for at least 72 hoursReduces risk
Some sending servers keep using the cached MX record, and Microsoft allows up to 72 hours for other systems to see the change. Cancelling the old hosting too soon loses that mail.
Keep the migration batch or sync tool running after the MX change, and only cancel the old service once its mailboxes have received nothing new for a few days. Check its billing renewal date so you are not forced to cut early.
Know who controls DNS before the change windowSaves time
DNS is often hosted by the web developer, the old email host or a reseller, not where the domain was bought. Finding out on cutover night stops the project.
Look up the NS records and confirm you can sign in and edit records at that host a week before. If DNS sits with the old email host you are leaving, move DNS first as a separate change (change nameservers).
Do not forget internal DNS and split-brain zonesUser impact
Organisations that run their own internal DNS (often on domain controllers) have a second copy of the zone. Public DNS can be perfect while domain-joined PCs still find the old Autodiscover or mail server.
Check DNS Manager on a domain controller for a zone named after your public domain and update MX, Autodiscover and any mail CNAMEs there too.
If a filtering service sits in front, configure Enhanced FilteringReduces risk
When MX points to a third-party filter rather than Microsoft 365, Microsoft sees the filter as the sender. SPF and DMARC checks then judge the wrong server, and Microsoft says DMARC aggregate reports are not sent.
Decide before cutover whether you keep the filter. If you do, configure Enhanced Filtering for Connectors on the inbound connector so Microsoft 365 checks the real source.
Check it worked, or roll back
Full validation checklist8 checks
Run these before you declare the migration complete. Record the results in the data validation report.
| Check | How to check | What good looks like |
|---|---|---|
| Public resolvers return only the new MX | From your admin PC run | Every resolver returns only the new provider's MX record, matching the value in your DNS cutover record sheet. |
| The new provider reports DNS as healthy | For Microsoft 365, go to Microsoft 365 admin center > Settings > Domains > your domain and run Check health, then review the DNS records tab. | MX, Autodiscover and SPF show as correctly configured with no warnings. |
| Inbound mail arrives from several outside providers | Send test messages from Gmail, Outlook.com and at least one other outside mail system to a sample of mailboxes, shared addresses and aliases. | Every test message arrives at the new service, and none arrives at the old one. |
| SPF, DKIM and DMARC pass on outgoing mail | Send from the new service to Gmail and Outlook.com test mailboxes. In Gmail select More > Show original and read the authentication results. In Exchange Online PowerShell, run | SPF, DKIM and DMARC all show pass for your domain, and DKIM signing is enabled. |
| SPF is a single record within the lookup limit | Run | Exactly one SPF record, with no more than 10 DNS lookups, and the old provider removed once the overlap ends. |
| Every other system that sends as your domain still passes | Using the list in your Network and DNS worksheet, ask each system owner (website, CRM, invoicing, newsletters, scanners) to send a test message to an outside mailbox, and check the headers. Review your DMARC aggregate reports for failing sources. | Each listed system passes SPF or DKIM, and DMARC reports show no legitimate source failing. |
| Outlook finds the new mailbox through Autodiscover | Run | Autodiscover resolves to autodiscover.outlook.com inside and outside the network, and Outlook connects without asking for a server name. |
| The old service has gone quiet | Sign in to the old provider's webmail or admin console a few days after the 72-hour window and check the newest message dates. | No new mail has arrived at the old service since the MX change settled. |
Rollback planIf it goes wrong
Roll back if
- Outside senders report bounces, or test messages from outside providers do not arrive at the new service
- The new provider's domain health check shows MX or SPF errors you cannot fix in the change window
- SPF or DMARC failures cause legitimate outgoing mail to be rejected or sent to junk
- Mailboxes or aliases turn out to be missing at the new provider after MX has moved
Point of no return
DNS changes are reversible: you can put back any record from your DNS cutover record sheet. The point of no return is closing the old mail service, because once its mailboxes are deleted there is nowhere to send mail back to. A DMARC policy at p=reject with the old provider already removed from SPF also makes a quick switch back harder, as the old service's mail will fail. Mail delivered to the new provider during the cutover stays there; changing MX back does not move it.
- 1
Put the old MX records back
Where: Your DNS host's control panel > your domain > DNS recordsAdd the old MX records with the priorities saved in your DNS cutover record sheet, then remove the new provider's MX record. Keep the TTL short.
nslookup -type=mx contoso.com 8.8.8.8You should see: Public resolvers return the old MX records again. - 2
Restore SPF to cover the old provider
Where: Your DNS host's control panel > your domain > DNS records > the v=spf1 TXT record > EditEdit the single SPF record so it includes the old provider again. Keep the new provider in it if users may still send from there. Do not add a second SPF record.
You should see: One SPF record that includes the old provider, and test mail from the old service passes SPF. - 3
Relax DMARC if you tightened it
Where: Your DNS host's control panel > your domain > DNS records > _dmarc TXT record > EditIf you moved DMARC to quarantine or reject during the cutover, set it back to
p=noneuntil both services pass again.You should see: Mail from the old service is no longer quarantined or rejected by receivers. - 4
Point Autodiscover back
Where: Your DNS host's control panel, and DNS Manager on a domain controller if you run internal DNSRestore the old autodiscover or autoconfig records from the record sheet so clients find the old service.
You should see:nslookup -type=cname autodiscover.contoso.comreturns the old value. - 5
Keep or reverse the mailbox sync
Where: Your migration batch (Exchange admin center > Migration) or sync toolStop the migration batch or sync tool so it does not keep copying. Messages that arrived at the new provider during the window must be moved back by the migration tool, if it supports the reverse direction, or by hand in a mail client connected to both accounts.
You should see: Users have all mail from the cutover window in the old mailboxes.
Agree the triggers and who decides before the go / no-go meeting. Use the rollback plan template.
Common problems and fixes6 errors
SPF permerrorCause: Two SPF TXT records exist for the domain, or SPF needs more than 10 DNS lookups.
Fix: Merge into one SPF record and remove unused includes; move bulk senders to a subdomain with its own SPF.
Mail still arrives at the old provider after the MX changeCause: Senders have cached the old MX, or the old MX record was not removed.
Fix: Keep syncing for at least 72 hours, and check the old MX is gone or has a lower priority than the new one.
Outlook keeps connecting to the old mailboxCause: Autodiscover still points to the old server in public or internal DNS, or an Exchange SCP is still published.
Fix: Point autodiscover to autodiscover.outlook.com in all DNS zones and clear the Exchange SCP if Exchange is still running.
Set-DkimSigningConfig says the CNAME records do not existCause: The selector CNAMEs are missing, mistyped or not yet visible.
Fix: Publish the exact Selector1CNAME and Selector2CNAME values, wait, then run the command again.
Outbound mail lands in junk after cutoverCause: SPF does not include the new provider, DKIM is not enabled, or DMARC is at reject while SPF and DKIM fail.
Fix: Fix SPF and enable DKIM first; relax DMARC to p=none until both pass.
Website contact form stops sendingCause: The web server or app is not in the updated SPF record, or it relayed through the old provider.
Fix: Add the sending service to SPF, or send through an authenticated service with DKIM on a subdomain.
Frequently asked questions
How long does an MX change take?
It depends on the TTL that was cached. Microsoft says to allow up to 72 hours for other mail systems to recognise a changed MX, so keep the old service syncing for that long.
Will I lose email when I change provider?
Not if the new mailboxes exist before you change MX and the old mailboxes keep being synced until all senders have picked up the new record.
Can I have two SPF records during the move?
No. Only one SPF record is allowed per domain. Include both providers in a single record during the overlap.
Do I need to change DMARC when I move?
The DMARC record does not name a provider, so it usually stays. Check that SPF and DKIM will pass with the new provider before you enforce quarantine or reject.
What TTL should I use?
Microsoft recommends 3,600 seconds or less on MX before migrating. Lower it ahead of time and raise it again when the move is complete.
Official sources
9 official pages this guide is based on
Vendors change limits and features, so confirm details on the source before you rely on them. Last checked 4 Nov 2026.