The .onmicrosoft.com Free Ride Ended This Month, and Teams Is the Bouncer

The .onmicrosoft.com Free Ride Ended This Month, and Teams Is the Bouncer

A user files a ticket: “I can’t invite our auditor to a Teams meeting anymore. It worked last month.” You check the tenant. Every UPN ends in contoso.onmicrosoft.com. There is no custom domain. There never was. That’s the whole diagnosis.

As of September 2026, Microsoft restricts external collaboration in Teams for tenants running on MOERA alone — the Microsoft Online Email Routing Address, that .onmicrosoft.com service domain every tenant is born with. Office365itpros flagged it this week. The Exchange Online team did the same thing earlier. Now it’s Teams, and the clock is already running.

Is this actually a “block,” or a nudge with teeth?

Both, and the distinction matters for how hard you panic. This isn’t a global kill switch on Teams. Internal chat, meetings, and channels keep working. What gets cut is the cross-tenant surface: guest access (B2B invites into your teams and channels), external access (federated 1:1 chat and calls with other orgs), and shared channels (B2B Direct Connect). Anything that reaches across a tenant boundary needs an identity that resolves to a real, verified domain. MOERA doesn’t count as one.

So if your business runs on external collaboration — client channels, partner shared channels, guest reviewers — that capability is gone for MOERA-only tenants. Not degraded. Off. The word “block” in the headline is accurate; it just applies to a narrower blast radius than “Teams is down.”

Who actually trips over this?

Not many well-run tenants, and that’s the point. To be caught, a tenant has to have never added and verified a custom domain, with every user still on @contoso.onmicrosoft.com. In practice that population is: abandoned trials, test tenants that quietly went into production, dev sandboxes someone started inviting real guests into, and the occasional small org that stood itself up in a hurry and never finished the job.

That last category is the one that bites in six months. MOERA was designed as a bootstrap and fallback address — the thing that keeps you signed in while DNS propagates. It was never meant to carry production user identities. A tenant still living on it is, from Microsoft’s side, indistinguishable from an abuse or spam vector. Restricting that cohort cuts fraud and support load. Hard to argue with the logic, even while you’re the one holding the ticket.

What actually fixes it — and where admins stop too early

Two steps. Adding the domain is the one everyone does. Migrating the UPNs is the one that gets skipped, and skipping it means you fixed nothing.

First, verify a custom domain. In the Microsoft Entra admin center: Identity > Settings > Domain names > Add custom domain. Add contoso.com, then prove ownership with the TXT record Microsoft hands you. Confirm the current state before you touch anything:

audit.ps1PowerShell
Connect-MgGraph -Scopes "Domain.Read.All","User.ReadWrite.All"
​
try {
    Get-MgDomain -All -ErrorAction Stop |
        Select-Object Id, IsVerified, IsDefault |
        Format-Table -AutoSize
}
catch {
    Write-Error "Failed to read domains: $($_.Exception.Message)"
}

If the only IsVerified row is your .onmicrosoft.com, you’re in the affected group. Verifying the domain alone does not lift the restriction — the user identities still resolve to MOERA. You have to move the UPNs.

Do not pipe a live Get-MgUser straight into a bulk update. Export, eyeball it, then act on the reviewed file. Build a CSV with Id and the intended NewUserPrincipalName, review it, then:

audit.ps1PowerShell
# Runs as a dry run by default. Add -Execute only after reviewing upn-migration.csv
param([switch]$Execute)
​
$users = Import-Csv -Path ".\upn-migration.csv"
​
foreach ($u in $users) {
    try {
        if ($Execute) {
            Update-MgUser -UserId $u.Id `
                -UserPrincipalName $u.NewUserPrincipalName -ErrorAction Stop
            Write-Host "Updated $($u.Id) -> $($u.NewUserPrincipalName)"
        }
        else {
            Write-Host "[WhatIf] $($u.Id) -> $($u.NewUserPrincipalName)"
        }
    }
    catch {
        Write-Warning "Failed $($u.Id): $($_.Exception.Message)"
    }
}

A UPN change is not cosmetic. It’s the user’s sign-in name and it ripples into cached credentials, saved sign-ins, and anything keyed on the old address. Pilot it on a handful of accounts, warn people, and expect a round of re-authentication. Synced from on-prem AD? The UPN change belongs upstream in AD, not in the cloud, or Entra Connect will fight you.

The verdict

The headline says Teams is blocking external collaboration. The precise version: Teams is enforcing something that was always true — MOERA is not a production identity domain, and it never was. This isn’t a new limitation landing on healthy tenants. It’s Microsoft finally charging rent on a shortcut that was quietly overdue. If a verified custom domain is a surprise to you in September 2026, external Teams collaboration isn’t your only exposure — it’s just the first one to send a ticket.

Related Post