DNS Changes After Office 365 Migration
Getting your mailboxes into Microsoft 365 is a big milestone — but it's not the finish line. Once the data is there, you still need to update your DNS records so that email actually starts flowing to the new environment, Outlook connects without issues, mobile devices sync properly, and your security settings reflect the change.
It doesn't matter whether you migrated from Exchange Server, Google Workspace, a hosted IMAP setup, or another Microsoft 365 tenant — the DNS cutover is what makes everything click into place for real users.
EdbMails Office 365 Migration handles the heavy lifting on the mailbox side — migrating emails, shared mailboxes, archives, public folders, and permissions with minimal downtime. But once that's done, updating your DNS is what seals the deal and redirects live traffic to Microsoft 365.
This guide walks through every DNS record you'll need to update, explains why each one matters, and covers how to time the cutover, what mistakes to watch out for, and how to keep mail flowing smoothly throughout the transition.
Why DNS Changes Matter After Office 365 Migration
Migrating a mailbox means copying the data. But users won't actually start using their new Microsoft 365 mailboxes until your DNS records tell the rest of the internet — and your own internal systems — to look there instead of the old server.
Skip this step (or do it wrong), and you'll run into problems like:
- Incoming email still landing on the old mail server
- Outlook constantly asking users to re-enter their passwords
- Mobile devices that won't sync
- Messages getting flagged as spam because SPF or DKIM hasn't been updated
- Delivery failures caused by a stale MX record
- Autodiscover still pointing Outlook at the old Exchange environment
- Messy coexistence issues if you're doing a phased migration
Getting DNS right is what makes the migration feel invisible to end users.
Understanding the DNS Records Microsoft 365 Relies On
DNS is the system that maps your domain to the actual services behind it. During an Office 365 migration, several records either need to be created fresh or updated to point at Microsoft 365.
Here's a quick overview of what each one does:
| DNS Record | What It Does |
| MX | Sends incoming email to Microsoft 365 |
| Autodiscover CNAME | Lets Outlook set itself up automatically |
| SPF TXT | Confirms Microsoft 365 is authorized to send mail for your domain |
| DKIM | Digitally signs outgoing messages to prove they're legitimate |
| DMARC | Protects your domain from spoofing and phishing attempts |
| CNAME Records | Support Microsoft services like Teams and Intune |
| TXT Verification | Proves domain ownership to Microsoft 365 |
Just updating the MX record isn't enough. A complete migration requires all of these to be in order.
When Should You Actually Change Your DNS Records?
The right timing depends on how you're approaching the migration.
Cutover Migration — DNS changes happen after all mailboxes have been moved and users are ready to switch over immediately.
Staged Migration — DNS is typically updated after the final batch of mailboxes has been migrated, to avoid a situation where mail is being delivered to two different environments at the same time.
Hybrid Migration — Some records stay the same during the coexistence period. Others get updated gradually, depending on where each mailbox lives at any given point.
Tenant-to-Tenant Migration — DNS cutover usually happens after you've verified the migrated mailboxes are working and before you redirect live mail flow to the destination tenant.
Planning this carefully saves a lot of headaches.
Getting Ready for the DNS Cutover
Before you touch a single DNS record, make sure the migration itself is actually done and working properly.
A solid pre-cutover checklist looks like this:
- Confirm migrated mailbox item counts look right
- Test access through Outlook on the web
- Verify shared mailboxes are accessible
- Check that calendars and contacts came through correctly
- Run one final incremental sync in EdbMails to catch anything recent
- Document your current DNS settings so you can roll back if needed
- Lower your DNS Time-To-Live (TTL) values 24–48 hours before the planned cutover
That last point is worth emphasizing. Lowering TTL ahead of time means that when you do make changes, they propagate faster — reducing the window where some users are on the old system and some are on the new one.
Understanding DNS Propagation (and Why It Takes Time)
Changing a DNS record doesn't flip a switch worldwide. Every DNS resolver out there caches records based on their TTL setting. Until that cache expires, some systems will still be looking at the old record.
Here's a rough timeline to keep in mind:
- Internal DNS: Usually updates within minutes
- Public DNS providers (Google, Cloudflare, etc.): Anywhere from 15 minutes to a few hours
- Full global propagation: Can take up to 48 hours
During this window, some messages may still arrive at your old mail server. This is completely normal — but it means you should not shut down the source environment the moment you flip the DNS switch. Keep both systems running until propagation has fully completed, or you risk losing mail in transit.
Updating the MX Record
The MX (Mail Exchange) record is the one that tells other mail servers where to deliver email for your domain. This is the most critical DNS change in the entire migration.
After cutover, it needs to point to Microsoft 365 — something like:
yourdomain-com.mail.protection.outlook.com
Why This Change Can't Wait
If your MX record still points at the old server after migration:
- External senders will keep delivering to the old environment
- Newly migrated users won't receive incoming messages
- You end up with split mail delivery, which is confusing and hard to untangle
- Users may think the migration failed, even though their mailboxes migrated perfectly fine
Getting this record right is what makes the switchover real for everyone sending you email.
Before You Update the MX Record
Take a moment and check these things first:
- All mailbox migrations are complete (or at least all for this batch)
- Every migrated user has a Microsoft 365 license assigned
- Users can log into Outlook on the web successfully
- Mailbox permissions look correct in the new environment
- You've communicated the migration window to affected users
- The old mail server is still running and will stay up through propagation
Verifying the New MX Record
Once you've made the change, don't just assume it worked. Verify it:
- Confirm Microsoft 365 shows up as the active mail destination
- Make sure no old MX records are lingering with an equal or higher priority
- Check that priority values are set correctly (lower number = higher priority)
- Send a test email from an external account and confirm it arrives in Microsoft 365
- Monitor the old server to see when mail stops arriving there
Common MX Record Mistakes
These are the ones that catch people off guard:
- Having multiple MX records with the same priority (causes unpredictable routing)
- Setting the wrong priority value
- A typo in the Microsoft 365 endpoint
- Forgetting to delete the old mail server's MX entry
- Updating the MX record before the mailbox migration is actually done
- Shutting down the source server before propagation has finished
Most post-migration support tickets trace back to one of these. A little double-checking goes a long way.
