Changing Your Company Email Domain in Microsoft 365 After a Rebrand: The Order of Operations
A rebrand looks like a marketing project until someone asks when the email addresses change. In Microsoft 365 that question touches every mailbox, sign-in name, group and shared mailbox, the DNS that keeps your mail out of junk, and every outside app where the login is an email address. Done in the right order, it is a low-drama week in which nobody loses a message. This is that order: what changes at each step, who does it, and what stays the same.
What changes, and what never does
Three things change: the domain in everyone's email address, the sign-in name (user principal name, or UPN) that matches it, and the DNS that authenticates mail from the new domain. Three things do not. The tenant's original .onmicrosoft.com name is permanent; Microsoft provides no way to rename it, and anyone promising it is selling you a tenant migration. The SharePoint URL does not change with the domain; Microsoft's separate tenant rename operation has real caveats (sync clients re-link, hard-coded links break) and is quoted as its own project. And no data moves: mailboxes, folders, rules, OneDrive files, Teams chats and memberships, and MFA registrations stay put.
Passwords do not change either. Users get a new sign-in name with the same password and may see a one-time prompt to sign in again in Outlook, Teams, OneDrive and phone apps; that is the whole user-facing event, which is why the change runs in batches during business hours rather than as a weekend big bang.
If people need to land in a different tenant, because the rebrand is really a merger, demerger or spin-off, that is a tenant-to-tenant migration, which often includes a domain change as one step.
Steps 1 and 2: verify the new domain and authenticate it before anyone moves
Register the new domain in your own registrar account and add it to the tenant; verification is a TXT record in its DNS. Then publish the rest before a single user is switched: MX so the domain can receive, Autodiscover for Outlook, SPF naming Microsoft 365 as a sender, DKIM signing enabled with the selector records the tenant issues, and a DMARC record. Send test messages from the new domain to external mailboxes and read the authentication headers: all three must pass before the pilot batch, not after the first client email lands in junk. SPF, DKIM and DMARC for Microsoft 365: the setup order explains why that order.
Two cautions. A brand-new domain has no sending reputation, so the first days should look like normal personal mail, not a marketing blast. And walking every sending service (marketing platform, CRM, ticketing) to DMARC enforcement is separate, separately scoped work.
Once verified and authenticated, set the new domain as the tenant's default so new accounts are created on it. DNS turnaround drives this phase; book same-day turnaround with whoever applies your DNS changes.
Step 3: swap addresses and sign-in names in batches, and keep the old domain as an alias
The swap is two edits per user: the primary SMTP address (what recipients see in the From line) and the UPN (what the user types to sign in), changed together so they match. The old address is never removed; it becomes a secondary alias on the same mailbox, so mail sent to it keeps arriving for as long as the old domain stays registered and pointed at Microsoft 365. Nothing sent to an old address bounces; the success criterion on our service page is zero messages lost to the change.
Do it in batches, pilot first. A small group including IT and a few tolerant volunteers is switched, and sign-in, Outlook, Teams, OneDrive, mobile devices and inbound mail to the old aliases are verified before the next batch; the pilot confirms the re-sign-in behavior before the whole company experiences it. Exceptions are fine: a salesperson mid-deal keeps the old address as primary and moves later.
Two conditions change the runbook and must be declared at scoping: identities synced from on-premises Active Directory (the UPN change happens on the AD side and syncs up), and mailboxes under litigation hold, journaling or address-keyed archiving.
Step 4: the forgotten objects
Users are the easy part because they complain. The objects that do not are what a rebrand leaves half-done for years:
- Distribution lists and Microsoft 365 groups: new primary address, old one kept as an alias.
- Shared mailboxes and public-facing addresses (info@, sales@, billing@): the same; these are the addresses on your invoices and website.
- Resource mailboxes (rooms, equipment): re-addressed so calendar invitations resolve.
- Devices and applications that send as your domain (printers, scanners, line-of-business systems): sending address updated and covered by SPF for the new domain.
- Teams and SharePoint: team names, channels and site URLs do not change, memberships follow the user objects, and saved links keep working.
The scoping inventory lists every one of these before the first change, and the sweep runs after the user batches so nothing is skipped because it looked done.
Step 5: outside the tenant: apps, devices, signatures and partners
Third-party applications are the least predictable part of any rename, because each vendor decides how identity is keyed. Apps connected through Microsoft Entra single sign-on generally keep working, because Entra identifies the user by an immutable internal ID rather than the email string. Apps where the email address is the username, which is most standalone SaaS, need a per-app change in the vendor's console, sometimes only by the account holder. The checklist dispositions each inventoried app (updated, assigned to an owner, or confirmed unaffected), and the app nobody remembered surfaces on its own schedule, which is why the checklist stays with you after close. Moving an app onto Entra SSO makes the next rename invisible to it; SSO with BambooHR ($475 per project) is one example. App registrations in your own tenant that pass the UPN as a claim need the same review.
Mobile devices and Outlook: users sign in again once; profiles are not rebuilt. Signatures and templates are your marketing project. External partners who allow-list your domain in a mail filter, EDI link or portal (banks, insurers, large customers) need the new domain added; the customer and vendor announcement in the communication kit is where you tell them.
Keep the old domain indefinitely: a registrar fee a year keeps decades of business cards working and stops someone else registering it and receiving your customers' mail; its SPF and DMARC posture is set at close so it cannot be spoofed.
Out of scope: the website and its hosting, moving DNS hosting, device re-enrollment, and Intune or Conditional Access changes. A rename is a good moment for the Free Microsoft 365 Security Assessment (no additional charge, for clients), scoped separately, with what a clean Microsoft tenant should look like in 2026 as the standard.
Frequently asked questions
Will we lose email during the change?
No. Old addresses become aliases on the same mailboxes, so anything sent to them keeps arriving for as long as you keep the old domain; message trace is monitored during the rollout for any NDR attributable to the change.
Do users get new passwords?
No. The sign-in name changes to match the new address; the password, mailbox, files, Teams and MFA setup do not. Users may be prompted once to sign in again.
Can you rename our .onmicrosoft.com name or our SharePoint URL?
The .onmicrosoft.com name cannot be renamed by anyone. The SharePoint URL can, through Microsoft's separate tenant rename operation, which we quote as its own project because of its sync-client and hard-coded-link caveats.
How long does it take, and can we do it over a weekend?
About a week: inventory and DNS on days one and two, a pilot on day three, batches and the sweep on days four and five, then verification. A weekend big bang produces Monday lockouts; batches during business hours are safe because the aliases mean there is no mail outage.
Should we cancel the old domain when it is done?
No. Keep it registered and attached to the tenant indefinitely, with its SPF and DMARC records maintained; a lapsed domain stops old-address mail and can be registered by someone else.
Sources
- IT Partner service page: Microsoft 365 Domain Change and Company Rebranding (content/services/ITPWW670MIGOT - Microsoft 365 Domain Change and Company Rebranding.json): scope, order, exclusions, limitations, price
- IT Partner service pages (content/services/*.json): Entra ID SSO with BambooHR; Free Microsoft 365 Security Assessment (no charge, clients only); Post-Migration Support for Admin; Microsoft 365 Tenant-to-Tenant Cutover Email Migration
- IT Partner blog posts (content/blog/new/): SPF, DKIM and DMARC for Microsoft 365; What a Clean Microsoft Tenant Should Look Like in 2026
- IT Partner engineering notes, September 2026
| Item | What changes | Who does it | When |
|---|---|---|---|
| New domain | Added to the tenant, verified by TXT record, set as default | You register; IT Partner verifies | Days 1 and 2 |
| MX, Autodiscover, SPF, DKIM, DMARC | Published for the new domain; test mail authenticated | IT Partner supplies values; you or your DNS host publish | Days 1 and 2, before any user moves |
| Users | Primary SMTP and UPN swapped; old address kept as alias; same password | IT Partner, in batches | Pilot day 3; batches days 4 and 5 |
| Groups, distribution lists, shared, resource and public-facing mailboxes | New primary address, old one aliased | IT Partner | Days 4 and 5 |
| Devices and apps sending as your domain | Sending address and SPF coverage updated | You, from our list | Days 4 and 5 |
| Teams, SharePoint, OneDrive, .onmicrosoft.com name | No change; memberships follow users | Nobody | Not applicable |
| Third-party SaaS logins | Per-app username change; none if on Entra SSO | App owners with our instructions | Days 4 to 7 and after |
| Mobile devices, Outlook, Teams apps | One re-sign-in per user | Users | After their batch |
| Partner allow-lists, signatures, website | New domain added; your marketing project | You, through the announcement | Announcement date |
| Old domain | Kept indefinitely; SPF and DMARC posture set | You keep it registered; IT Partner sets the records | At close, then for good |
Key takeaways
- The order is fixed: verify the new domain, publish and test MX, Autodiscover, SPF, DKIM and DMARC, set it as default, then swap addresses and UPNs in batches with the old domain kept as an alias.
- Nothing is lost: old addresses become aliases and keep receiving mail for as long as the old domain stays registered, which should be indefinitely.
- Passwords, mailboxes, files, Teams, MFA, the SharePoint URL and the .onmicrosoft.com name do not change; users see one re-sign-in.
- Groups, shared and resource mailboxes, devices that send as your domain and apps keyed to an email address are where renames go wrong; inventory and disposition each before the first change.
- The service is about $1,950 for a typical single-domain change, fixed in writing after scoping; the website, DNS hosting moves, device re-enrollment and Intune or Conditional Access changes are separately scoped.
The Microsoft 365 Domain Change and Company Rebranding service runs this order in about a week, typically $1,950 for a single-domain change, fixed in writing after a short scoping call and paid after you approve delivery. If you want a qualified admin on call while your team works the third-party checklist afterward, Post-Migration Support for Admin is $900 for 30 days.
Questions this article didn’t answer?
Thirty minutes with Mike — our CEO, not a sales rep. Bring the hard version of the question.