How far in advance should I lower the MX record TTL?

Lower it before you start the email migration, not on cutover day. Microsoft recommends a TTL of 3,600 seconds (one hour) or less on every MX record, so sending systems refresh your MX at least hourly by the time you switch. Remote systems keep the old value cached until the previous, longer TTL expires, so make the change at least one full old-TTL period before cutover.

How long does an MX record change take to work?

Microsoft's cutover guidance says it can take up to 72 hours for the email systems of your customers and partners to recognize a changed MX record. Keep the old system receiving mail and keep migration syncs running until that window has passed.

Should I delete the old MX record or just lower its priority?

Either works for routing, because mail goes to the MX record with the lowest preference number. Microsoft recommends removing MX records that point to the old system once mail is flowing to Exchange Online, because multiple MX records can cause delivery problems.

Why do some senders get 550 5.4.1 Recipient address rejected after cutover?

Directory-based edge blocking in Exchange Online rejects mail for addresses that don't exist in the tenant. Check the address exists as a mailbox, group or contact in Exchange Online. If a whole domain is affected, switch the accepted domain to Internal relay and back to Authoritative to resync it.

Email cutover checklist - TTL, MX switch, Autodiscover

A clean email cutover to Exchange Online comes down to three things: lower the MX record's TTL to 3,600 seconds or less well before cutover, switch MX (and Autodiscover) only after every mailbox exists and has synced, and keep the old system receiving and syncing for up to 72 hours while the change propagates. Day-one support then focuses on message trace, Autodiscover and Outlook profiles, and bounces from addresses that don't exist in the new tenant.

Who this is for and what you will have at the end

This checklist is for administrators running the final switch of a domain's mail to Exchange Online, whether the source is on-premises Exchange (cutover or staged), Google Workspace, an IMAP host or another Microsoft 365 tenant. It assumes the mailbox migration tooling itself is already working. At the end you will have:

A dated runbook from one week before cutover to three days after.
DNS records prepared so the switch takes effect quickly and predictably.
A day-one support plan with the tools and fixes for the common tickets.
Clear criteria for when to stop syncing and retire the old system.

For source-specific detail, see the Google Workspace to Microsoft 365 migration guide and the Microsoft 365 tenant-to-tenant migration architecture.

The cutover timeline at a glance

When	Task
Before migration starts (at least one old-TTL period before cutover)	Lower TTL on every MX record to 3,600 seconds or less; record current DNS values
T-3 to T-1 days	Confirm all recipients exist in Exchange Online, licences assigned, SPF merged, accepted domain type decided, users told what will change
T-0	Final sync; switch MX; switch Autodiscover CNAME; clear Exchange SCP if applicable; test inbound and outbound
T-0 to T+1	Day-one support: message trace, Outlook profiles, mobile devices, bounces
T+3 (72 hours)	Confirm no mail reaching the old system; final sync; complete or delete migration batches; remove old MX records; restore longer TTL

Prerequisites

The domain is added and verified in Microsoft 365 (Settings > Domains in the Microsoft 365 admin center).
Access to the public DNS zone at your DNS host, and to internal DNS if clients resolve Autodiscover internally.
Every user, shared mailbox, group and contact that receives mail for the domain exists in Exchange Online.
Exchange Online PowerShell for message trace and accepted domain changes.
A written rollback plan: the old MX values, TTLs and who can change them.

Before migration: lower the TTLs

Sending servers cache your MX record for the record's time to live (TTL). If you switch MX while senders still hold a long-lived cached value, they keep delivering to the old system until it expires. Microsoft's cutover guidance is to set the MX TTL to 3,600 seconds (one hour) or less before you start the email migration, on every MX record if you have more than one. Microsoft's DNS guidance also notes that Exchange Online only supports TTL values of less than 6 hours (21,600 seconds).

Do the same for the Autodiscover record, and for any A record that clients use to reach the old mail system. Capture the current state so you can roll back:

Resolve-DnsName -Name contoso.com -Type MX
Resolve-DnsName -Name autodiscover.contoso.com -Type CNAME
Resolve-DnsName -Name contoso.com -Type TXT | Where-Object { $_.Strings -match 'v=spf1' }

Lowering the TTL only takes effect after the old TTL has expired in resolvers around the internet, which is why this can't be left to cutover day.

T-3 to T-1: final readiness

Recipients and licences

Microsoft's guidance for connecting a domain is to add users and set up mailboxes for everyone on the domain before you update the MX record, so mail keeps working as it moves. In a cutover migration from Exchange, migrated users still need licences; without one, the mailbox is disabled when the 30-day grace period ends.

Check for gaps: shared mailboxes, distribution lists, mail-enabled public folders, resource mailboxes, and service addresses used by applications. Any address that doesn't exist in Exchange Online will bounce once the domain is authoritative.

Accepted domain type

Microsoft recommends temporarily setting the accepted domain to Internal relay while you set up an environment, and switching it to Authoritative after every intended recipient exists in Exchange Online and has replicated. Authoritative turns on directory-based edge blocking, which rejects mail for unknown recipients. Decide in advance when you will flip it, and do not flip it before the recipient list is complete.

SPF

You can have only one SPF TXT record per domain. If the old system will still send mail during the transition, merge the Microsoft 365 include into the existing record instead of adding a second one:

v=spf1 include:spf.protection.outlook.com include:mail.contoso.com -all

After the old system stops sending, trim the record to v=spf1 include:spf.protection.outlook.com -all, then move on to DKIM and DMARC.

Communications

Tell users when the switch happens, what changes in Outlook and on phones, how to reach the old mailbox if needed, and where to report problems. Microsoft's cutover process ends with a welcome message explaining how to sign in to the new mailbox.

T-0: switch MX and Autodiscover

Run or confirm a final incremental sync so the Exchange Online mailboxes are current.
In the Microsoft 365 admin center, go to Settings > Domains, select the domain, open DNS records and copy the exact MX value shown. Don't build it from a pattern; use the value the admin center gives you.
At the DNS host, create the Exchange Online MX record with the highest priority available (typically preference 0) and TTL 3,600.
Either remove the MX records that point to the old system or give them a lower priority (a higher preference number) than the Exchange Online record. Mail is delivered to the record with the lowest preference number.
Update the Autodiscover CNAME so autodiscover points to autodiscover.outlook.com, in external DNS and in internal DNS if you have a split zone.
If the source is on-premises Exchange, stop domain-joined Outlook clients from finding the old server through the Active Directory service connection point:

Get-ClientAccessService | Set-ClientAccessService -AutoDiscoverServiceInternalUri $null

On Exchange 2010 or 2013, use Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri $null instead.

Verify the new records resolve from your network:

Resolve-DnsName -Name contoso.com -Type MX
Resolve-DnsName -Name autodiscover.contoso.com -Type CNAME

Send test messages from an external mailbox to several migrated users, and from a migrated user to an external mailbox. Confirm both in message trace.

Microsoft notes it can take up to 72 hours for other organizations' mail systems to recognize the changed MX record. Until then, some mail will still land on the old system, which is why the old system must keep accepting mail and migration syncs must keep running.

Day one: support

Tools to have open

Message trace. In the Exchange admin center go to Mail flow > Message trace (or https://admin.exchange.microsoft.com/#/messagetrace). The default query covers the last two days; results under 10 days are available immediately as a summary report. In PowerShell, use Get-MessageTraceV2 (Exchange Online PowerShell module 3.7.0 or later), which accepts a maximum of 100 query requests in a running five-minute window. Without parameters it returns only the last 48 hours, and each query can cover at most 10 days:

Get-MessageTraceV2 -SenderAddress partner@fabrikam.com -StartDate (Get-Date).AddHours(-12) -EndDate (Get-Date)

Status values include Delivered, Failed, Pending, Quarantined, Filtered as spam and Getting status; reported status can lag the real state by five to ten minutes.

Microsoft Remote Connectivity Analyzer. The Exchange Online test suite at https://testconnectivity.microsoft.com simulates client logon and mail flow from the internet and returns success, warning or fail results with guidance. Check the Microsoft 365 Service Health dashboard first, so you don't chase a service incident.

The tickets to expect

"Outlook still shows my old mailbox." Outlook is using a cached profile or an SCP that still points on-premises. Confirm the SCP was cleared and the Autodiscover CNAME resolves. If Outlook still connects to the old mailbox, create a new Outlook profile; Microsoft's cutover guidance points users to creating new Outlook profiles as part of the welcome communication.
"My phone stopped syncing." Check that the Autodiscover CNAME resolves externally, then remove and re-add the account on the device so the mail app looks up the new location through Autodiscover instead of using its saved settings.
"An external sender's mail bounced." Read the NDR code. 550 5.4.1 Recipient address rejected: Access denied means directory-based edge blocking didn't find the recipient. Check spelling, check the recipient exists in Exchange Online, and if every recipient in the domain is affected, switch the accepted domain from Authoritative to Internal relay and back to resync it.
"I'm missing recent mail." The message probably arrived at the old system from a sender still using a cached MX. Confirm with the old system's logs, and make sure the migration batch keeps syncing until the 72-hour window has passed.
"Mail from our scanner or application stopped." Devices that sent through the old server need to be pointed at Exchange Online SMTP relay or another service.

T+3: close out

Confirm no new mail is arriving at the old system.
Run a final sync. For a cutover migration from Exchange, check that the batch's Last Synced Time is later than the moment mail started routing to Exchange Online, then delete the cutover batch. After deletion, mail sent to the old mailboxes is no longer copied.
Remove any remaining MX records that point to the old system.
Raise the MX and Autodiscover TTLs back to your normal values.
Trim the SPF record and enable DKIM and DMARC for the domain.
Switch the accepted domain to Authoritative if it isn't already, now that every recipient exists.
For on-premises Exchange, plan decommissioning separately; the last Exchange server guide covers hybrid environments.

Troubleshooting

MX looks right internally but senders still deliver to the old system. External resolvers still hold the old record because the TTL was lowered too late. Wait out the old TTL; keep the old system receiving and syncing.

Admin center shows the domain with DNS issues after cutover. Recheck the records against the values listed under Settings > Domains > your domain > DNS records, especially duplicate SPF records and stray MX records.

Two SPF records published. A domain can have only one SPF TXT record. Merge both sets of includes into a single record.

Bounces only for one group or shared address. That recipient wasn't created in Exchange Online. Create it, or temporarily set the domain to Internal relay while you fix the gap. Changes to on-premises synced recipients can take up to 24 hours to update directory-based edge blocking.

Message trace shows nothing for a message. It most likely never reached Exchange Online; the sender is still using the old MX or the message was rejected upstream. Ask for the NDR or the sender's server logs.

Checklist

MX (and Autodiscover) TTL at 3,600 seconds or less, set at least one old-TTL period before cutover.
Current DNS values recorded for rollback.
Every recipient exists in Exchange Online; licences assigned.
Accepted domain type decided; Authoritative only after recipients are complete.
Single merged SPF record.
Users informed; support staff briefed on Outlook profiles, mobile devices and NDRs.
MX copied from the admin center, old MX removed or deprioritised, Autodiscover CNAME and SCP updated.
Inbound and outbound tests confirmed in message trace.
Old system kept receiving and syncing for 72 hours; final sync done; batch completed or deleted.
TTLs restored, SPF trimmed, DKIM and DMARC enabled.

Email migration cutover checklist: DNS TTLs, MX switch and day one