DNS Cutover for Mail: MX, Autodiscover, SPF, DKIM, DMARC and TTL

The migration itself may take weeks, but the moment users notice is a handful of DNS changes. Get the order wrong and mail bounces, Outlook profiles fail to build, or the first messages from the new tenant land in spam.

This post lists each record, what it does, when to change it, and how to confirm it took.

TTL planning: the change before the change

Every record has a time to live, and resolvers around the world cache the old value for that long. If your MX has a TTL of 86400, some mail servers will keep delivering to the old host for a full day after you change it.

At least two days before cutover, lower the TTL on MX, autodiscover and the root TXT record to 300 seconds. Do not change the values yet, only the TTL. Wait for the old TTL to expire so every cache has picked up the short one. After the migration settles, raise TTLs back to 3600.

dig +noall +answer MX domain.com
dig +noall +answer autodiscover.domain.com
nslookup -type=TXT domain.com 8.8.8.8

MX and Autodiscover

The MX record tells the world where to deliver your mail. Microsoft 365 gives you a hostname in the admin center under Settings, Domains, and it looks like domain-com.mail.protection.outlook.com. Use exactly the value shown for your tenant, with priority 0, and remove every other MX. A leftover MX for the old host means mail arrives in two places for weeks.

Autodiscover is what Outlook, phones and the Exchange Online tooling use to find the mailbox. It is a CNAME from autodiscover.domain.com to autodiscover.outlook.com. In a hybrid migration, keep it pointing at the on-prem server until the last mailbox has moved, because the on-prem Exchange redirects moved users to the cloud but Exchange Online cannot redirect users back the other way. In a cutover or IMAP migration, change it at the same time as MX.

• MX: domain-com.mail.protection.outlook.com, priority 0, as shown in the admin center.
• autodiscover CNAME: autodiscover.outlook.com.
• Remove old MX, old autodiscover A records, and SRV records for _autodiscover._tcp if any exist.

SPF, DKIM and DMARC

SPF lists which servers may send mail for your domain. The record is a TXT at the root, and Microsoft 365 needs include:spf.protection.outlook.com. Keep any other legitimate senders such as your CRM, marketing platform or ticket system, and remove the old mail server's IP once it stops sending. Stay under ten DNS lookups in the record or receivers will treat it as invalid.

DKIM signs outbound mail with a key that Microsoft holds. Enable it per domain in the Defender portal under Email authentication settings, or with PowerShell. The portal shows two CNAME records, selector1._domainkey and selector2._domainkey, which point at hostnames inside your tenant's onmicrosoft.com domain. Create both, wait for them to resolve, then enable signing. Without DKIM, DMARC alignment fails for forwarded mail.

DMARC tells receivers what to do when SPF and DKIM both fail and where to send reports. Start with p=none and a reporting address so you can see what is sending on your behalf, then move to quarantine and reject once the reports are clean.

v=spf1 include:spf.protection.outlook.com -all
selector1._domainkey  CNAME  selector1-domain-com._domainkey.tenant.onmicrosoft.com
selector2._domainkey  CNAME  selector2-domain-com._domainkey.tenant.onmicrosoft.com
_dmarc  TXT  v=DMARC1; p=none; rua=mailto:dmarc@domain.com

Connect-ExchangeOnline
New-DkimSigningConfig -DomainName domain.com -Enabled $true
Get-DkimSigningConfig -Identity domain.com | Format-List Selector1CNAME, Selector2CNAME, Enabled

The records people forget

A few CNAMEs are not needed for mail but make the rest of Microsoft 365 work. Enterpriseregistration and enterpriseenrollment point Windows and mobile devices at Entra ID and Intune for device join and enrollment. The admin center shows the full list per domain, and it will flag anything missing.

If you keep an on-prem SMTP relay, an internal DNS zone for the same domain, or split-brain DNS, update those copies too. An internal autodiscover record pointing at a decommissioned server breaks profile creation inside the office while everything works from home.

• enterpriseregistration CNAME to enterpriseregistration.windows.net
• enterpriseenrollment CNAME to enterpriseenrollment.manage.microsoft.com
• Internal DNS zone copies of MX and autodiscover
• Any mail hostnames in the certificate that other systems reference, such as mail.domain.com for a scanner

Verifying the cutover

Once the records are in, check them from outside your network. Public resolvers show what the rest of the world sees, which is not always what your internal DNS returns. Then send test messages in both directions and read the headers of the reply. Authentication-Results should show spf=pass and dkim=pass with the signing domain being yours, not onmicrosoft.com.

Microsoft's Remote Connectivity Analyzer at testconnectivity.microsoft.com runs an Outlook Autodiscover test and an inbound SMTP test against your domain. Run both after the change and keep the results.

1. Confirm MX from two public resolvers.
2. Confirm autodiscover resolves to the new target.
3. Send from Gmail to a migrated user and back, check headers for spf and dkim pass.
4. Run the Remote Connectivity Analyzer Autodiscover and SMTP tests.
5. Check the Microsoft 365 message trace for the test messages.

Frequently asked questions

Takeaway

Lower TTLs early, change MX and Autodiscover in the right order for your migration type, and add SPF, DKIM and DMARC before the first message leaves the new tenant. Then verify from outside and keep the results. DNS is the smallest part of a migration and the one that generates the most tickets when rushed.