Can I Nest Microsoft 365 Groups? (w/Examples) + FAQs

No. You cannot nest one Microsoft 365 Group inside another Microsoft 365 Group. Microsoft’s platform design treats each Microsoft 365 Group as a flat membership object tied to a single mailbox, a single SharePoint site, a single Planner plan, and (optionally) a single Microsoft Teams team, so group-inside-group hierarchies are blocked at the directory level. This limit is documented by Microsoft in the Microsoft 365 Groups overview and reinforced by Entra ID rules that disallow a unified group from appearing as a member of another unified group.

The rule that creates this problem is the Entra ID group-membership constraint described in the Microsoft Entra group types documentation, which blocks Microsoft 365 (unified) groups from being added as members to other Microsoft 365 groups. The immediate negative consequence of ignoring this rule is that your “parent” group never delivers mail, never grants Teams access, and never shows nested members in SharePoint permission previews, even when the admin center appears to accept the change through a PowerShell workaround. According to Microsoft’s published service limits, a single user can be a member of up to 1,000 Microsoft 365 Groups and a group can have up to 100 owners, but there is no “nesting depth” figure because nesting is not supported at all.

Here is what you will learn in this guide:

• 🧩 Exactly which Microsoft 365 objects accept nesting and which refuse it flat-out
• 🛡️ How governance, compliance, and sensitivity labels break when admins force unsupported nesting through scripts
• 🏢 Three real-world scenarios (law firm, hospital, school district) showing the right and wrong way to structure groups
• 🧠 Seven common mistakes IT admins make when trying to simulate nested Microsoft 365 Groups
• ✅ A decision framework using Security groups, Distribution Lists, Dynamic groups, Shared channels, and Hub sites to get nesting-like behavior without breaking Microsoft 365

What “Nesting” Really Means in Microsoft 365

Nesting, in plain English, means placing one group inside another group so the child group’s members automatically inherit the parent group’s access, mail, or permissions. In the on-premises Active Directory world, nesting has been standard practice for decades under the “AGDLP” model (Account, Global, Domain Local, Permission), which Microsoft Learn describes in its Active Directory security groups article. The consequence of assuming that same model works in Microsoft 365 is that admins build permission trees that silently fail, leaving users either over-permissioned or locked out.

The Difference Between Group Types

Microsoft 365 ships four distinct group objects, and only some of them support nesting. The Compare groups article on Microsoft Learn lists these as Microsoft 365 Groups, Distribution Lists, Mail-enabled Security groups, and Security groups. Each has a different purpose, a different backend, and a different nesting rule, which is why confusion is common.

The plain-English explanation is that a Microsoft 365 Group is a “collaboration bundle” (mailbox + SharePoint + Teams + Planner), while a Security group is a pure permission token with no mailbox. The consequence of treating them as interchangeable is that you either lose collaboration features or lose the nesting capability, never both. A real-world example is Maria, an IT admin at a 400-person engineering firm, who tried to add the “All-Engineers” Microsoft 365 Group as a member of the “All-Staff” Microsoft 365 Group and found the PowerShell command Add-UnifiedGroupLinks rejected it with a RecipientTypeDetails mismatch error. A common misconception is that “if PowerShell doesn’t error, it worked,” but Microsoft 365 Groups enforce nesting rules at the directory layer, not the script layer.

Why Microsoft Blocks the Nesting

Microsoft blocks Microsoft 365 Group nesting because each unified group is provisioned with a one-to-one mailbox, site, and team, and a mailbox cannot own another mailbox as a recipient. The governing rule is the Exchange Online recipient model described in the Recipients in Exchange Online docs, which treats each group mailbox as a terminal delivery endpoint. The consequence of forcing a nested assignment is that the parent group cannot expand the child’s membership at delivery time, and emails sent to the “parent” will not reach the child’s members.

A mini-scenario: David, a compliance officer at a hospital system, wants the “Clinical-Leadership” Microsoft 365 Group to automatically include every member of “Cardiology-Chiefs,” “Oncology-Chiefs,” and “Neurology-Chiefs.” Because he cannot nest, he either has to add each user directly (brittle) or convert the structure to Dynamic groups driven by job title attributes, as shown in the Dynamic membership rules documentation. The common misconception is that “Microsoft just hasn’t added it yet”; in reality, Microsoft has publicly confirmed on the Microsoft 365 roadmap and Tech Community forums that nesting is an intentional architectural decision, not a missing feature.

Which Microsoft 365 Objects Support Nesting

Not every group object in Microsoft 365 follows the same rule. The Entra ID group types article and the Exchange Online group nesting guidance together describe a patchwork where some objects nest freely, some nest with limits, and some refuse nesting entirely.

Security Groups Inside Microsoft 365 Groups

As of a 2021 update rolled forward through 2026, Microsoft allows Security groups to be added as members of a Microsoft 365 Group for limited purposes, documented in the Add a security group to a Microsoft 365 group article. The plain-English explanation is that the Security group acts like a “shortcut” to its members for SharePoint site permissions and for Outlook mail, but the members do not become Teams participants or Planner users through that shortcut. The consequence of assuming Teams inheritance is that a user inside the nested Security group can read the SharePoint files and receive the mail but cannot join the team chat, which confuses end users.

A named example: Priya, an admin at a 2,000-student charter school, adds the “All-Teachers” Security group as a member of the “Faculty-Collaboration” Microsoft 365 Group. The teachers immediately receive announcements and see the SharePoint document library, but when one teacher tries to open Teams, she gets a “you are not a member of this team” error. The misconception is that Security group nesting enables Teams; it does not, and Microsoft’s Teams membership documentation explicitly lists direct user or direct group add as the only supported path.

Distribution Lists and Mail-Enabled Security Groups

Distribution Lists (DLs) can nest other Distribution Lists, and Mail-enabled Security groups can nest other Mail-enabled Security groups, under the rules in the Manage distribution groups article on Microsoft Learn. The plain-English explanation is that these are classic Exchange recipient objects, and Exchange has nested them since the 1990s. The consequence of relying on DL nesting inside Microsoft 365 is that the collaboration side (Teams, SharePoint, Planner) stays out of sync, because DLs do not create those objects.

A mini-scenario: Jordan, an HR director at a law firm, asks IT to make “Firm-Wide-Announcements” a DL that nests “Partners-DL,” “Associates-DL,” and “Staff-DL.” That works for email, as confirmed by the Exchange Online distribution group limits. But when Jordan later asks why the firm-wide Teams team is missing associates, IT has to explain that DLs and Microsoft 365 Groups are different objects with different membership paths. The misconception is “mail-enabled equals Teams-enabled”; it does not.

Workarounds That Simulate Nesting

Because true nesting is blocked, Microsoft provides several supported patterns that achieve nesting-like outcomes. The Microsoft 365 governance overview lays out the four main approaches: Dynamic membership, Hub sites, Shared channels, and Security group assignment.

Dynamic Membership Rules

Dynamic membership lets you define a rule (for example, user.department -eq "Sales") that automatically populates a Microsoft 365 Group’s members. The Dynamic membership rules article shows the full syntax. The plain-English explanation is that instead of nesting group A inside group B, you describe group B’s membership as “everyone whose Entra ID attributes match these filters,” so the population updates automatically.

The consequence of using Dynamic groups without good HR data is that people land in the wrong groups instantly, and because the rule fires every few minutes, the error spreads fast. A real-world example: Samir, an IT lead at a 6,000-employee hospital, writes a rule (user.jobTitle -contains "Chief") -and (user.department -contains "Medicine") for the “Clinical-Leadership” group. A physician who changes titles sees her Teams membership update within 24 hours, no manual step required. The common misconception is that Dynamic groups are free; in reality, each member of a Dynamic group needs a Microsoft Entra ID P1 license, as listed in the Microsoft Entra ID pricing page.

Hub Sites for SharePoint Hierarchy

SharePoint hub sites create a parent-child relationship between site collections, documented in the SharePoint hub sites overview. The plain-English explanation is that associating a child site with a hub gives inherited navigation, shared branding, and roll-up news, without putting one Microsoft 365 Group inside another.

The consequence of skipping hub sites is that your SharePoint environment becomes a flat pile of unrelated sites, and users cannot find related content. A mini-scenario: Elena, a knowledge manager at a 1,200-lawyer firm, associates every practice-group Microsoft 365 Group’s SharePoint site with a “Firm-Knowledge” hub site. Each practice group keeps its own membership and permissions, but a single news feed, search scope, and navigation bar surfaces across all of them. The misconception is that hub association shares permissions; it does not, and each associated site retains its own membership, as clarified in the hub site permissions article.

Shared Channels (Teams Connect)

Shared channels, also called Teams Connect, allow one channel from Team A to be shared with members of Team B without adding Team B as a nested member of Team A. The Shared channels in Microsoft Teams article explains the cross-team model. The plain-English explanation is that you keep two separate Microsoft 365 Groups, but share a single channel between them, so collaboration feels nested even though the directory objects are not.

The consequence of overusing shared channels is audit complexity, because each shared channel creates its own SharePoint site and its own sharing log, reviewed through Microsoft Purview audit logs. A named example: Marcus, a project lead at a school district, shares the “Curriculum-Planning” channel from the “District-Admin” team with the “Principals” team, so principals see the discussion without joining the admin team. The misconception is that external tenants cannot join shared channels; as of 2026, cross-tenant shared channels are supported through Entra ID cross-tenant access settings, per the B2B direct connect documentation.

Real-World Nesting Scenarios

The three scenarios below show the most common real situations where admins try to nest Microsoft 365 Groups and the supported pattern that replaces nesting in each case.

Scenario 1: Law Firm Practice Groups

Scenario 2: Hospital Clinical Leadership

Scenario 3: School District Staff Structure

Named Examples You Can Copy

Three named scenarios illustrate the decisions in practice. These examples are deliberately specific so you can map them to your own tenant.

Rachel, a SharePoint administrator at a 900-person insurance company, wants regional offices to roll up under a corporate intranet. She resists the urge to nest Microsoft 365 Groups and instead associates each regional communication site with a single “Corporate-Hub” hub site, configured per the hub site association guide. Each region keeps its own membership, governance, and sensitivity label, while the hub gives a single navigation and search scope.

Tomás, an Entra ID administrator at a 3,500-employee manufacturer, needs a “Plant-Managers” Microsoft 365 Group whose membership auto-updates when HR promotes someone. He writes a Dynamic rule user.jobTitle -eq "Plant Manager" and verifies processing with the dynamic group processing status guidance. When HR updates a title in Workday, Entra ID syncs the attribute and the new manager joins the group within hours, no ticket required.

Aisha, a Teams administrator at a 500-attorney law firm, wants the “Partners” team to see updates from every practice-group team without being a member of each one. She uses Shared channels to expose one channel per practice group to the Partners team, under the rules in the Teams Connect article. The partners get one consolidated Teams pane, and each practice group keeps its own private team.

Mistakes to Avoid

Below are seven of the most common mistakes admins make when trying to nest Microsoft 365 Groups. Each mistake lists the error and the negative outcome so you can avoid repeating it.

• Assuming a successful PowerShell command equals a successful nest. Even when Add-UnifiedGroupLinks returns no error, the mail flow, Teams, and SharePoint layers do not honor the nested relationship, and users silently lose access.
• Nesting a Distribution List inside a Microsoft 365 Group. The DL’s members never become Teams members, which leads to missed chat messages and frustrated users who thought they joined the team.
• Forgetting Entra ID P1 licensing for Dynamic groups. Members who lack a P1 license stop being processed by the rule, per the Entra ID licensing rules, which causes incomplete group membership.
• Mixing sensitivity labels between parent and child constructs. When a “parent” Microsoft 365 Group carries a stricter label than a nested Security group expects, files become unreadable, per the container-level sensitivity labels docs.
• Ignoring the 1,000-group-per-user limit. When admins simulate nesting by adding users to many groups, they eventually hit the cap noted in the Microsoft 365 Groups limits article, and new group additions silently fail.
• Relying on shared channels without audit review. Each shared channel widens the blast radius of file sharing, and without Purview audit review, DLP incidents go undetected.
• Using Distribution Lists for governance-sensitive communication. DLs do not support sensitivity labels, retention policies, or Teams-level eDiscovery, so regulated industries lose audit trails.

Do’s and Don’ts

Follow the do’s and don’ts below to keep your Microsoft 365 group architecture healthy and supportable.

Do’s

• Do use Dynamic Microsoft 365 Groups when membership depends on a repeatable HR attribute, because the attribute becomes the source of truth.
• Do use Hub sites for SharePoint hierarchy, because they give navigation and search benefits without breaking per-site permissions.
• Do use Shared channels for cross-team collaboration, because they preserve each team’s governance while enabling cross-pollination.
• Do use Mail-enabled Security groups when you need both email delivery and permission assignment, because they unify two jobs in one object.
• Do audit group membership quarterly with access reviews in Entra ID Governance, because stale membership creates compliance risk.

Don’ts

• Don’t attempt to nest Microsoft 365 Groups via PowerShell hacks, because the nested relationship is not honored by Exchange, Teams, or SharePoint.
• Don’t use Distribution Lists as a substitute for collaboration groups, because they lack Teams, Planner, and SharePoint.
• Don’t mix personal and compliance-bound data in the same Microsoft 365 Group, because retention labels apply to the entire group container.
• Don’t forget to assign Entra ID P1 licenses to all Dynamic group members, because unlicensed users drop out of processing.
• Don’t allow unrestricted guest access in nested-like scenarios, because Shared channels propagate external reach across teams.

Pros and Cons of Nesting Workarounds

The workarounds that simulate nesting each carry benefits and trade-offs. The table below summarizes the most important pros and cons.

Pros

• Dynamic groups cut admin overhead by linking membership to HR data, which reduces ticket volume.
• Hub sites deliver a consistent intranet experience without forcing site-level permission inheritance.
• Shared channels let users collaborate across team boundaries without duplicating membership lists.
• Security-group-inside-Microsoft 365-Group assignment works well for SharePoint read access, which simplifies file governance.
• Mail-enabled Security groups give one object for mail and permission, which reduces directory clutter.

Cons

• Dynamic groups require Entra ID P1 licensing, which adds per-user cost.
• Hub sites do not share permissions, so admins still manage each site’s membership separately.
• Shared channels create extra SharePoint sites, which increases storage and audit scope.
• Security group nesting does not grant Teams access, which can confuse users.
• Mail-enabled Security groups cannot be converted to Microsoft 365 Groups cleanly, which limits flexibility.

Processes and Forms for Group Architecture

When you design your group architecture, follow the sequence below. Each step has a decision point with a direct consequence.

Step 1: Identify the Purpose

Decide whether the group is for collaboration (Teams, SharePoint, Planner), mail distribution only, or permission assignment only. The decision matters because, per the Compare groups guidance, choosing the wrong object forces you to recreate the group later. If you pick a Distribution List and later need Teams, you cannot convert the DL; you must create a new Microsoft 365 Group.

Consequences of a bad choice include orphan Teams, duplicate mailboxes, and broken sensitivity labels. A mini-scenario: Hannah, a project manager, asks IT for a “DL” when she actually needs a full collaboration bundle. Two weeks later, she asks to add a Teams team, and IT has to create a new Microsoft 365 Group, leaving the DL orphaned.

Step 2: Decide on Membership Source

Choose between assigned membership, Dynamic membership, or Security-group-based membership. The assigned vs. dynamic membership article explains the differences. Assigned is simplest; Dynamic is scalable; Security-group-based is a middle ground.

The consequence of choosing Dynamic without clean HR data is massive membership churn. Yusuf, an HR systems administrator, once saw 400 users added and removed from a Dynamic group in a single day because a payroll system wrote blank department values during a nightly refresh. The misconception is that Dynamic is “set and forget”; in reality, it is “set and monitor.”

Step 3: Apply Sensitivity Labels

Sensitivity labels at the container level control external sharing, privacy, and unmanaged device access, as described in the container labels article. Apply the label at group creation so you do not have to relabel later.

The consequence of skipping labels is uncontrolled external sharing. A scenario: a school district creates a “District-Leadership” Microsoft 365 Group with no sensitivity label, and an executive assistant inadvertently invites an external vendor as a guest. With a “Highly Confidential” label, that invitation would have been blocked automatically.

Step 4: Set Expiration and Lifecycle

Apply a group expiration policy, documented in the Microsoft 365 Groups expiration policy article. Expiration forces owners to renew, which keeps stale groups from accumulating.

The consequence of skipping expiration is group sprawl, where tenants accumulate thousands of unused groups. Nina, an IT lead at a 1,500-employee firm, found 2,300 Microsoft 365 Groups in her tenant before enabling expiration; within 90 days of enabling a 180-day expiration, the count dropped to 900, reducing attack surface and search noise.

Key Entities in Microsoft 365 Group Architecture

Several key entities interact to enable (or block) nesting-like behavior. Understanding each role helps you choose the right tool.

• Microsoft Entra ID is the directory that stores all group objects and enforces the no-nesting rule for Microsoft 365 Groups, per the Entra ID groups overview.
• Exchange Online provides the group mailbox and enforces recipient rules that block unified groups as members of unified groups, per the Exchange Online recipients article.
• SharePoint Online provisions the site behind each Microsoft 365 Group and supports Hub site associations for hierarchy, per the SharePoint hub sites guide.
• Microsoft Teams provisions the team object and supports Shared channels for cross-team collaboration, per the Shared channels documentation.
• Microsoft Purview applies sensitivity labels, retention policies, and audit logs to every group container, per the Purview documentation.
• Planner creates a plan for each Microsoft 365 Group and uses the same membership list, per the Planner for Microsoft 365 article.

Recap of Key Microsoft Rulings and Policy Positions

Microsoft has stated its position on Microsoft 365 Group nesting consistently across product updates. The Microsoft 365 roadmap does not include a nesting feature, and the Exchange Team Blog has repeatedly explained that unified groups are terminal recipients by design. The consequence of expecting a future nesting feature is that architectural decisions based on that expectation will never pay off.

The 2021 update that allowed Security groups to be added to Microsoft 365 Groups (documented in the Microsoft 365 Groups update history) is the closest Microsoft has come to nesting, and it remains limited to membership expansion for SharePoint and Outlook. Microsoft’s ongoing guidance, reinforced through Ignite 2025 sessions, is to use Dynamic groups, Hub sites, and Shared channels rather than wait for native nesting.

FAQs

Can I nest one Microsoft 365 Group inside another Microsoft 365 Group?

No. Microsoft Entra ID blocks unified groups from being members of other unified groups, because each group has its own terminal mailbox, SharePoint site, and Teams team.

Can I nest a Security group inside a Microsoft 365 Group?

Yes. Microsoft supports adding Security groups as members of Microsoft 365 Groups for SharePoint access and mail distribution, but not for Teams membership or Planner access.

Can I nest a Distribution List inside a Microsoft 365 Group?

No. Distribution Lists cannot be members of Microsoft 365 Groups, and the combination breaks both mail flow and collaboration features.

Can a Dynamic Microsoft 365 Group contain nested groups?

No. Dynamic groups define membership by attribute rules, not by nested objects, so adding a nested group has no effect on processing.

Can I nest Microsoft 365 Groups using PowerShell?

No. Even commands like Add-UnifiedGroupLinks do not create honored nesting; Exchange, Teams, and SharePoint ignore the relationship.

Can Hub sites replace Microsoft 365 Group nesting?

Yes. Hub sites provide navigation, search, and branding inheritance across associated SharePoint sites without sharing membership or permissions.

Can Shared channels simulate Microsoft 365 Group nesting?

Yes. Shared channels allow one team’s channel to be shared with members of another team, preserving governance on both sides.

Can I convert a Distribution List into a Microsoft 365 Group?

Yes. The Microsoft 365 admin center supports upgrading eligible Distribution Lists, but Mail-enabled Security groups and nested DLs are not eligible.

Can nested Security group members join the Microsoft 365 Group’s Teams team?

No. Nested Security group members gain SharePoint and Outlook access only; Teams requires direct membership of the user or group.

Can I apply sensitivity labels to nested groups?

Yes. Sensitivity labels apply to the Microsoft 365 Group container, and nested Security group members inherit the label’s effects on files they access through that container.

Can external guests be members of nested groups?

Yes. Guests can be added to Security groups that are nested inside Microsoft 365 Groups, but guest access policies in Entra ID still apply to every layer.

Can I use Dynamic groups to replace most nesting needs?

Yes. Dynamic groups with well-designed attribute rules cover the majority of nesting scenarios, provided every member holds an Entra ID P1 license.