DNS Cutover

DNS is where a tenant migration finally becomes real

By Captain O7 min read

You can copy every mailbox in the background and nobody notices. The migration only becomes real the moment you change a DNS record and mail for the whole company starts landing somewhere new. Get the order and the timing right and it is a quiet Tuesday. Get them wrong and mail bounces for a day.

New to cloud? CAMPUX is a free, build-first course. Start here →

This is part of the Azure tenant-to-tenant migration guide, and it is the piece where all the invisible work meets the public internet. Mailboxes can be synced, licenses assigned, and users provisioned in the target tenant while the source tenant is still handling live mail — none of that touches a user's day. DNS is different. The MX record and the autodiscover record are read by the entire world: every sending mail server, every Outlook client, every phone. When you change them, you are telling the internet that this domain lives somewhere new now. That is the cutover.

Figure 1 — DNS is where the cutover becomes real. Lower the time-to-live on the records days ahead, so when you flip them the change propagates in minutes instead of a day. At cutover the verification TXT proves the domain to the target, MX and autodiscover point mail at its new home, and SPF, DKIM, and DMARC are realigned. Sequence it with removing the domain from the source.

The records that actually carry the switch

A short list does the heavy lifting. The MX record tells the world which mail server accepts mail for the domain; repointing it at the target tenant is what makes new inbound mail land in the new mailboxes. The autodiscover record — a CNAME pointing at autodiscover.outlook.com — is how Outlook and mobile clients find where a mailbox now lives and reconfigure themselves; without it, users get password prompts that never resolve. Then the authentication trio: SPF, DKIM, and DMARC. These have to be realigned so that mail sent from the target tenant passes checks at the receiving end. Miss them and your outbound mail quietly starts landing in junk folders, which is worse than a bounce because nobody tells you.

The verification TXT comes first, and it is harmless

Before any of the live records move, the target tenant has to prove it owns the domain. Microsoft hands you a unique TXT record value; you publish it in the domain's public DNS, Microsoft queries it, sees its own value staring back, and accepts that you control the domain. That is all it does. It carries no mail, changes no routing, and breaks nothing — which is exactly why you publish it early. The catch that governs the whole cutover: a custom domain can be verified in only one tenant at a time. Microsoft's own migration guidance states plainly that the source and target tenant domains must be unique. So the domain cannot be verified in the target while it still lives in the source.

A domain lives in one tenant at a time. Cutover is a handoff, not an overlap.

Lower the TTL long before you touch anything

TTL, time to live, is the number of seconds a resolver is allowed to cache a record before checking again. If your MX TTL is a day, a change can take 24 to 48 hours to reach everyone, and there is nothing you can do to hurry it. So you plan ahead. At least 48 to 72 hours before cutover, drop the TTL on the MX, autodiscover, and SPF records to something small — five minutes is a good target. Nothing else changes yet; you are just shrinking the cache window. When cutover night comes, a record change propagates in minutes instead of a day, and if something goes wrong you can roll back just as fast. TTL is the one dial that decides whether your cutover has a safety margin or a 24-hour commitment.

Why the low TTL is non-negotiable

Think about the failure you are guarding against. You cut the MX over, and a mailbox turns out not to be fully migrated, or authentication is misaligned and mail starts bouncing. With a five-minute TTL you revert the record and the world catches up before your coffee is cold. With a one-day TTL you are stuck watching the problem for up to 48 hours while half the internet still holds the old answer. Same change, wildly different blast radius — the only difference is a number you set two days earlier.

The cutover, in order

Sequence is everything here. Publish the verification TXT for the target well ahead of time so it is ready. When the mailbox data is fully caught up, you remove the domain from the source tenant (this is the step that frees it), then add and verify it in the target using that TXT. Only now do you move the live records: repoint the MX to the target, point autodiscover at the target's endpoint, and realign SPF, DKIM, and DMARC so outbound mail authenticates. Because you lowered the TTLs days ago, mail starts flowing into the new mailboxes within minutes. One honest note on timing: while the domain is being removed from the source and reverified in the target, there is a genuine window where inbound mail has nowhere clean to land, which is why this whole dance is usually done off-hours and paired with a plan to queue or forward stragglers. The overlap and coexistence details — how mail keeps flowing between the two tenants during the move — are their own discipline, covered in mail routing and coexistence.

The takeaway

DNS is not the hard part of a tenant migration — it is the visible part, the moment the whole thing stops being a background copy job and becomes something users feel. Publish the verification TXT early because it is harmless. Lower your TTLs 48 to 72 hours ahead because that number is your entire safety margin. Then run the cutover in order: free the domain from the source, verify it in the target, move MX and autodiscover, realign SPF, DKIM, and DMARC. "Low TTLs set two days out, TXT ready, domain removed from source before it is verified in target, then MX and autodiscover last" is the sequence you keep once you have run it live on a Friday night and watched mail arrive exactly where it was meant to.

Questions people also ask

Can the same domain be verified in two Microsoft 365 tenants at once?

No. A custom domain can be verified in only one tenant at a time, and Microsoft's guidance is explicit that the source and target tenant domains must be unique. To move a domain you remove it from the source tenant, which frees it, then add and verify it in the target with a TXT record. That is why cutover is a hard switch rather than an overlap.

What DNS records change during a tenant-to-tenant email cutover?

The MX record repoints inbound mail to the target tenant. The autodiscover CNAME points Outlook and mobile clients at the new mailboxes. SPF, DKIM, and DMARC records are realigned so mail sent from the target passes authentication. A verification TXT proves ownership of the domain to the target tenant before any of the live records move.

Why do you lower DNS TTL before a migration cutover?

TTL tells resolvers how long to cache a record. Left at a day, an MX change can take up to 24 to 48 hours to reach everyone. Lower the TTL on MX, autodiscover, and SPF to a few minutes at least 48 to 72 hours before cutover, and a change propagates in minutes. It is your safety margin, and your ability to roll back fast.

What does the domain verification TXT record actually do?

The target tenant gives you a unique TXT value to publish in the domain's public DNS. When Microsoft queries that record and finds the value, it accepts that you control the domain and lets the tenant claim it. It proves ownership, nothing more. It carries no mail and changes no routing, so you can publish it ahead of the real cutover.

How long does mail take to move after you change the MX record?

It depends on the TTL you set. With MX TTL lowered to five minutes days in advance, most senders pick up the new record within minutes and mail flows into the target mailboxes. Some resolvers and sending systems cache longer, so keep the source able to receive and forward for a day or two to catch stragglers.