Shared Mailbox, Distribution List, or Microsoft 365 Group?

An auditor asks a narrow question: who answered the complaint that arrived at the support address on a Tuesday in March, two years ago? Nine people have had access to that mailbox. The reply is sitting in the Sent Items of someone who left in 2024. The From line reads support and nothing else. Answering takes a week, and the answer is a shrug.

That week was bought years earlier, in about ninety seconds, when somebody needed an address for the website contact form and picked whichever option was closest to the mouse. Microsoft 365 offers several objects that all produce a working email address and all look identical in the address book. They behave nothing alike once mail starts arriving.

Four objects, one address bar

Distribution groups

Microsoft describes distribution groups as being used for sending notifications to a group of people, and recommends them for broadcasting to a defined set, such as everyone in a building. The critical property is what a distribution group is not: it is not a mailbox. It has no storage. Mail addressed to it is expanded and delivered into each member's own mailbox, and that is the end of the group's involvement.

Nothing accumulates. There is no shared history, no shared folder structure, and nothing at the group itself to search two years later. If four people were members and three have since left, the only surviving copies are wherever those individual mailboxes went. A distribution group is a routing rule wearing an email address.

Dynamic distribution groups work the same way with one difference Microsoft states plainly: membership is determined each time a message is sent to the group, based on filters and conditions you define, rather than from a stored member list.

Mail-enabled security groups

A security group grants access to Microsoft 365 resources such as SharePoint sites. A mail-enabled security group does both jobs at once. Microsoft says they function the same as regular security groups, except that they cannot be dynamically managed through Microsoft Entra ID and cannot contain devices, while adding the ability to send mail to all group members.

The convenience is real and it is also the trap. One object now controls both mail delivery and resource access, so adding somebody to the group because they should see the announcements is the same action as granting them the files. Membership changes made for a mail reason get audited later as an access decision.

Shared mailboxes

Microsoft's stated use case for a shared mailbox is exactly the one in question: when multiple people need access to the same mailbox, such as a company information or support email address, a reception desk, or another function shared by several people. It is a real mailbox with real storage and a calendar. Mail lands in one place and stays there.

What it is not is an account. Every shared mailbox has a corresponding user account with a system-generated password that is not known and not intended for use, and Microsoft's instruction is unambiguous: always block sign-in for that account and keep it blocked. People reach the mailbox by signing in as themselves and opening it.

The absence of a security context has a consequence most teams discover late. Microsoft states that email sent from a shared mailbox cannot be encrypted, because the mailbox has no username and password of its own and therefore cannot be assigned an encryption key. If members encrypt using their own keys, other members might not be able to read those messages. Microsoft also caps practical use at 25 users, warning that beyond that people might see connection failures or duplicated messages.

Microsoft 365 groups

A Microsoft 365 group is where the mailbox stops being the whole product. Microsoft describes it as being for collaboration between users, both inside and outside the company, where members get a group email plus a shared workspace for conversations, files, and calendar events, along with a video service and a planner, and which can also be connected to Teams.

That is the dividing line worth memorizing. If the work is answering mail from outsiders and the artifact is a thread, a shared mailbox fits. If the work generates documents, tasks, and internal discussion that outlive any single message, the group is the correct object, because it brings the workspace along with the address. Microsoft 365 groups also support dynamic membership through Microsoft Entra ID, which neither distribution groups nor shared mailboxes do.

The licensing rule that surprises people

Here is the sentence that costs money. A user needs a licensed Exchange Online mailbox in order to open a shared mailbox, but the shared mailbox itself does not need its own license, up to a point. Microsoft states that shared mailboxes are limited to 50 GB, and that to increase the size limit to 100 GB, the shared mailbox must be assigned an Exchange Online Plan 2 license. Unlicensed shared mailboxes created before July 2018 kept a 100 GB size, which is why an old mailbox and a new one in the same tenant can behave differently for no visible reason.

Fifty gigabytes sounds like plenty until an address has been collecting attachments for eight years with nobody deleting anything. What happens at the ceiling is specific, and it is not a warning email to the help desk. In Microsoft's words, when a shared mailbox reaches the storage limit you can receive email for some time but cannot send new email; after some time the shared mailbox stops receiving email and senders receive a non-delivery receipt. Customers writing to your support address get a bounce, and nobody inside the company sees it happen.

The archive is a separate purchase, not a workaround. Increasing the size of the archive mailbox requires an Exchange Online Plan 2 license, or an Exchange Online Plan 1 license with an Exchange Online Archiving add-on. Either of those also allows auto-expanding archiving to be enabled. Microsoft's published limits give each archive 100 GB initially, with additional storage added incrementally as that capacity is reached, up to 1.5 TB including the recoverable items folder.

Litigation hold carries the same bill. To place a shared mailbox on litigation hold, Microsoft requires that shared mailbox to hold an Exchange Online Plan 2 license, or Plan 1 with the Exchange Online Archiving add-on. The detail that catches people is the sequence: the license has to exist before the hold, and the hold has to exist before anything gets deleted.

Full access, send as, and send on behalf are three different things

Permissions on these objects are usually granted in a hurry and almost never reviewed. Microsoft's definitions are precise, and the differences are visible to whoever receives the mail.

• Full Access allows the delegate to open the mailbox and view, add, and remove its contents. It does not allow the delegate to send messages from the mailbox.
• Send As allows the delegate to send messages as if they came directly from the mailbox or group. Microsoft is explicit that there is no indication the message was sent by the delegate. It does not allow reading the mailbox.
• Send on Behalf allows the delegate to send messages from the mailbox, and the From address clearly shows that the message was sent by the delegate on behalf of the mailbox or group. Replies still go to the mailbox, not to the delegate. It also does not allow reading the mailbox.

Two consequences follow. First, reading and sending are independent: a person can read everything and send nothing, or send as the company and never see a single reply. Second, when a user holds both send permissions, Microsoft states that the send-as permission is always used. Grant both and the on-behalf attribution you thought you had disappears from every message that leaves.

Full Access carries a side effect worth knowing before it lands on a hundred desktops. By default, mailbox auto-mapping uses Autodiscover to automatically open the mailbox in the delegate's Outlook profile alongside their own. It can be switched off at the moment the permission is assigned, and Microsoft notes that auto-mapping works only for individual users and not for any kind of group.

The sent-items behavior

The classic complaint arrives about a week after go-live: replies sent from the support address are invisible to everyone except the person who sent them. That is the documented default. Microsoft states that messages sent from the shared mailbox are not saved to the Sent Items folder of the shared mailbox, and are saved instead to the Sent Items folder of the person who sent the message. The reason is structural. The sender is signed in as themselves and merely opening the shared mailbox, so Outlook files the copy where the sender is.

Fixing this once meant PowerShell, and the message-copy parameters still exist per mailbox for both the send-as and the send-on-behalf paths. The same choice is now exposed in the Microsoft 365 admin center under the shared mailbox's sent items settings. Either way it remains a deliberate decision, made per mailbox, and both send paths need it. Enabling one and not the other produces a shared Sent Items folder that looks convincingly complete while quietly omitting half the outbound mail.

What happens when the owner leaves

The most common origin story for a badly built shared address is an offboarding. Someone leaves, their mail still matters, and their user mailbox is converted to a shared mailbox. That path is supported and documented, along with conditions that are easy to miss.

The mailbox must be licensed at the moment of conversion. Afterward the license can be removed, but only if the mailbox is smaller than 50 GB. Over that, content has to be deleted or a Plan 2 license kept in place. Existing email and calendar information is retained, and inbox rules are preserved through the conversion, which is its own hazard: forwarding rules the departed employee wrote keep running against an address nobody is watching.

Two warnings deserve reading twice. Microsoft says not to delete the old user's account, because the account is required to anchor the shared mailbox. And unless the password is reset, the original username and password will continue to work on the shared mailbox. A converted mailbox inherits credentials a former employee may still remember.

If the goal is preservation rather than continued use, conversion is the wrong tool and the order of operations is unforgiving. Making a mailbox inactive requires a hold on the mailbox, and then deleting the mailbox or the corresponding user account. The mailbox must be licensed correctly so that the hold can be applied before deletion. Microsoft's own sequence is to apply the retention settings, wait for them to take effect, then remove the account. Reverse those steps and there is nothing left to hold.

What an auditor can actually attribute

Shared identity and individual accountability are in tension, and the resolution is less bleak than it first looks, provided the right object was chosen at the start.

Mailbox auditing is on by default for user mailboxes, shared mailboxes, and Microsoft 365 group mailboxes. The records separate the actor from the object. One field records the user who performed the action; another records the email address of the person who owns the mailbox that was accessed. A logon type value records how the mailbox was reached, distinguishing a mailbox owner from an administrator and from a delegate, plus further values for datacenter transport and service accounts. Anyone holding send-as, send-on-behalf, or full-access permission on another mailbox is recorded as a delegate.

So the audit log can usually name the individual even when the message itself cannot. What it will not do is reconstruct browsing at fine grain. Microsoft notes that audit records for folder bind actions performed by delegates are consolidated, generating one record for individual folder access within a 24-hour period. Retention is finite as well. Standard auditing keeps records for 180 days when they were generated on or after October 17, 2023. Premium auditing retains Exchange, SharePoint, OneDrive, and Microsoft Entra records for one year, but only for users assigned an E5 or equivalent add-on license; records for everyone else are kept for 180 days.

Retention and discovery hold an object-shaped trap of their own. Retention policies applied to the Exchange mailboxes location support shared mailboxes and resource mailboxes. They do not reach Microsoft 365 group mailboxes. Microsoft is blunt about it: even though a Microsoft 365 group has an Exchange mailbox, a retention policy for the Exchange mailboxes location will not include content in Microsoft 365 group mailboxes. Groups require the separate group mailboxes and sites location, which covers the group's mailbox, site, and files together. A tenant running an all-mailboxes retention policy and believing everything is covered may have left every group inbox and every group site outside the policy entirely.

Distribution groups have no equivalent option, because there is nothing to retain. An object with no storage cannot be a retention location or a hold target. Whatever policy applies to each member's individual mailbox is the entire extent of the coverage, which means the retention story for an address served by a distribution group is really several unrelated retention stories that change shape every time someone joins or leaves.

Choosing among these objects is really choosing what you want to be true in three years. A distribution group promises that no record will exist in any one place. A shared mailbox promises one record, a hard storage ceiling, and permissions that decide whether that record names anyone. A Microsoft 365 group promises a workspace and a second compliance configuration somebody has to remember to build. None of those promises is wrong on its own terms. The failure is making one by accident and reading the terms for the first time during an audit, when the ninety seconds spent creating an address turns out to have been the only cheap moment the decision was ever going to have.