Domain Change Email Migration: The Rebrand Runbook

A rebrand looks like a marketing project until you reach the email section of the plan. Then it becomes an identity, DNS, and authentication project that touches every employee, vendor, and customer who has ever sent you a message. A domain change email migration done badly produces bouncing mail, broken calendar invites, and quarantined newsletters for months. Done well, it is invisible to the outside world and finished in a single weekend window. This is the runbook you want open on your second monitor while the change ticket is in flight.

What actually changes when the company name changes#

The marketing announcement says "Company X is now Company Y." Inside your tenant, dozens of dependent objects need to be updated, and the order matters.

The list, roughly:

• The accepted domain list on your mail tenant
• The primary SMTP address on every user, shared mailbox, distribution list, and Microsoft 365 group
• The default send-as identity for every mailbox
• DNS records for the new domain: MX, SPF, DKIM selectors, DMARC, Autodiscover, MTA-STS, optional BIMI
• The internal address book and any cached nicknames in user Outlook profiles
• Mobile device profiles, especially iOS Mail accounts created from a Microsoft 365 profile
• SAML and OIDC identity providers that emit email as the NameID claim
• Third-party SaaS apps that key on the user's email address
• Email signatures, banner disclaimers, and footer legal text
• Outbound transactional senders (transactional ESPs, payment processors, ticketing)

If you skip any of those, the rebrand leaks. Customers see the old logo on a transactional receipt, or a partner replies to a thread and gets a non-delivery report a month after launch day.

Decide the topology before you touch DNS#

There are three common shapes for a domain change email migration, and they have very different effort levels.

Same tenant, new primary domain. The most common case. You add the new domain as an accepted domain, add it as a UPN suffix and proxy address, swap the primary SMTP, and update DNS. No mailbox content moves. Plan one weekend for cutover.

New tenant, new domain. The parent company spun you out, or compliance demands a clean tenant. You stand up a new tenant, migrate mailboxes with a tool, and cut DNS at the end. See the tenant-to-tenant migration guide for the heavy version of this work.

Hybrid, old domain stays. The new brand is customer-facing only. Internal mail keeps using the old domain. Cheap on the IT side, but creates ongoing confusion for new hires and external partners. Most rebrands evolve out of this within 18 months.

Pre-flight: the 30-day countdown#

Email cutovers fail because of work that should have happened weeks earlier. The countdown looks like this.

T-30 days: discovery#

Pull a list of every mailbox, alias, distribution group, shared mailbox, and resource calendar. Note which ones have external auto-replies, forwarders, or transport rules pointing at the old domain. Export the list to a spreadsheet that becomes your tracking sheet for the entire project.

Run a DNS audit on the old domain. You need the current MX, SPF, DKIM selectors, DMARC policy, Autodiscover record, any MTA-STS or TLS-RPT records, and any SRV or CNAME records used by third-party services like Zoom, Slack SCIM, or DocuSign. Document the TTLs. Anything above 3600 needs to come down to 300 a week before cutover.

T-21 days: register and validate#

Buy the new domain if you haven't already. Verify it inside your mail tenant. For Microsoft 365 that means adding the TXT verification record. For Google Workspace, you add the domain in the admin console and pass the verification check. Do not add the new domain as primary yet — just verified and active.

Set up DKIM for the new domain immediately, even before users start sending. DKIM selectors need time to propagate and need to exist before you start signing outbound mail.

T-14 days: shadow SPF and DMARC#

Publish SPF for the new domain at this stage with a permissive ~all. Publish DMARC at p=none with both rua and ruf reporting addresses. You want two weeks of DMARC aggregate reports landing in your inbox before you flip the primary, so you can spot any third-party sender you forgot.

v=DMARC1; p=none; rua=mailto:dmarc@newdomain.com; ruf=mailto:dmarc@newdomain.com; pct=100; fo=1; sp=none; adkim=r; aspf=r

When you cut over, you can move DMARC to p=quarantine after two weeks of clean reports.

T-7 days: comms and TTL reduction#

Send the first all-staff comms with the timeline, the new address format, and the things they personally need to do (mostly: nothing, but update LinkedIn and email signatures on Monday). Send vendor comms with the new domain so anyone who uses an allowlist can pre-add you. Reduce DNS TTLs to 300 seconds on the old domain so you can roll back fast if needed.

T-1 day: freeze#

No mailbox creation, no group changes, no transport rule edits, no inbound role changes. The configuration you cut over with is the configuration you tested.

Cutover weekend#

Friday evening, after most of the business is offline. The order matters because of how email clients cache identities.

Step 1: Add the new domain as an accepted/secondary domain#

If you haven't done this in pre-flight, do it now. The tenant will route mail for both domains while you stage the switch.

Step 2: Add the new SMTP address to every object#

Every user gets firstname.lastname@newdomain.com added as a secondary SMTP. Same for shared mailboxes, distribution groups, and Microsoft 365 groups. At this point the new domain accepts inbound mail and delivers it to the right mailbox.

Step 3: Swap MX#

Point the new domain MX at your tenant's inbound endpoints. Inbound mail to the new domain now flows correctly. Watch your DNS resolver for two cycles to confirm propagation.

Step 4: Make the new domain primary#

For each user and group, set the new SMTP as the primary. The old SMTP remains as a secondary alias. Users sending from the desktop client will now stamp messages with the new From address, which is what you want.

Step 5: Update outbound DNS#

Tighten SPF on the new domain from ~all to -all after you confirm DMARC reports are clean. Move DMARC from p=none to p=quarantine. Don't go to p=reject until you have a month of clean data — see MX record reference for why aggressive DMARC during a rebrand will quarantine your own marketing newsletter.

Step 6: Verify#

Send a test from each platform (Outlook Win, Outlook Mac, Outlook Web, iOS Mail, Android Gmail) to an external address and an internal address. Check headers for the new From, correct SPF pass, correct DKIM signature on the new selector, and DMARC pass. Reply to a thread that started on the old domain and confirm replies go to the new From.

The alias period: how long is long enough#

The old domain stays alive as an alias on every user and group for at least 12 months. That is the conservative floor. Here is what fails after each milestone if you remove it too soon.

Month 1–3: Customer reorders, support ticket replies, vendor invoices, SaaS password reset flows, partner introductions made before launch day.

Month 4–6: Quarterly business reviews, contract renewals dated from before the rebrand, NDA exchanges that referenced the old domain.

Month 7–12: Annual subscription renewals from any vendor billed yearly. Auditors and tax authorities who file annual paperwork.

Year 2+: Long-tail. People who only email you every couple of years. Lapsed customer reactivations.

A clean shutdown sequence at month 18 looks like this: stop publishing the old domain in any new outbound material, add the subject prefix at month 15, send an external announcement at month 17, switch the old domain to forward-only for executives and a noreply autoresponder for everyone else at month 18, and keep the catch-all running on the old domain until month 24. Then you can finally take it offline.

Special cases that bite#

Calendar invites#

Existing recurring meetings have the organizer's old SMTP baked into the iCalendar payload. Recipients who decline-then-accept may bounce. There is no clean automated fix; the practical answer is to leave the organizer alias in place for at least the duration of the longest recurring meeting series, which for most organizations means 24 months.

Shared mailboxes and resource accounts#

Easy to miss because they don't have a human owner. Pull a complete list and add the new domain as primary for every one. Resource calendars for meeting rooms are particularly nasty — bookings created before the rebrand will reference the old room mailbox SMTP forever.

Hard-coded vendor configurations#

Allowlists at upstream mail providers, SMS-to-email gateways, scanner-to-email functions on office copiers, SCADA alert systems, monitoring tools (PagerDuty, Datadog, Opsgenie), and CI/CD pipelines that email build results. Every one of these needs an inventory step.

SSO NameID#

If your SAML NameID is the user's email and that email is changing, every app the user authenticates into will create a new account. Either pre-migrate by changing NameID to an immutable claim (objectGUID, sub) before the rebrand, or accept the per-app account merge work.

User communications that actually land#

Three rounds, kept short.

The first round, 14 days out, is a single email to all staff. It states the new domain, the date, and the one thing they need to do (replace their signature on Monday). No FAQ document, no Confluence page, no Teams channel. The shorter the message the more people read it.

The second round, the morning of cutover, confirms the change is happening that evening and gives an internal Slack or Teams channel to ping if anything looks wrong on Monday morning.

The third round, Monday morning, is the actual rebrand announcement that goes to customers. By then your DNS is settled and you can answer external questions confidently.

External customer comms are separate and live with the marketing team. Your job in IT is to make sure that when they hit send, the From address says the right thing and the SPF/DKIM/DMARC posture is correct.

When to combine the rebrand with a tenant move#

Sometimes the rebrand coincides with a divestiture, an acquisition, or a long-overdue tenant consolidation. The temptation is to do everything in one weekend. The reality is that adding mailbox content migration to a domain change roughly triples the timeline and the risk.

A clean sequence: do the tenant work first, with both old and new domains active on the new tenant. Once mailboxes are settled and validated, do the domain change as a second, smaller cutover. If you are reading this because the rebrand is driven by a corporate transaction, the merger and acquisition email migration playbook and the divestiture email migration guide both cover the tenant side of the work.

For the foundational concepts behind any of these moves, the complete email migration guide is the canonical reference.

Rollback criteria#

You roll back if you see any of these inside the first six hours:

• More than 2% of test sends failing DMARC at receivers
• Inbound mail to the new domain not delivering after two DNS resolver cycles
• Authentication failures on mobile devices for more than 10% of users
• Calendar free/busy lookup failures across the org

Rolling back means restoring the old domain to primary, dropping MX changes on the new domain, and not touching DKIM (you keep what you published). Keep the rollback runbook printed. The mistake people make is leaving the rollback in someone's head and then they go to sleep at 4 AM.