---
service: "Publicasta"
schema_version: "1.0"
article_id: 610
title: "Microsoft Teams is moving its web client to teams.cloud.microsoft: the network checks IT teams need now"
language: "en"
default_language: "en"
canonical_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=en"
json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=en"
api_url: "https://publicasta.com/api/public/v1/channels/it_today_news/articles/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=en"
channel_url: "https://publicasta.com/api/public/v1/channels/it_today_news"
channel_articles: "https://publicasta.com/api/public/v1/channels/it_today_news/articles"
search_url: "https://publicasta.com/api/public/v1/search"
documentation_url: "https://publicasta.com/api-docs#reading-publicasta"
openapi_url: "https://publicasta.com/api-docs/openapi.json"
published_at: "2026-09-14T14:11:27+00:00"
updated_at: "2026-09-14T14:11:27+00:00"
translations:
  - language: "ar"
    html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=ar"
    markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=ar"
    json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=ar"
  - language: "de"
    html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=de"
    markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=de"
    json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=de"
  - language: "en"
    html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=en"
    markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=en"
    json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=en"
  - language: "es"
    html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=es"
    markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=es"
    json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=es"
  - language: "fr"
    html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=fr"
    markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=fr"
    json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=fr"
  - language: "pl"
    html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=pl"
    markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=pl"
    json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=pl"
  - language: "ru"
    html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=ru"
    markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=ru"
    json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=ru"
  - language: "zh"
    html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=zh"
    markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=zh"
    json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=zh"
---

# Microsoft Teams is moving its web client to teams.cloud.microsoft: the network checks IT teams need now

> Microsoft’s September Teams web redirect is a small URL change with a large operational edge. Firewalls, proxies, browser policies, embedded apps, CSP rules and runbooks can all turn a harmless redirect into a help-desk incident.

Microsoft is changing the address of the Teams web client. During September 2026, users who open `teams.microsoft.com` may be redirected to `teams.cloud.microsoft`. Microsoft describes this as a domain change, not a feature migration: existing links and bookmarks are expected to continue working, and end users do not need to install a new client.

 ![Editorial illustration of a browser redirect through enterprise firewall, DNS, proxy and embedded-app checks.](https://publicasta.com/storage/projects/17/pages/610/2026/09/fb6a5668-f4dd-4a25-b9b1-c88a15dfa7ae.webp)

 That sounds routine until the request passes through an enterprise proxy, secure web gateway, DNS policy, browser allowlist, content-security policy, application manifest or remote-access control. In those environments, a redirect is not automatically harmless. The browser must be able to resolve and reach the destination, the security stack must permit it, and embedded Teams applications must recognize the new origin.

 The immediate advice is straightforward: treat `teams.cloud.microsoft` as a production endpoint, check the Microsoft 365 endpoint data used by your organization, and test the complete web experience before users discover the change through a failed sign-in or a blank tab. The useful lesson is broader than Teams. SaaS URL changes belong in endpoint management and change control, even when the vendor says that no product functionality is changing.

 ## What Microsoft is changing

 Microsoft’s Message Center notice MC1465764 says Teams web users will be redirected from `teams.microsoft.com` to `teams.cloud.microsoft` by September 2026. The notice labels the change as a major change with administrator impact. The destination uses Microsoft’s broader `cloud.microsoft` domain family, which Microsoft introduced for authenticated, user-facing Microsoft 365 experiences.

 The migration is not presented as a new Teams client or a new account system. A person using the browser should still reach the same service, with the same conversations, meetings, files and organization context. The visible difference is the address in the browser, plus the network and web-application behavior that follows from that address.

 Microsoft says the old URL will redirect and that existing links will continue to work. That reduces disruption for ordinary users, but it does not eliminate the need for administrative testing. A bookmark can follow an HTTP redirect; a tightly managed proxy may evaluate the first and second hostnames separately. A browser can load the page while an embedded tab fails because its `frame-ancestors` policy has not been updated. A firewall may allow `teams.microsoft.com` but reject `*.cloud.microsoft`.

 The Message Center notice also says that a temporary administrator control can disable the redirect, but that control ends on December 31, 2026. It is therefore a migration aid, not a durable operating model. Organizations that use it should record the exception, assign an owner and plan its removal.

 Microsoft’s public endpoint documentation already lists both `*.teams.microsoft.com` and `*.teams.cloud.microsoft` for Teams, alongside `teams.microsoft.com` and `teams.cloud.microsoft`. The same documentation lists `*.cloud.microsoft` as a required unified-domain endpoint for authenticated Microsoft 365 experiences. The practical implication is important: an organization should update its source-of-truth endpoint process, not just add one hostname to one firewall rule.

 ## Why a redirect can become an outage

 A redirect crosses several control points. Each one can create a different symptom, and the symptom may appear to users as “Teams is down” even when Microsoft’s service is healthy.

 ### Firewalls and secure web gateways

 Traditional allowlists often contain named hostnames. If the policy permits `teams.microsoft.com` but not `teams.cloud.microsoft`, the first request may succeed and the redirected request may be blocked. Depending on the gateway, users may see an access-denied page, a timeout, an authentication loop or an incomplete application shell.

 Some organizations use category-based filtering, TLS inspection or explicit proxy routing. Those controls may rely on certificate names, URL categories or rules that were written around the old domain. The new host needs to be evaluated under the same intended policy. Adding a broad wildcard without reviewing how the gateway handles it can create unnecessary exposure; refusing the wildcard without understanding Microsoft’s endpoint guidance can create brittle operations. The right decision depends on the organization’s control model, but it should be deliberate and documented.

 ### DNS and split-network behavior

 A new hostname also enters DNS workflows. Internal resolvers, filtering services, secure DNS products and remote-access clients may apply different policy to a newly observed domain. Test from office networks, VPN-connected devices, home-working scenarios and any managed virtual desktop environment. A successful test from an administrator’s laptop is not evidence that every egress path will behave the same way.

 Do not hard-code an IP address for this change. Microsoft’s endpoint guidance is expressed in terms of service domains and published address data, and cloud services can change their underlying infrastructure. An IP-based workaround may fail during a normal service change and can bypass the intent of hostname-based controls.

 ### Browser trust and cookie policies

 Teams web access depends on browser behavior as well as network reachability. Microsoft’s troubleshooting guidance for Teams identifies `*.cloud.microsoft` among the domains that may need to be trusted when browser controls restrict cookies or trusted sites. Organizations that block third-party cookies, enforce browser site lists or deploy group policies should test sign-in, meeting launch and navigation after the redirect.

 A domain exception should be scoped to the required Microsoft services and governed through the same review process as other authentication-related exceptions. Avoid turning off a browser privacy control globally just to make one test pass. First identify whether the issue is cookie scope, a trusted-site policy, TLS inspection, a proxy rule or a blocked endpoint.

 ### Embedded Teams apps and tabs

 Teams is also a host for applications. A custom tab, line-of-business tool or partner app may be loaded inside the Teams web client rather than opened as a top-level page. In that situation, the new host changes the browser origin and can expose assumptions that were invisible under the old address.

 Microsoft’s Teams developer guidance says application owners should update the Teams JavaScript library to version 2.19.0 or later and initialize the app for the new host. It also says that applications using Content Security Policy headers should include `*.cloud.microsoft` in the `frame-ancestors` directive while retaining the existing values for backward compatibility during migration.

 This is not a reason to change every security header indiscriminately. It is a reason to review the header against the actual supported host list, test the app in the Teams web client, and verify that any origin validation, `validDomains` entries, cookie settings and postMessage handling still match the intended application flow.

 A common failure pattern is partial success: the Teams shell loads, but a tab shows a blank frame; the tab opens, but file selection fails; or authentication returns to the application with no usable session. Record the host visible in the browser and the host that appears in network traces before changing application code.

 ## Who is affected

 The primary affected group is organizations that use Teams in a browser and control outbound access through firewalls, proxies, secure web gateways, DNS filters or managed browser policy. The change is less visible to people who use only the desktop or mobile client, although links, authentication handoffs and embedded experiences can still involve browser components.

 Teams application owners are a second group. This includes internal developers, software vendors, intranet teams and departments that maintain tabs, message extensions, websites embedded in Teams or integrations that validate the Teams origin. Their risk is not limited to the initial redirect. A new host can affect frame policies, origin checks, redirect URI assumptions, cookie attributes, telemetry filters and support documentation.

 Network and identity teams should also be involved. They often own different pieces of the path: the network team manages egress, the endpoint team manages browser policy, the identity team manages sign-in controls, and the application team manages embedded content. A change that crosses all four owners can fall between queues unless someone treats it as one service change.

 Small organizations are not automatically exempt. A small company may have no complex proxy, but it may rely on a managed firewall, an outsourced IT provider or a browser policy inherited from a parent organization. The simplest environments should test quickly rather than assume that simplicity guarantees compatibility.

 ## The endpoint details that matter

 Microsoft’s Microsoft 365 URL and IP address documentation says required endpoints should be reachable and identifies `*.cloud.microsoft` as a required unified-domain destination over TCP 443 and UDP 443. In the Teams section, it lists `*.teams.cloud.microsoft`, `*.teams.microsoft.com`, `teams.cloud.microsoft` and `teams.microsoft.com`, with TCP 443 and 80 and UDP 443.

 Those entries are more useful than copying a list from a forum post because Microsoft updates the endpoint data as its service changes. The documentation says endpoint data is normally published in advance, while updates may also occur during the month for support escalations, security incidents or other immediate operational requirements. That is a strong argument for automating the organization’s endpoint feed where its security tools support it.

 It is also a reminder that endpoint categories matter. Microsoft distinguishes required, optional and default destinations and explains that a feature can depend on endpoints across workload groups. A team that simply searches for “Teams” in a static list may miss a common authentication or content endpoint required by the complete experience.

 The safe operational sequence is to compare the current Microsoft endpoint data with the organization’s actual control layers, then test the result. Do not assume that a single allowlist in the perimeter firewall represents the whole policy. A cloud access security broker, endpoint agent, browser configuration, private DNS zone or VPN split-tunnel rule may still block the new host.

 ## A practical validation plan

 ### 1. Identify the real users and paths

 Start with an inventory, not a rule change. Determine which user groups open Teams in a browser, which groups use virtual desktops, which users connect through VPN, and whether contractors or managed service providers use separate egress paths. Include shared workstations, kiosk-style devices and meeting-room systems if they launch browser-based Teams links.

 Record the controls applied to each path: DNS filtering, proxy, TLS inspection, firewall, secure web gateway, browser policy, endpoint security and identity conditional-access policy. This map makes it easier to distinguish a service issue from a local policy issue later.

 ### 2. Review the organization’s endpoint source

 Use Microsoft’s current Microsoft 365 endpoint documentation and, where possible, its downloadable or web-service data rather than relying on a locally maintained spreadsheet. Confirm that the required unified-domain entries and Teams entries are represented in the systems that actually enforce access.

 If the organization intentionally permits only specific FQDNs, decide whether `teams.cloud.microsoft` is sufficient for the present Teams web redirect or whether the documented wildcard is needed for the organization’s broader Microsoft 365 usage. Make the choice with the security owner. A wildcard can simplify maintenance, while individual hostnames can provide tighter scope but demand more frequent maintenance.

 ### 3. Test the redirect itself

 From each representative network path, open the old Teams URL and observe the full chain. Confirm that the request reaches `teams.cloud.microsoft`, that the certificate is accepted, that authentication completes and that the application finishes loading. Test a normal user account as well as an administrator account; privileged accounts can have different policy and cached state.

 Use browser developer tools or gateway logs to record blocked requests, status codes and policy decisions. The goal is not to collect a huge packet capture. It is to answer four concrete questions: did DNS resolve, did the connection pass, did the redirect complete, and did the application load all required resources?

 Clear cached site data only after recording the first result. Cache clearing can hide a reproducible migration problem or create a false failure that ordinary users will not experience. Run at least one test with a clean profile and one with the managed production profile.

 ### 4. Test user actions, not only the landing page

 A green sign-in screen is not enough. Validate the actions that matter to the organization: open a chat, join a meeting, start a call if enabled, open a shared file, switch tenants if applicable, load a custom tab and use any approved Teams integration. Test both a direct browser bookmark and a link received from an email or calendar invitation.

 For meetings, test the path from a calendar link because the browser may pass through additional redirect and authentication steps. For files, test opening and editing a representative document if that workflow is important. For custom applications, test each business-critical tab and the sign-in return path.

 ### 5. Check embedded application policies

 Application owners should search source code and configuration for hard-coded references to `teams.microsoft.com`, explicit origin comparisons, CSP `frame-ancestors` values, trusted-domain lists, redirect URIs, cookie domain assumptions and telemetry filters. The search should include deployment configuration and documentation, not only application code.

 Follow Microsoft’s Teams app guidance for the TeamsJS version and initialization behavior. Retain old host values when backward compatibility is required, and add the new host according to the application’s security model. Do not replace old values blindly if users can still arrive through the old URL or if other Microsoft 365 hosts remain supported.

 After changing headers or manifests, test in every supported host context. A CSP that works in a top-level browser tab may still reject an embedded frame. Conversely, a permissive test header may conceal that the production response is generated by a different reverse proxy or CDN.

 ### 6. Update operational material

 Search help-desk articles, onboarding guides, firewall request forms, proxy policies, browser policies, monitoring checks and incident runbooks for the old Teams hostname. Keep the old URL in historical notes where useful, but describe it as a redirect source rather than the only service address.

 Monitoring should also be updated. A synthetic check that asserts the final hostname may start failing even though the service is healthy if it was written for the old address. A check that follows redirects and verifies the final page is more representative, provided it also alerts when the redirect chain changes unexpectedly.

 ## What not to do

 Do not tell users to bypass the proxy, disable browser protections or use an unmanaged device as the standard fix. Those actions can hide the policy problem and create a second security issue.

 Do not disable the redirect permanently just because an application team has not tested its tab. The temporary administrator control has an expiry date, and postponing the work turns a controlled change into a deadline incident. Use the control only when it is necessary to protect service continuity while a specific remediation is scheduled.

 Do not replace hostname rules with fixed IP addresses. Microsoft’s cloud infrastructure is designed to evolve, and an IP workaround can become stale or route traffic incorrectly.

 Do not allow every `*.microsoft` destination without review. The relevant Microsoft documentation identifies specific domain families and endpoint categories; broadening access beyond the business requirement weakens the value of the control.

 Do not treat an HTTP 200 response from the first page as proof that Teams works. The failure may occur after authentication, during an API call, while loading a tab or when opening a file.

 ## How to handle the temporary exception

 Microsoft’s notice says the administrator control for disabling the Teams redirect ends on December 31, 2026. If an organization uses it, the exception should have a clear reason and a named owner. A useful record includes the affected tenant or user group, the blocked dependency, the responsible application or network team, the target test date and the date when the exception will be removed.

 The exception should not become a substitute for endpoint maintenance. If the problem is a proxy rule, fix the proxy rule. If the problem is a custom tab’s CSP, fix the application response. If the issue is a third-party integration, ask its owner for a supported migration path and document the answer.

 Where a business-critical application cannot be validated in time, separate the risk. Keep the exception as narrow as the available control allows, monitor the affected workflow and communicate the end date to the service owner. The goal is to preserve continuity while keeping the migration visible.

 ## Why this is an infrastructure change

 A SaaS provider can change a hostname without changing the user-facing feature. For the customer, however, a hostname is part of the service contract enforced by networks, browsers and applications. The address determines which policy matches, which certificate is inspected, which cookies are sent, which origin is trusted and which logs identify the traffic.

 That is why domain migrations deserve the same lightweight discipline as other production changes. There should be an owner, a test matrix, a rollback or mitigation plan, a monitoring update and a communication path. The work does not need a large project. It does need someone to verify the entire path rather than assume that a redirect will be transparent everywhere.

 The change also illustrates a shift in cloud operations. Service endpoints are no longer a static appendix maintained once during deployment. Microsoft says its endpoint data changes as services evolve and can be updated outside the normal cadence when operational circumstances require it. Organizations that consume endpoint data automatically can reduce manual delay, but automation still needs review: a feed can update a firewall while the application’s CSP and runbook remain unchanged.

 ## A concise checklist for September

 - Confirm whether browser-based Teams is used in the organization.
- Review MC1465764 in the Microsoft 365 admin center and identify the tenant’s rollout status.
- Confirm that `teams.cloud.microsoft` and the relevant `*.cloud.microsoft` endpoints are permitted by the documented network policy.
- Test from office, VPN, remote, virtual-desktop and managed-browser paths.
- Follow the redirect and verify sign-in, meetings, files and critical Teams tabs.
- Review DNS filtering, proxy rules, TLS inspection and browser trust or cookie policies.
- Ask application owners to check TeamsJS, CSP `frame-ancestors`, origin validation, manifests and redirect URIs.
- Update synthetic monitoring, documentation and help-desk guidance.
- Record any temporary redirect exception with an owner and removal date before December 31, 2026.

 Microsoft’s Teams web migration is easy for an unmanaged browser and potentially consequential for a managed enterprise. The right response is not a broad emergency firewall change. It is a short, evidence-based validation of the new endpoint across the real paths users and applications take. Once that work is complete, the redirect should become what Microsoft intends: a change in address, not a change in availability.