Microsoft 365 Group as a Distribution List, Done Right

A Microsoft 365 group distribution list looks like the obvious upgrade from a classic distribution list. You get a shared mailbox, a calendar, a Teams-ready container, and a mailing list in one object. Most IT teams move to it for exactly that reason: one group, several collaboration surfaces, less sprawl. Then a new hire joins the group and doesn't get the emails everyone assumes they're getting, and the migration starts looking like it broke something that used to just work.

It didn't break. It's a setting. Microsoft 365 groups ship with a subscription model that classic distribution lists never had, and if you don't configure it deliberately at creation, new members are added to the group but not subscribed to its conversations. They can see the mailbox if they go looking, but nothing lands in their inbox automatically. For a group that exists specifically to broadcast information, that's the one failure mode you can't afford.

This article walks through why that happens, how autoSubscribeNewMembers fixes it, and how to set up Microsoft 365 groups as distribution lists in a way that actually behaves like a distribution list for every member, not just the founding ones.

Why Microsoft 365 groups aren't classic distribution lists

A classic distribution list has one behavior: mail sent to the list address goes to every member's inbox, always, no exceptions. A Microsoft 365 group is a broader object. It has a shared mailbox, and by default a group's shared mailbox works the way any mailbox does: you see new mail when you open it, not necessarily pushed to your personal inbox.

To make that feel like a distribution list, Microsoft 365 groups have a subscription flag per member. Subscribed members get group conversations delivered to their personal inbox. Unsubscribed members have to visit the group mailbox to read anything. Both states are "members of the group" as far as permissions, Teams access, and SharePoint go. Only the subscription state decides whether email actually shows up where people look for it.

The default that catches teams out

Here's the part that causes support tickets. When you create a group through the Microsoft 365 admin center or via PowerShell with sensible defaults, the founding members you add at creation time are usually subscribed automatically. But members added later, through group membership changes, through dynamic membership rules, or through self-service group joins, are not subscribed by default unless you've explicitly configured the group to do so.

So the group works fine during testing (you're a founding member, you get every email) and then quietly stops working for real users as the group grows. Nobody notices until someone asks why they never got the townhall invite that went to "everyone in Sales."

The fix: autoSubscribeNewMembers

Microsoft 365 groups expose a property called autoSubscribeNewMembers. When set to true, every member added to the group afterward is automatically subscribed to the group's conversations and calendar, and gets mail delivered to their personal inbox exactly like a classic distribution list would. When it's false or unset, new members land in the group but stay unsubscribed until they manually opt in from Outlook.

The critical detail: this property is easiest to set correctly at creation time, before the group starts accumulating members. Retrofitting it on an existing group doesn't retroactively subscribe everyone who already joined unsubscribed. You'd still need to fix those memberships separately.

Setting it via PowerShell

For an existing or newly created group, you can set the flag directly:

Set-UnifiedGroup -Identity "[email protected]" -AutoSubscribeNewMembers $true

Setting it via the Graph API at creation

If you're provisioning groups programmatically, the cleanest approach is to include the setting as part of the initial group object, rather than as a follow-up call:

{
  "displayName": "Sales Team",
  "mailNickname": "sales-team",
  "groupTypes": ["Unified"],
  "mailEnabled": true,
  "securityEnabled": false,
  "autoSubscribeNewMembers": true
}

Set it once, at creation, and every member added from that point forward, whether by an admin, a dynamic rule, or a self-service request, inherits the subscribed state automatically.

Choosing the right group type for a distribution list use case

Not every Microsoft 365 group should behave like a distribution list, and not every distribution list use case needs a full Microsoft 365 group. It's worth being deliberate:

Use case	Recommended object
Pure email broadcast, no shared files or Teams needed	Classic distribution list, or a mail-enabled security group
Team that needs shared mailbox + calendar + Teams + email broadcast	Microsoft 365 group with autoSubscribeNewMembers: true
Large, org-wide announcement list	Microsoft 365 group with subscription forced on, membership tightly controlled
Security or access-only grouping, no mail needed	Security group (not mail-enabled)

Defaulting every group to a Microsoft 365 group "because it does more" adds unsubscribed members and unused Teams sites you then have to clean up later. Pick the type that matches what the group is actually for.

Keeping membership current without manual upkeep

Getting the subscription setting right solves the delivery problem. It doesn't solve the membership problem: who's actually supposed to be in the "Sales Team" or "All Managers" distribution group in the first place. That's a separate, ongoing task, and it's usually where distribution lists rot fastest. Someone changes department, nobody removes them from the old list; someone joins Sales, nobody remembers to add them to the group everyone assumes they're already in.

This is exactly the kind of upkeep that attribute-based rules solve better than manual list management. Instead of an admin manually adding and removing people from a distribution group, a rule based on department, job title, or location keeps membership current automatically, and because the group was created with autoSubscribeNewMembers set correctly, every member the rule adds is subscribed from the moment they join. No manual email delivery fix, no manual membership fix, both handled by the same underlying logic.

What good looks like in practice

• Group created with autoSubscribeNewMembers: true from the start, so subscription is never a follow-up task.
• Membership driven by attributes (department, role, location) rather than a person remembering to add or remove someone.
• A periodic access review to catch groups that quietly became "everyone" over time, since broad distribution groups tend to accumulate members but rarely lose them.
• A clear decision, documented once, on which group type each use case gets, so new groups don't default to whatever was easiest at the time.

Getting these four things right up front is a lot cheaper than debugging "why didn't the new hire get the email" tickets six months into a group's life.

FAQ

What does autoSubscribeNewMembers actually do in a Microsoft 365 group? It controls whether members added to the group after creation are automatically subscribed to receive group conversations and calendar items in their personal inbox. When it's true, new members get mail delivered like a classic distribution list. When it's false, they have to manually subscribe from Outlook, and until they do, group emails only appear in the shared mailbox.

Can I fix autoSubscribeNewMembers on a group that already exists? Yes, you can set it with Set-UnifiedGroup -AutoSubscribeNewMembers $true on an existing group, and it will apply to members added from that point forward. It does not retroactively subscribe members who already joined while the setting was off; you'd need to check and update those individually.

Should every Microsoft 365 group be used as a distribution list? No. Microsoft 365 groups are a good fit when a team needs a shared mailbox, calendar, and Teams presence alongside email broadcast. For a pure mailing-list use case with no collaboration surface needed, a classic distribution list or a mail-enabled security group is often simpler to manage.

How do I know if members of my group are actually receiving emails? Check the subscription state per member, either through the Microsoft 365 admin center group settings or via PowerShell with Get-UnifiedGroupLinks combined with subscription status. If autoSubscribeNewMembers was off when members joined, expect a mix of subscribed and unsubscribed members that needs to be reconciled manually.

Getting the subscription setting right is a five-minute fix. Keeping the membership behind it accurate over time is the harder, ongoing part, and it's where attribute-driven rules pay off more than any manual process. If you want to see how ServiceChanger keeps Entra ID and on-prem AD group membership current automatically as people join, move, and leave, take a look at our identity and access management (IAM) platform, or browse more on Groups and Microsoft 365 on the blog.