Adding a new domain to Microsoft 365 without email downtime

Adding a domain is a wizard with five green ticks, which is why people treat it as a ten-minute job and then spend the afternoon explaining why mail from the new brand is landing in spam or bouncing. The wizard is fine for a domain that has never received mail. For a domain that is live somewhere else — an acquired company, a brand moving off a legacy host — the wizard's order is wrong, because it wants the MX record early. This runbook puts the MX last.

The general DNS reference is in domains and DNS setup; this is the sequencing for a domain that must not drop a message.

Step 1: verify ownership, and nothing else

Microsoft 365 admin center → Settings → Domains → Add domain. Add the TXT verification record at the registrar and verify. Stop the wizard here — choose to configure DNS yourself, not to have Microsoft add records. Verification changes nothing about mail flow; the domain is now known to the tenant and can be attached to users.

If the domain is already verified in another Microsoft 365 tenant (the seller's, in an acquisition), it must be removed there first, which means every user, group and alias in that tenant using it has to be changed. A domain cannot exist in two tenants, and there is no support process that shortcuts the removal.

Step 2: decide the accepted-domain type

Exchange admin center → Mail flow → Accepted domains. The verified domain appears as Authoritative by default: Exchange Online believes it holds every mailbox for the domain and rejects mail to any address it does not know.

For a domain whose mail still lives elsewhere during a transition, or which has some recipients on-prem in a hybrid, change it to Internal relay. Exchange Online then forwards mail for unknown recipients to wherever an outbound connector says. This one setting is the difference between "coexistence" and "bounces for every user not yet migrated". Switch it back to Authoritative once every recipient is in the tenant.

Step 3: authentication records, before any mail is sent

Set these up while the MX still points at the old system. None of them affects inbound mail.

SPF. The domain's existing SPF record must gain include:spf.protection.outlook.com without dropping the current sender. A domain sending from two platforms during transition needs both in one record; the ten-DNS-lookup limit is the constraint to check.

DKIM. Exchange Online publishes two selectors per domain. In the Defender portal → Email authentication settings → DKIM, select the domain, and it shows the two CNAME records (selector1._domainkey and selector2._domainkey) to create. Add them, wait for DNS, then enable signing. Enabling before the CNAMEs resolve fails with an error, which is harmless — retry later. Mail sent before DKIM is enabled goes out signed with the tenant's default onmicrosoft.com domain, which passes DKIM but does not align for DMARC.

DMARC. If the domain has none, publish p=none with a reporting address now; you want reports from the first day. If it already has p=reject because the old platform was well run, leave it — provided SPF and DKIM above are done, Exchange Online mail will align. The DMARC rollout guide covers moving to enforcement.

MTA-STS and BIMI are optional and can wait.

Step 4: stamp addresses on users

Add the new domain as a proxy address on the users who need it. Whether it becomes the primary SMTP address depends on the business; a rebrand changes the primary, an acquisition often keeps the old one primary for a while. Either way, adding the alias means Exchange Online will accept mail for it the moment the MX moves, and users can send from it if it is primary or if they use Send As on an alias-capable client.

Do it by script, not by hand, and verify with Get-Mailbox -ResultSize Unlimited | Where-Object EmailAddresses -like "*@newdomain.com" afterwards. Missing aliases are the most common cause of bounces on day one. Groups, shared mailboxes, resource mailboxes and distribution lists all need the same treatment; the proxy addresses guide has the patterns.

Hybrid tenants: addresses on synced objects are stamped on-prem, either via the on-prem email address policy or directly in AD, and synced up. The domain must also be added as an accepted domain in on-prem Exchange and, if users will sign in with it, as a UPN suffix in AD. If your hybrid configuration was run before this domain existed, the send and receive connectors and the hybrid domain list need updating — rerunning the Hybrid Configuration Wizard is the supported way.

Step 5: Autodiscover, and a test

Create the autodiscover CNAME to autodiscover.outlook.com. If the old platform still serves Autodiscover for the domain and users' clients are still there, hold this until the mailboxes have moved — Outlook profiles that resolve the new Autodiscover before the mailbox exists will fail to connect.

Send a test from a mailbox with the new domain as primary to an external address on a different platform, and check the received headers: SPF pass, DKIM pass with the new domain's selector, DMARC pass. If any of the three fails, fix it before moving the MX; from this point on you are sending mail as the domain, and reputation starts accruing.

Step 6: the MX, at a quiet hour

Lower the TTL on the existing MX to something short a day ahead. Then change the MX to the value the admin center shows for the domain (domain-com.mail.protection.outlook.com), keeping the old MX briefly as a lower-priority backup only if the old system will still accept and forward mail — otherwise a backup MX pointing at a system that bounces unknown users does harm, not good.

Mail already in transit to the old MX keeps arriving there for the TTL window. If the old platform is being retired, either leave a forwarding rule on it for a fortnight, or set the old system's MX host to relay to Exchange Online. Nothing is lost if both ends accept mail; things are lost when one end stops without the other having started.

Watch the message trace for an hour. Bounces with "recipient not found" mean a missing alias or an authoritative domain that should have been internal relay. Bounces to external recipients mean the SPF change has not propagated or the DKIM selector is not enabled.

Downtime, honestly

None, if the MX is last and the aliases are stamped before it moves. The realistic risk is not lost mail but delayed mail during propagation, and mail from the new domain being treated with suspicion by receivers for a week while reputation builds. Warm the domain with normal traffic; do not launch a marketing send from it on day two.

Nothing here needs Microsoft support. The one step that needs an outside party is the old platform's provider, if mail has to be forwarded from it after the cutover — arrange that before the day, not on it.