Microsoft started redirecting web access to Microsoft 365 from m365.cloud.microsoft to copilot.cloud.microsoft on September 1, 2026. If your organization already allows the recommended Copilot network configuration, this is invisible — users land on the new URL and keep working. If your proxy, firewall, or security gateway only ever allow-listed the old address, your users are about to find out the hard way, sometime between now and the second wave in October.
Microsoft flagged this as Admin Impact: High in the Message Center, and it’s easy to see why. A blocked redirect doesn’t produce a clean error pointing at DNS or a firewall rule — from the user’s side, Microsoft 365 on the web just stops loading.
What is MC1462915 and what does it actually say?
The Message Center post is MC1462915, itself a follow-up to an earlier notice, MC1454108, that laid out the same change. The rollout runs in two phases:
- September 1–30, 2026: users in organizations where copilot.cloud.microsoft is already reachable get redirected automatically.
- Starting in October 2026: organizations that are currently blocking the domain get redirected regardless, whether or not they’ve fixed their network configuration by then.
In other words, waiting this out isn’t an option. Every tenant ends up on the new domain either way — the only choice is whether your users hit that transition cleanly or during an outage you’re troubleshooting live.
What to actually check — and the part that’s easy to get wrong
Reviewing proxy, firewall, and gateway rules for copilot.cloud.microsoft specifically is the obvious step, and it’s the one most coverage of this change stops at. Microsoft’s own guidance goes a step further: it explicitly does not support allow-listing individual URLs within the *.cloud.microsoft domain. If your rule set only opens the door for copilot.cloud.microsoft by name, you’re one future rename away from doing this exact exercise again. Allow the wildcard, *.cloud.microsoft, not the specific hostname of the week.
If your organization already followed Microsoft’s published network guidance for Microsoft 365 Copilot — meaning *.cloud.microsoft was already open — there’s nothing left to do here. This redirect stays inside a domain you’ve already cleared.
Once you’ve checked the rule set, confirm it from the client side rather than trusting the config alone. The Microsoft 365 network connectivity test tool, at connectivity.office.com, runs from an actual endpoint and reports what it can and can’t reach, including SSL inspection and proxy detection along the path — useful for catching a rule that looks right on paper but isn’t what’s actually being enforced at the edge.
If you’re blocking the domain on purpose
Some organizations block copilot.cloud.microsoft deliberately, specifically to stop employees from signing into Copilot with a personal Microsoft account. That’s a reasonable goal, but blocking the domain outright is the wrong tool for it once Microsoft 365 itself lives at that address — you’d be taking down a core productivity service to control sign-in behavior on one feature of it.
Microsoft’s recommendation is Tenant Restrictions instead. Rather than blocking the domain, Tenant Restrictions controls which account types are allowed to authenticate against it, so employees can still reach Microsoft 365 and Copilot with their work account while personal Microsoft account sign-in gets rejected at the identity layer. That’s a narrower, more durable control than a domain block that’s now in direct conflict with where Microsoft 365 itself lives.
Don’t stop at the network layer
Firewall and proxy rules are the part that breaks loudly, but they’re not the only place the old domain is hiding. Check any SSO application definitions, browser homepage policies, or internal documentation that hardcode m365.cloud.microsoft rather than pointing users to office.com or microsoft365.com, which will keep redirecting correctly regardless of which backend domain Microsoft uses this month. If any Conditional Access named locations or Cloud App Security policies reference the specific hostname instead of the broader Microsoft 365 app identifiers, this is also a reasonable time to confirm they still match what you think they match.
Part of a pattern, not a one-off
This isn’t the first cloud.microsoft rename this year — Teams went through the same move to a cloud.microsoft-based address recently, flagged the same way in the Message Center with the same admin-action recommendation. Microsoft hasn’t given a detailed technical or strategic reason for consolidating Microsoft 365 under a Copilot-branded domain specifically, beyond the general move toward putting more of its productivity surface under the unified cloud.microsoft namespace. Whatever the branding rationale, the operational lesson is the same one as last time: allow-list the domain family, not the individual hostname, or you’ll be back here again the next time Microsoft renames something under it.
If you haven’t checked your rules yet, do it before the October cutover rather than after — this is a case where being on the calendar early is strictly better than finding out from a help desk queue.
Read More: Windows 11 25H2 and 26H2: What Is Actually Changing?
Frequently Asked Questions
Do I need to do anything if copilot.cloud.microsoft is already accessible on my network?
No. If your organization already follows Microsoft’s recommended network configuration for Copilot, meaning *.cloud.microsoft is allowed, this redirect requires no additional changes.
What happens if we don’t update our firewall before October?
Microsoft redirects your users to copilot.cloud.microsoft regardless, starting in October, whether or not your network is configured to allow it. Unprepared organizations will see Microsoft 365 web access fail at that point, not avoid the change.
Can we just allow copilot.cloud.microsoft specifically instead of the whole domain?
Microsoft explicitly doesn’t support that. Allow the full *.cloud.microsoft wildcard — partial allow-listing within that domain isn’t a supported configuration and risks future breakage.
How do we block personal Microsoft account sign-in without blocking Microsoft 365 itself?
Use Tenant Restrictions to control which account types can authenticate, rather than blocking the domain outright.
Where can we verify whether our network actually allows the new domain?
Run the Microsoft 365 network connectivity test at connectivity.office.com from an affected location — it tests real connectivity rather than just confirming the rule exists on paper.
References
Microsoft — Microsoft 365 Network Connectivity Test Tool https://learn.microsoft.com/en-us/microsoft-365/enterprise/office-365-network-mac-perf-onboarding-tool
Microsoft — Microsoft 365 URLs and IP Address Ranges https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges
M365 Admin (Message Center coverage) — MC1462915: Allow Connections to copilot.cloud.microsoft Before the Copilot URL Redirect https://m365admin.handsontek.net/allow-connections-copilot-cloud-microsoft-copilot-url-redirect/
