Teams Real Simple with Pictures: Using B2B Management Policy in Azure AD to block Guest invitations to specific domains

blog is part of a series on Teams. For more articles, check back often

Written: 09/01/2022 | Updated: N/A

So we are all back to it! I really hope you enjoyed the holidays. It feels almost like a distant memory – but on the flip side that’s all good because spring and easter and lighter evenings aren’t too far away. Now as I am teaching SCI Fundamentals this week, I only have limited time to devote to the blog: so I am going to write a short one on a nice but seemingly lesser known functionality in Azure AD where you can restrict inviting guests from specific domains, or permit guests from specific domains: in other words a governance functionality very much like how we manage external users and federation in the TAC. This is called a B2B Management Policy. Now, why would we use this and how does it fit in with how we already manage guests? In terms of how we would use this, think of it as follows. When we enable guests in the TAC, we allow Teams owners to invite B2B users from any organisation. That’s cool and frictionless – except thinking about zero trust, it means that we could be leaving ourselves open to insider risk and competitors being added to our Teams. Now, we could go down the route of using sensitivity labels – but we really want to simply block the competitors whole org and any of their users being added to ours as guests. We could go down the route of entitlement management – but this can be heavy and would involve actions on the part of users: besides; it could be bypassed anyway as EM doesn’t lock the ability to add guests via Teams. No, we want something quick and frictionless and automatic: an all out block across the tenant. Well, we can do this in Azure AD. Now, to set expectation two things. Number one: this is simply another useful tool in the kit bag regarding management of guests: you would still use sensitivity labels and EM and this would simply layer over the top of that. Secondly, this isn’t something that will all out block all sharing and communication with other domains: other things need to be added which will be referred to below. All good?

Let’s go.

This blog will cover

  • Setting up a B2B Management Policy to block specific domains
  • Setting up a B2B Management Policy to allow specific domains
  • Blocking messaging with specific domains
  • Blocking sharing files with specific domains
  • PowerShell
  • Notes

Note this blog may have some abridged steps which will assume some experience with a Microsoft 365 environment and Azure AD


  • Microsoft 365 Licence which includes Teams (for testing)
  • Global Administrator role


1.) Login to

2.) From the waffle, or from the left app rail, select Admin

3.) In the Microsoft 365 admin centre, from the left navigation, select Show All and then Azure Active Directory

4.) From the left nav, select Azure Active Directory

5.) Select External Identities

6.) Select External Collaboration Settings

7.) Under Collaboration Restrictions select Deny Invitations to the specified domains

8.) Tick Target Domains, add the specified domains and then click Save

9.) The policy should now be set as confirmed by Azure AD

10.) This blocks the guest with the specific domain being added to any Team in the organisation. When a user tries to do so, it with throw an error ‘something went wrong’ and that there was an issue.

Here shows you what happened if a user with the specific domain is added alongside multiple other users, it will block the specific user in the B2B management policy from being added and add the others



Like federation with external users, in addition to creating a block list, you can also set up an allow list where the specified domains are the only ones you will allow, whereas all other domains are blocked. This is done in exactly the same way as the steps above except allow is specified in the external collaboration settings in Azure AD instead of deny.


Azure AD will block guests: it will not block communication with users outside the organisation and this is a natural extension of blocking them as guests. As opposed to Azure AD, this is executed in the Teams Admin Centre. In the TAC, select Users then External Access, set Block only specific external domains and specify the domains. Select Save once done. Like a B2B management policy, you can also set allow here, specifying the allowed domains, which blocks all others.


With regards specific domains, we can block guests being added in Azure B2B. We can block messaging those specific domains in chat via the Teams Admin Centre. But what about sharing files? That is done within the SharePoint Admin Centre. In the SPO Admin Centre select Policies, then Sharing. Under More External Sharing Settings tick Limit External Sharing by Domain and then Add Domain. Add the deny or allow rule as appropriate, add domains and then Save


The creation of the B2B Management Policy can be done via PowerShell using the following. Adjust as required. Docs refers to module version  or later but I am using the current version, so you’ll need to update your module if’s it’s older than

New-AzureADPolicy -Definition @("{`"B2BManagementPolicy`":{`"InvitationsAllowedAndBlockedDomainsPolicy`":{`"AllowedDomains`": [],`"BlockedDomains`": [`"`"]}}}") -DisplayName B2BManagementPolicy -Type B2BManagementPolicy -IsOrganizationDefault $true 

You can use the Get-AzureADPolicy cmdlet to get the ID of the policy if you want to delete it, or simply use the $currentpolicy.Id below

Get-AzureADPolicy then

Remove-AzureADPolicy -Id [Id] or Remove-AzureADPolicy -Id $currentpolicy.Id


  • You can create one allow list or one deny list. You can’t set up both.
  • You can create only one B2B Management policy
  • You can add domains to a current deny or allow list
  • The maximum size of the entire policy is 25 KB (25,000 characters), in other words you can have as many domains as make up 25,000 characters
  • The list does not apply to externals who have already redeemed the invitation. The list will be enforced after the list is set up. It does cover those in a pending state