DNS Changes After Office 365 Migration
Mailbox migration moves the selected data, but it does not change where the internet sends new mail. That depends on the domain's DNS records and, in some environments, an email security gateway or hybrid mail route. Check those settings before users start relying on their Microsoft 365 mailboxes.
This guide covers the records that commonly need attention after a move from Exchange Server, a hosted mail service, or another Microsoft 365 tenant. The right values depend on your domain, the services you use, and whether mail will go directly to Exchange Online or through another system.
If you used EdbMails Office 365 migration software to move supported mailbox data, review the migration reports and run any planned follow-up pass before changing live mail routing. DNS changes are made with your DNS provider and Microsoft 365, outside the migration job.
Why DNS changes matter after migration
A migrated mailbox can be accessible in Outlook on the web while new messages continue to reach the old system. MX controls inbound routing; Autodiscover helps supported Outlook clients find their settings; SPF, DKIM, and DMARC help receiving systems evaluate mail sent from your domain. These are separate checks, so a successful MX update does not confirm that client discovery or outgoing email authentication is correct.
- New mail may continue to arrive at the previous provider or gateway.
- Outlook may discover the old mailbox, especially if internal Autodiscover records or a cached profile remain.
- Legitimate outbound mail may fail authentication when an SPF record omits a sender or DKIM is not configured for the custom domain.
DNS records to review
Open Settings > Domains in the Microsoft 365 admin center, select the domain, and check its DNS records. Compare the values shown there with the records at the authoritative DNS host. You may already have some of these records; review them before adding or replacing anything.
| Record | What to review |
|---|---|
| MX | The intended inbound route. Use the domain-specific Microsoft 365 value when Exchange Online receives mail directly; a gateway or hybrid design may use another route. |
| Autodiscover CNAME | How supported Outlook clients find mailbox settings. A cloud-only configuration commonly uses autodiscover.outlook.com; check hybrid dependencies first. |
| SPF TXT | One SPF record for each sending domain or subdomain, covering Microsoft 365 and any other authorized senders. |
| DKIM CNAMEs | Two selector records for the custom domain, with the exact targets shown in Microsoft 365. Enable DKIM signing after the records are detected. |
| DMARC TXT | The policy and reporting record at _dmarc, reviewed alongside SPF and DKIM alignment. |
| Domain verification TXT | Needed when adding or transferring an unverified custom domain to a Microsoft 365 tenant; it is not a routine new record after every mailbox move. |
| Other CNAME or SRV records | Records for selected services such as Teams or Intune, if those services are part of the domain setup. |
When should you change the records?
Cutover migration usually moves inbound routing after destination mailboxes, user access, and the final data pass have been checked.
For a staged migration, follow the agreed coexistence or forwarding plan. The MX record applies to the domain, not to individual batches of users, so changing it for one batch can affect mail for everyone at that domain.
Hybrid migration needs a review of mail connectors, accepted domains, internal DNS, and client discovery. Do not change Autodiscover to Exchange Online solely because some mailboxes have moved; remaining on-premises services can depend on the existing configuration.
In a tenant-to-tenant migration, plan the custom-domain move as well as DNS. A custom domain cannot be attached to both tenants at once. Remove its source-tenant dependencies, verify it in the destination tenant, assign the intended addresses, and confirm routing as part of the cutover.
Prepare for the DNS cutover
- Confirm destination recipients and licenses are ready, then test sign-in and mailbox access through Outlook on the web.
- Review mailbox mapping and migration reports. If a repeat pass is planned in EdbMails, run it against the same source and target before the final switch and check its results.
- Record the current MX, Autodiscover, SPF, DKIM, and DMARC values, along with any gateway or connector settings.
- Identify every service that sends as your domain, including printers, applications, and marketing platforms, before editing SPF.
- Lower the existing MX record's TTL in advance when your DNS provider permits it. Allow its previous TTL to expire before the cutover if you need the new value to be cached for less time.
- Keep the previous mail route available during the transition and agree on who will verify inbound and outbound messages.
Update MX for the planned inbound route
When Exchange Online should receive mail directly, copy the MX target shown for your domain in the Microsoft 365 admin center and enter it at the DNS host. Avoid using a sample value copied from another tenant. If a third-party gateway remains in front of Microsoft 365, review its downstream routing and connectors; the public MX may stay pointed at the gateway.
Check the route before switching
Make sure the domain is configured in the destination tenant, the target recipients can accept mail, and any coexistence route is ready. Then check the MX priority values. Lower numbers have higher priority; two records at the same priority may split delivery between systems if they point to different providers. Remove or reprioritize old entries only as your routing plan requires.
After the change, query public DNS for the domain's MX records and send a test message from an external account. Check where it arrived and review message trace in Exchange Online. Continue monitoring the previous route while resolver caches expire.
Check Autodiscover and outbound authentication
Autodiscover
For a cloud-only Exchange Online setup, compare the public autodiscover CNAME with the value shown in Microsoft 365, commonly autodiscover.outlook.com. In hybrid environments, review internal and external discovery plus any on-premises dependencies before changing it. If Outlook still opens the old mailbox after DNS is correct, inspect the existing profile and sign-in context.
SPF
Publish one SPF TXT record per sending domain or subdomain. If an SPF record already exists, add the appropriate Microsoft 365 mechanism to that record while retaining other legitimate senders. The simple value v=spf1 include:spf.protection.outlook.com -all fits only when Microsoft 365 is the sole authorized sender for that domain. Check the final record for duplicate SPF entries and excessive DNS lookups.
DKIM
For a custom sending domain, use the two selector1._domainkey and selector2._domainkey CNAME targets displayed for that domain in Microsoft 365. Target formats vary by when a domain was added, so do not copy another tenant's selector values. Once DNS is visible, enable DKIM signing for the custom domain and test an outbound message.
DMARC
Review the TXT record at _dmarc.yourdomain.com and the alignment of your legitimate sending services. If you are introducing DMARC, a p=none policy lets you monitor reports while you check SPF and DKIM; it does not instruct receivers to reject failing mail. Move to an enforcement policy only after reviewing the results and resolving legitimate failures.
Domain verification and other Microsoft 365 services
If the custom domain has not been verified in the destination tenant, use the verification TXT value generated in that tenant. In a tenant-to-tenant move, plan this alongside the removal of source-tenant domain references. TXT verification by itself does not redirect mail.
Teams, Intune, and other selected services can require additional CNAME or SRV records. Add only the records shown for the services you are configuring; they are not all required for an email-only migration.
Allow for DNS caching during the transition
DNS resolvers can keep an earlier answer until its TTL expires, so different senders may temporarily use different routes. Lowering TTL before the cutover can shorten later caching, but it does not erase records that are already cached. There is no fixed worldwide propagation time that applies to every DNS change.
Keep the previous route available until test mail and message traces show the intended flow and older cached paths are no longer delivering there. Record the original settings so the team can investigate or reverse a change if required.
Validate DNS, mail flow, and client access
- Query the public records from more than one resolver. For example, use
nslookup -type=mx yourdomain.comandnslookup -type=txt yourdomain.com. Check the Autodiscover CNAME, both DKIM selectors, and_dmarc.yourdomain.comseparately. - Confirm the domain's DNS status in the Microsoft 365 admin center, then send inbound and outbound test messages to an external address.
- Check Exchange Online message trace for delivery and inspect a received message's authentication results for SPF, DKIM, and DMARC. A successful inbound test does not prove outbound authentication.
- Test Outlook setup for representative users and verify that mail sent during the transition reached the intended mailbox. Compare the migration reports with the destination mailbox before closing the old route.
Common problems after the switch
Why does mail still reach the old server?
Check cached MX answers, an old MX record with equal or higher priority, and any gateway that forwards to the previous environment. If public DNS is correct, use message trace and the old server's logs to identify the actual path.
Why does Outlook open the old mailbox?
Public DNS may be correct while internal Autodiscover, an existing Outlook profile, or a previous-tenant sign-in still points to the source. Test from inside and outside the network and review the client profile before changing more DNS records.
Why are outbound messages failing authentication?
Look for two SPF TXT records, an omitted third-party sender, DKIM selectors copied from the wrong tenant, or a DMARC policy that was tightened before all legitimate sources aligned. Fix the specific failing source and retest rather than removing authentication checks for the whole domain.
Additional resources:
