Microsoft 365 Domain Change and Company Rebranding
Microsoft 365 Domain Change and Company Rebranding is a one-week engagement that moves your organization's email and sign-in identity from the old company domain to the new one without losing a single message: the new domain added and verified in your tenant, SPF, DKIM, and DMARC issued for it, primary email addresses swapped in controlled batches with every old address kept as a working alias, user sign-in names (UPNs) changed in Microsoft Entra ID, a checklist-driven pass through the third-party apps that use email addresses as logins, and communication templates so customers and vendors hear about the change from you — not from a bounced email. Mail sent to the old addresses keeps arriving for as long as you keep the old domain, which we recommend you do.
What this engagement is
A company rename looks like a marketing project until someone asks when the email addresses change — and then it becomes an identity project with several hundred moving parts. Changing the email domain in Microsoft 365 touches every mailbox, every sign-in name, every distribution list and shared mailbox, the DNS records that keep your mail out of junk folders, and — the part most rename projects discover late — every third-party app where the login is an email address. Done as one big-bang change on a Friday night, it produces Monday-morning lockouts. Done in stages, with aliases retained and sign-ins changed in verified batches, it is a low-drama week. That staged approach is this engagement. We add and verify the new domain in your tenant and publish its DNS: MX, autodiscover, SPF, DKIM signing, and a DMARC record, so the very first message from the new addresses authenticates properly instead of landing in spam during your most visible week. Then we swap primary SMTP addresses in controlled batches — pilot group first — while keeping every old address as a working alias, which means nothing sent to the old addresses ever bounces. Sign-in names (UPNs) change in Microsoft Entra ID in the same batches, with users told exactly what to expect: same password, new sign-in name, a possible one-time re-sign-in on Outlook, Teams, and OneDrive. Groups, shared mailboxes, resource calendars, and public-facing addresses are swept in a dedicated pass, because they are the ones everyone forgets. Two honest boundaries, stated up front. First, your tenant's original *.onmicrosoft.com name is permanent — Microsoft provides no way to rename it, for anyone. It is internal plumbing your customers never see, and this engagement changes everything they do see. (The contoso.sharepoint.com URL is a separate Microsoft rename operation with its own risks and caveats — see the FAQ.) Second, we change your identity, not your brand: logos, templates, websites, and stationery are your marketing project; we make sure email and sign-in are ready when it launches. A typical single-domain change runs about $1,950; the final quote is fixed in writing after a short scoping call, because mailbox count and the depth of your third-party app inventory are what move the effort. If your rebrand is actually a merger, acquisition, or split — where people need to land in a different tenant, not just a different domain — that is tenant-to-tenant migration, and we will tell you so at scoping rather than force this scope to fit.
Success criteria
What you receive
How the work unfolds
Scoping inventory confirmed, new domain verified in the tenant, DNS published, DKIM enabled and verified, DMARC issued. Test mailboxes send from the new domain to external systems and we read the authentication headers before anyone else is touched. Batch plan and communication templates approved.
A small pilot group (typically including IT and a few tolerant volunteers) gets the primary SMTP swap and UPN change. We verify sign-in, Outlook, Teams, OneDrive, mobile devices, and inbound mail to old aliases, and adjust the runbook with anything the pilot teaches us.
Remaining batches switched with verification between each. Distribution lists, groups, shared and resource mailboxes, and public-facing addresses re-addressed. The third-party app checklist is worked: apps we can update are updated; apps needing their owner get a named owner and instructions.
End-to-end verification: authentication passing from new addresses, old aliases still delivering, no stray NDRs in message trace. Your customer/vendor announcement goes out on your schedule with our templates. As-built documentation delivered, old-domain posture agreed, open third-party items handed off with owners.
Prerequisites
Who does what
IT Partner
- Run scoping, build the inventory, and produce the batch plan and runbook.
- Verify the new domain and publish or hand off all DNS records; enable and verify DKIM; issue DMARC for the new domain.
- Execute the primary SMTP swaps and Entra ID UPN changes batch-by-batch, with verification and a rollback path at each step.
- Re-address groups, shared mailboxes, resource mailboxes, and public-facing addresses per the approved inventory.
- Work the third-party checklist for apps we are given access to, and deliver per-app instructions for the rest.
- Provide the communication kit and advise on sequencing the announcement.
- Monitor message trace during the rollout for NDRs attributable to the change, and fix same-day.
- Deliver the as-built documentation and the old-domain posture recommendation.
Your team
- Confirm the user list, exceptions, and batch timing; approve the plan before the first change.
- Apply DNS changes same-day if you keep DNS access in-house.
- Communicate with staff using the provided templates, and ensure users complete their one-time re-sign-ins after their batch.
- Update third-party apps we do not have credentials for, using the per-app instructions, and report completion so the checklist closes.
- Send the customer/vendor announcement on your chosen date.
- Keep the old domain registered and its DNS intact for as long as old addresses should keep receiving mail.
- Own trademark, legal-entity, and brand aspects of the rename — we change the technical identity only.
- Review deliverables and approve acceptance against the published success criteria.
What's not included
Limitations & technical notes
Frequently asked questions
Will we lose email during the change?
No — and not because of luck, but because of aliases. Your old addresses are never removed; they become secondary addresses on the same mailboxes, so mail sent to them keeps delivering exactly as before, indefinitely, as long as you keep the old domain. The change swaps which address is primary — what recipients see in the From line — in verified batches. Message trace is monitored throughout, and the success criterion is written into this page: zero messages lost to the swap.
Do users get new passwords? What actually changes for them?
Passwords do not change. What changes: the name they sign in with (new UPN, which matches their new email address) and their From address. What they may notice: a one-time prompt to sign in again in Outlook, Teams, OneDrive, and phone apps after their batch. What does not change: mailbox contents, folders, rules, OneDrive files, Teams chats and memberships, and their MFA setup. Each batch gets a one-page what-to-expect note from the comms kit before their switch day.
Can you rename our onmicrosoft.com tenant name too?
No — nobody can. The tenant's original *.onmicrosoft.com domain is assigned at creation and Microsoft provides no way to rename it, at any license level or price. We would rather tell you that in the second sentence than have you discover it mid-project. The practical reality: it is internal plumbing — your customers see your email domain, your sign-in names, and your SharePoint links, and this engagement changes the ones that matter. If the internal name is truly intolerable, the only genuine fix is a migration to a fresh tenant, which is a much larger project we can scope honestly if it is worth it to you.
What about our SharePoint links — files still say oldcompany.sharepoint.com?
That is a real Microsoft capability, separate from this engagement: SharePoint tenant rename can change contoso.sharepoint.com to newco.sharepoint.com (it requires adding a new onmicrosoft.com domain first, and Microsoft's standard process covers tenants up to 10,000 total sites, with an advanced path beyond that). We keep it out of the base scope deliberately: it re-links every OneDrive sync client, can break hard-coded links in documents and third-party integrations, and Microsoft redirects the old URLs only for a period. For many companies the old SharePoint URL is a tolerable leftover; for some it is not. If it matters to you, we scope and quote it as its own project with the risks in writing.
Will the new addresses land in spam? Our rebrand week is exactly the wrong time for that.
This is why authentication comes first in the plan, not last. Before any user is switched, the new domain has SPF published, DKIM signing enabled and verified, and a DMARC record issued — and we send test mail to external systems and read the authentication headers to prove it passes. One nuance worth knowing: a brand-new domain has no sending reputation yet, so the first days benefit from normal, personal mail patterns rather than a mass blast. If you also send bulk mail (marketing platforms, CRM), walking every sending service to DMARC enforcement is the separate email authentication engagement — the rebrand is a natural moment to do both.
What happens to all the apps our staff log into with their email address?
They split into two families. Apps connected through Microsoft Entra single sign-on generally keep working, because Entra identifies users by an immutable internal ID rather than the email string — we verify rather than assume. Apps where the email address is the username (most standalone SaaS) need a per-app change, usually in the app's admin console or the user's profile settings. The scoping inventory lists them, the checklist dispositions each one — updated by us, assigned to your app owner with instructions, or confirmed unaffected — and the honest caveat is that the app nobody remembered will surface later, which is why the checklist format is built for your team to keep using.
Can everyone keep the old address too? Some customers will use it for years.
Yes — that is the default, not an option. Every old address remains as a working alias forever (well: for as long as you keep the old domain registered). Replies and new mail go out from the new address; anything sent to the old one still arrives. You can also designate exceptions who keep the old address as primary for a transition period — sales people mid-deal, for instance — and switch them in a later batch on their own schedule.
Should we just cancel the old domain once this is done?
Please don't — and we say that with feeling. Keep it registered: it costs a registrar fee per year, keeps decades of business cards and address books working, and prevents the genuinely ugly scenario where the domain lapses, someone else registers it, and starts receiving mail your customers still send to it. Part of the close-out is setting the old domain's posture deliberately — it stays attached to your tenant receiving mail, with its authentication records maintained so it cannot be spoofed against you.
How long does this take, and can we do it over a weekend?
About a week for a typical single-domain change — and the week is a feature, not padding. A big-bang weekend cutover is exactly how rename projects generate Monday lockouts: every user re-signing in at 8 a.m., every problem at once, no pilot data. The staged plan switches a pilot first, learns from it, then moves batches with verification between — during business hours, because the alias mechanics mean there is no mail outage to hide from. The public announcement is the thing to schedule deliberately, and the plan sequences the technical work so email is ready before marketing pushes send.
We're actually merging with another company — same problem, right?
Related, but bigger, and worth naming precisely. If everyone stays in the same tenant and only the domain changes, this engagement is the right size. If people, mailboxes, and files need to end up in a different tenant — merger, acquisition, divestiture — that is tenant-to-tenant migration, which moves data between tenants and often includes a domain change as one of its steps. The scoping call sorts this in ten minutes, and it is much cheaper to pick the right project before it starts.
What does it cost, exactly?
A typical single-domain change runs about $1,950. We quote the exact figure fixed, in writing, after a short scoping call — mailbox count, hybrid identity, multiple retiring domains, and the depth of your third-party app list are what move the number — and you pay after you approve delivery. Domain registration fees and any third-party vendor charges stay yours; there are no per-mailbox surprises after the quote.