A Teams message from an external tenant, a contact posing as the helpdesk, a request to open Quick Assist: the scenario analyzed by Microsoft Threat Intelligence on September 2, 2026 relies on a setting that Teams leaves open by default. This article shows how to switch to a domain allow list, seed it from your Microsoft Entra ID guests and validate the behavior in a test tenant before production.
Why open external access by default benefits fake IT support
By default, Teams allows all external domains, as the Microsoft Learn documentation states. An attacker only has to create a tenant, contact your users and pose as IT or the helpdesk. In the intrusions described by Microsoft Threat Intelligence, they then push the victim to open Quick Assist or to accept a remote control request.
Teams does display safeguards: external tenant label, Accept/Block prompt, message preview. But they only work if the user does not bypass them. Tony Redmond, MVP, reaches the same conclusion: warnings are not enough, since the user can still accept the connection. He recommends an allow list rather than open access, at the cost of maintaining it.
December 2024
MVP opinion on federated chat
Tony Redmond argues for an allow list against brand impersonation in federated chat.
November 2025
Teams vishing campaign discovered
Microsoft's DART team discovers a campaign where the attacker impersonates IT support.
March 16, 2026
DART report
Microsoft recommends an allow list model limited to trusted external domains and restricting inbound unmanaged Teams accounts.
September 2, 2026
Microsoft Threat Intelligence analysis
Detailed attack chain, from the fake support request to enterprise-wide access.
This setting is part of a broader set of controls: our Teams Security Baseline 2026 guide places it among the other modern attack vectors.
How Teams filters external domains
External access is configured per domain, in three modes. The mode you choose also determines what your security team can do in Microsoft Defender.
| Mode | Behavior | Management via Defender (Tenant Allow/Block List) | Maintenance effort |
|---|---|---|---|
| Allow all external domains | All domains are allowed (default value) | Compatible | None, but no barrier |
| Block only specific domains | Only the listed domains are blocked | Compatible | Block list to be fed as incidents occur |
| Allow only specific external domains | All domains are blocked except those on the list | Not compatible | Allow list to keep up to date |
Three mechanisms are worth understanding before you switch.
- External access is bilateral. The partner must also allow your domain and enable external access for its users, otherwise the chat fails. A domain added on your side is not enough.
- Granular policies exist. They allow different lists per user or group (finance, executives, IT support). A custom policy assigned to a user takes precedence over the organization settings, and the "Manage external domains for this organization" setting must be enabled at the organization level.
- Defender management has a licensing prerequisite. The Tenant Allow/Block List requires Defender for Office 365 Plan 1 or 2, and only works with "Block only specific domains" or "Allow all". For an overview of the offering, see our article on the Microsoft Defender platform.
Configuring the allow list: portal or PowerShell
Prerequisites before changing the setting
- An account with a Teams administration role on the tenant (check in your tenant that the chosen role is sufficient, applying least privilege)
- The MicrosoftTeams PowerShell module installed (Install-Module MicrosoftTeams -Scope CurrentUser)
- The inventory of partner, supplier and customer domains your teams actually exchange with
- A test tenant configured to validate the procedure (see below)
In the Teams admin center, open Users (or External collaboration depending on the tenant) then External access. The menu label varies from one tenant to another. Choose "Allow only specific external domains", then add each allowed domain and save.
Tenant-wide impact
Once the allow list is active, all domains not on the list are blocked, including legitimate partners. Populate the list before switching and validate first in a test tenant. The Microsoft Learn pages consulted give no propagation delay: do not conclude it has failed within a minute of the change.
Implementation: seeding the list from your Microsoft Entra ID guests
Starting from scratch is the best way to cut legitimate exchanges. Tony Redmond suggests seeding the list with the domains of the tenant's guest accounts or those of existing federated chats, then completing it by hand. The script below automates the first approach.
- Modules: Microsoft.Graph.Users and MicrosoftTeams (Install-Module Microsoft.Graph.Users -Scope CurrentUser, then Install-Module MicrosoftTeams -Scope CurrentUser)
- Minimum Graph permission: User.Read.All delegated, read-only
- Output: a CSV file of candidate domains; with the dry-run option, nothing is modified
- Filter: consumer email domains are excluded by default, to be adapted to your context
1#Requires -Version 5.12[CmdletBinding()]3param(4 [switch]$DryRun,5 [string[]]$DomainesExclus = @('gmail.com','outlook.com','hotmail.com','yahoo.com'),6 [string]$CheminCsv = '.\domaines-invites.csv'7)8 9# 1. Connexion à Microsoft Graph en lecture seule10Connect-MgGraph -Scopes 'User.Read.All' -NoWelcome11 12# 2. Récupération des invités et extraction du domaine de leur adresse e-mail13$invites = Get-MgUser -Filter "userType eq 'Guest'" -All -Property Id,Mail14$domaines = $invites |15 Where-Object { $_.Mail } |16 ForEach-Object { ($_.Mail -split '@')[-1].ToLower() } |17 Where-Object { $_ -notin $DomainesExclus } |18 Sort-Object -Unique19 20# 3. Export pour revue manuelle avant toute écriture21$domaines | ForEach-Object { [pscustomobject]@{ Domaine = $_ } } |22 Export-Csv -Path $CheminCsv -NoTypeInformation -Encoding UTF823Write-Host "$($domaines.Count) domaine(s) candidat(s) exporté(s) vers $CheminCsv"24 25# 4. Mode simulation : on s'arrête avant de toucher à Teams26if ($DryRun) {27 Write-Host 'Simulation : aucune modification effectuée.'28 return29}30 31# 5. Ajout des domaines à la liste d'autorisation Teams32Connect-MicrosoftTeams33foreach ($domaine in $domaines) {34 Set-CsTenantFederationConfiguration -AllowedDomainsAsAList @{Add=$domaine}35 Write-Host "Ajouté : $domaine"36}37 38# 6. Vérification du résultat39Get-CsTenantFederationConfiguration | Format-List AllowedDomains, BlockedDomains, BlockAllSubdomainsFirst run the script with -DryRun, review the CSV, remove any doubtful domains, then run it without the option. Then complete the list by hand with partners that were never invited into the tenant.
Testing an external message in a test tenant
The test must prove two things: an allowed domain gets through, an unknown domain is blocked. Since access is bilateral, the test tenant must allow the production tenant's domain, and vice versa.
Allow both domains on each side
In the test tenant, add the production domain to the allow list. In the production tenant (or its pre-production environment), add the test domain. Enable external access on both sides.
Check the applied configuration
Check that the list contains the expected domains.
1Connect-MicrosoftTeams2Get-CsTenantFederationConfiguration | Format-List AllowedDomains, BlockedDomains, BlockAllSubdomainsSend a message from an allowed domain
From an account in the test tenant, write to a production user. Observe what the recipient sees: external tenant label, Accept/Block prompt, message preview. The Microsoft Learn page on trust indicators details these representations.
Remove the domain and try again
Remove the test domain from the production list, wait, then send another message. The chat must fail. To clean up the test conversations, see our article on deleting an external chat for a user.
Test the edge cases
Try a subdomain of an allowed domain, then anonymous meeting join from a domain that is not allowed. These two cases are the pitfalls detailed below.
Documented pitfalls and troubleshooting
Blocking contoso.com does not block its subdomains, unless you enable BlockAllSubdomains:
1Set-CsTenantFederationConfiguration -BlockAllSubdomains $TrueAnother limit: people from a blocked domain can still join your meetings anonymously if anonymous access is allowed. The allow list therefore does not replace a review of your meeting settings.
| Symptom | Likely cause | Resolution |
|---|---|---|
| Chat with a trusted partner fails | The partner does not allow your domain or has not enabled external access | Ask the partner to add your domain and enable external access on their side |
| A subdomain of a blocked domain still gets through | Blocking does not cover subdomains by default | Enable BlockAllSubdomains with Set-CsTenantFederationConfiguration -BlockAllSubdomains $True |
| A user from a blocked domain joins a meeting | Anonymous meeting access is allowed | Review the meetings' anonymous access settings |
| The Defender Tenant Allow/Block List has no effect | The "Allow only specific external domains" mode is active, or the Defender for Office 365 Plan 1 or 2 license is missing | Manage the list in Teams, or go back to "Block only specific domains" or "Allow all" with the required license |
| A different rule must apply to one team | Single organization-wide setting | Create a custom external access policy and enable "Manage external domains for this organization" |
| The External access menu cannot be found | The label varies by tenant | Look under Users or External collaboration in the Teams admin center |
The list reduces the surface, it verifies nothing
An allowed domain can itself be compromised. Microsoft also recommends verifying any support request through a known internal channel and setting up an authentication phrase. Without these reflexes, an attacker who controls a trusted domain remains credible.
Frequently asked questions
Is an allow list enough to block fake IT support calls?
No, it greatly reduces the attack surface by cutting off unknown tenants, but it is not enough on its own. Microsoft recommends combining it with verification of any support request through an internal channel and with an authentication phrase. The DART team also recommends restricting inbound unmanaged Teams accounts.
Should I notify my partners before enabling the list?
Yes. External chat is bilateral: the partner must allow your domain and enable external access for its users, otherwise the conversation fails. This also applies to your test tenant.
Can I apply different lists depending on the department?
Yes, through granular external access policies, for example for finance, executives or IT support. A custom policy assigned to a user takes precedence over the organization setting. The "Manage external domains for this organization" setting must be enabled at the organization level.
Can I manage my list from the Defender Tenant Allow/Block List?
Only with "Block only specific domains" or "Allow all", and with Defender for Office 365 Plan 1 or 2. With an allow list, management is done in Teams.
Where to start
Next actions
- Run the script with -DryRun and review the CSV of candidate domains
- Complete the list with partners absent from the Entra guests and the domains of existing federated chats
- Validate the procedure in the test tenant, including subdomains and anonymous meetings
- Notify critical partners so they allow your domain
- Switch to "Allow only specific external domains" and rerun Get-CsTenantFederationConfiguration to check the result
- Remind users of the procedure for verifying a support request through an internal channel
If your organization has many partners that change often, start with "Block only specific domains" and a granular policy for sensitive populations (finance, executives, IT support), then tighten progressively. If you already have Defender for Office 365 Plan 1 or 2 and prefer centralized management by the security team, keep in mind that this management is incompatible with the allow list.
Going further
- Manage external meetings and chat (trusted organizations) – Microsoft Learn: the reference on allow and block lists, granular policies and Defender prerequisites.
- Impersonating IT support: how threat actors turn a remote session into enterprise-wide access: the detailed attack chain and Microsoft's recommendations.
- Help on the line: How a Microsoft Teams support call led to compromise: Microsoft DART's incident feedback and the recommended allow list model.
- Thwarting Social Engineering Attacks Against Teams Federated Chat: an MVP's view on the maintenance cost and methods for building the list.
- Representation of users outside your organization (trust indicators): what the user sees for an allowed or unknown domain, useful for validating your test.
