Microsoft 365 Groups vs distribution lists vs shared mailboxes

Most people arrive at this question with two of the three in mind. They are deciding between a shared mailbox and a distribution list, because those are the two names that come up first, and the Microsoft 365 Group sitting behind every Team they already use never enters the conversation. That is usually the mistake. Microsoft gives you three tools that all involve a group of people and an email address, the names do not describe what they do, and picking the wrong one creates problems that only surface months later.

Here is the plain-English version of all three, including the traps Microsoft's own documentation does not lead with, and a section at the end on what happens to shared mailboxes over years rather than weeks, which is where the real cost lives and where most articles stop.

The short answer

• •A team needs to work together, with files, chat and a calendar as well as email: Microsoft 365 Group, usually created as a Team
• •Several people need to monitor and reply from one address, like accounts@ or support@: shared mailbox
• •You just need one address to reach a set of people: distribution list

That covers most cases. The rest of this article explains why, where the traps are, and what to do if your tenant already has the wrong mix, which, honestly, most do.

Microsoft 365 Groups: the one people forget they already have

A Microsoft 365 Group is not really an email feature. It is a membership object that provisions a bundle: a group mailbox and shared calendar, a SharePoint site for files, a Planner board, and optionally a Teams team. It works the other way around too. Every team created in Microsoft Teams silently creates a Microsoft 365 Group behind it, along with the SharePoint site and everything else. If your business uses Teams at all, you already have Groups, whether or not anybody decided to.

For a project team or a department that genuinely works together, this is the right tool, and in practice you usually get it by creating a Team rather than by creating a Group directly. The email side is real but secondary: members can receive group mail in their own inbox or leave it in the group mailbox.

Two behaviours catch people out. External senders are blocked by default, so a Group address that customers are meant to email will silently reject them until somebody changes a per-group setting. And because every Team creates a Group, and by default most staff can create Teams, tenants accumulate dozens of half-used Groups, each with its own SharePoint site and its own sharing surface. If you have ever opened your SharePoint admin centre and wondered where fifty sites came from, this is where.

Good for: project teams, departments, anything with files and conversation as well as email. Not good for: a customer-facing address, or a simple broadcast.

Shared mailboxes: one inbox, many people

A shared mailbox is a real mailbox that multiple staff open alongside their own. Everyone with permission sees the same inbox, the same folders, and the same history, and they can reply from the shared address rather than their personal one. A new starter given access today can read everything the mailbox has ever received. This is what functional addresses like bookings@, accounts@ and support@ should almost always be.

The licensing is the headline feature: a shared mailbox does not need its own licence, as long as it stays under 50GB and you do not need archiving or litigation hold on it. Past any of those it needs an Exchange Online licence like a normal mailbox. Plenty of businesses discover this the hard way when a busy shared mailbox quietly crosses 50GB and mail flow stops.

Two permission types matter. Send As means the email appears to come from the shared address itself, with no trace of who sent it. Send on Behalf shows both, as in 'Jamie on behalf of accounts@'. For customer-facing addresses you almost always want Send As, and it is worth checking which one you actually have configured, because the default surprises people.

Good for: functional and customer-facing addresses where replies and history matter. Not good for: broadcasting, or anything needing shared files.

Distribution lists: one-way broadcast

A distribution list, also called a distribution group, is the oldest and simplest of the three. It is a single alias that fans an email out to every member. Someone emails allstaff@yourcompany.com.au and Exchange delivers a copy to each person's own mailbox. That is the whole feature. Nothing is stored centrally, and if someone joins the list tomorrow they see nothing that was sent yesterday.

That simplicity is also its strength. For announcements, alerts from systems, or a supplier-facing address that just needs to reach three people, a distribution list is lightweight and hard to break. Microsoft has been nudging everyone towards Microsoft 365 Groups for years, but a plain broadcast list is still the right tool when broadcast is genuinely all you need.

Good for: announcements, system notifications, simple fan-out addresses. Not good for: anything where people need to reply from the address, see a shared history, or collaborate.

Side-by-side comparison

Which should you use? Real scenarios

A project team working together for six months

Microsoft 365 Group, created as a Team. Files, chat, meetings and a group inbox in one membership, and you can archive the lot when the project ends.

accounts@ monitored by three people in finance

Shared mailbox. They need shared history and to reply as accounts@, and it costs nothing in licensing.

support@ that customers email, handled by a rotating roster

Shared mailbox, with Send As permissions and a named owner. Not a Group: a Group blocks external senders by default and adds collaboration features an email queue does not need. If volume grows to the point where you need assignment, statuses and reporting, that is when to look at proper ticketing rather than bending a Group into shape.

allstaff@ for company announcements

Distribution list. Nobody replies from it, nobody needs history, and you do not want to provision a SharePoint site for the privilege of sending a newsletter.

A distribution list people keep replying to and losing track of

That is your signal it should have been a shared mailbox all along. See below for how to make the switch.

What goes wrong with shared mailboxes over time

Every article on this subject stops at the comparison table. The table is the easy part, and it is also not where businesses lose money. What costs you is what happens to these objects over five years, and that is a different subject entirely.

Some context on where this is coming from, because it changes what is worth telling you. Alongside this work I design and run automated lifecycle governance for thousands of shared mailboxes in an environment of around 200,000 users. Access is granted for a defined period rather than indefinitely, so it expires on its own and somebody has to make a decision to renew it. Legal hold and audit settings are enforced by policy rather than applied by hand, so a mailbox cannot quietly end up outside them. Archiving is driven by actual usage, so nothing sits unowned for years because nobody remembered it existed.

The point is not the scale. It is that at that size you get to watch every one of these failures happen hundreds of times, which makes it very clear which ones actually matter, and every one of them shows up identically in a twenty-person business. Here they are, in the order they usually bite.

Nobody owns it

The person who set up info@ left two years ago, six people have access, and nobody is responsible for what happens in it. Mail arrives, everyone assumes somebody else is reading it, and nothing is answered for a fortnight until a customer rings to ask why. This is the single most common shared mailbox failure and it is not a technical problem. Every shared mailbox needs a named owner, and the moment to name one is when it is created, not after something is missed.

Access granted years ago that nobody reviews

Access to a shared mailbox is granted once and then it is permanent, because nothing in Microsoft 365 ever prompts anybody to look at it again. Five years of staff changes later, the list of people who can read accounts@ bears no relationship to the list of people who should. Nobody did anything wrong. There was simply never a moment at which anybody was asked.

The scaled-down version of what I run at work is not machinery, it is a calendar reminder. Twice a year, list who has access to what and remove anybody who does not need it. Fifteen minutes. The value is not the list, it is that somebody has to look at it and the default answer at a review is remove.

The person who set it up leaves

Shared mailboxes are anchored to a user account, and that account is exactly the kind of thing that gets tidied up during an offboarding by somebody who does not know what it is anchoring. Delete it and the shared mailbox goes with it. Convert the departing person's mailbox in the wrong order and you find the option is not there any more.

This is the point where offboarding and shared mailboxes become the same subject, and the order genuinely matters.

It quietly starts costing money

A shared mailbox is free under 50GB. Above it, or the moment it needs litigation hold or an expanded archive, it needs a licence, and the failure mode is not a warning email, it is mail bouncing. Meanwhile the opposite problem is more common and more expensive: mailboxes that were created as ordinary licensed users and never converted, sitting there paying a full seat for reception@ and the boardroom calendar.

Sent items scatter, and nobody notices for six months

By default, a reply sent from a shared mailbox lands in the sender's personal Sent Items, not the shared one. So the mailbox contains every message received and half the messages sent, and the half that is missing is whichever half you need when somebody disputes what was agreed. There is a setting that fixes this and it is off unless somebody turned it on.

There is no record of what was decided

The one that only becomes visible during a dispute. If a shared mailbox has no owner, no access review and no hold configured, then at the moment somebody asks what was sent and when, the honest answer is that nobody knows and some of it may be gone. That is a governance failure rather than a technical one, and it is fixable in advance and not afterwards.

The gotchas nobody mentions until they hurt

• •The 50GB trap: a shared mailbox over 50GB, or one that needs archiving or litigation hold, requires a licence. Unlicensed and over quota means bounced mail.
• •Send As is not the default everywhere: check whether your team actually has Send As or only Send on Behalf on customer-facing mailboxes.
• •Sent items scatter by default: replies sent from a shared mailbox can land in the sender's personal Sent Items unless you turn on the setting that copies them to the shared mailbox. Six months later, nobody can find what was sent.
• •Groups block external mail by default: if customers are supposed to email a Group address, someone has to flick that switch, and usually nobody has.
• •Distribution lists can be upgraded: Microsoft provides an upgrade path from cloud-managed distribution lists to Microsoft 365 Groups, but not for nested, dynamic, or on-premises synced lists.
• •Every Team is a Group: restricting who can create Teams is the single most effective control against sprawl.
• •Around 25 concurrent users is the practical ceiling on a shared mailbox. Past that, Outlook gets unreliable and it is time for a Group or proper ticketing.

Fixing a distribution list that should be a shared mailbox

There is no one-click conversion between these two, but the manual path is straightforward and low-risk if you sequence it properly:

• •Create the shared mailbox under a temporary address and grant the current list members Full Access and Send As.
• •Turn on the setting that keeps sent items in the shared mailbox, and name an owner.
• •In a quiet window, remove the alias from the distribution list and add it to the shared mailbox, then retire the list.
• •Let senders keep using the same address throughout. From the outside, nothing changed, except replies now have history.

Where to start

Almost every tenant I review has a mix of all three, accumulated over years: distribution lists doing shared mailbox jobs, shared mailboxes with no owner, and a graveyard of Groups from Teams nobody remembers creating. The fix is not dramatic. List every address, decide what job each one is actually doing, match it to the right tool using the table above, name an owner for each, and consolidate the duplicates.

Then put a date in the calendar to look at it again in six months, because the list you produce today is accurate today and will not be accurate in a year. That single habit is most of what governance means at this scale.