Shared mailboxes explained
By Emil Björk · Microsoft ecosystem consultant, Gothenburg
Shared mailboxes are mailboxes multiple people can monitor. Here's how they differ from groups, distribution lists, and personal mailboxes.
3 min read
Share as imagePNGA shared mailbox is a mailbox in Exchange Online that several people can read and send from, without needing a licence per person. They're how addresses like support@, sales@, or info@ get handled by a team rather than an individual.
What a shared mailbox is
A shared mailbox:
- Has its own primary SMTP address.
- Doesn't require a Microsoft 365 licence (up to 50 GB; beyond that, it does).
- Can't be signed into directly — there's no password.
- Is accessed by delegated users who have Full Access and/or Send As / Send on Behalf permissions.
- Shows up in Outlook automatically for those users via auto-mapping.
For each delegated user, the shared mailbox appears as a separate folder under their mailbox tree in Outlook, OWA, and the mobile app.
What it's good for
- Generic team addresses: support, sales, info, hr, careers.
- Ticketing queues that don't yet have a ticketing system.
- Functional roles that change owner over time without disrupting the address.
Shared mailboxes vs Microsoft 365 Groups
A Microsoft 365 Group is much more than an email address — it also has a SharePoint site, a OneNote, a Planner plan, and can be the basis of a Teams team. Mail to a group can land in members' inboxes or in the group's own conversation history.
If the team wants a shared workspace alongside the inbox, a group is usually the better choice. If they just need a shared address to monitor and reply from, a shared mailbox is simpler.
Shared mailboxes vs distribution lists
A distribution list (or distribution group) is a fan-out address: mail sent to it is delivered to each member's personal inbox. There's no shared storage. Compared to a shared mailbox, this means no collaborative read/reply, but everyone gets their own copy. Use it for announcements, not for shared queues.
Operational tips
- Set delegated users to send on behalf or send as depending on whether you want the original sender's name to appear.
- Use Sent Items copy settings (an option in Exchange) so sent mail lands in the shared mailbox's Sent folder, not the sender's personal one.
- Apply Purview retention to shared mailboxes the same way you do to personal ones.
- For high-volume scenarios, route the address into a real ticketing system (Zendesk, ServiceNow, Dynamics) instead of letting it grow.
Shared mailboxes are a great low-cost starting point for team-based email. They're a stop-gap for serious workflow, not a destination.
Licensing edge cases worth knowing
The "no licence needed" rule has real limits that catch tenants out. A shared mailbox growing past 50 GB needs a licence assigned to it (any Exchange Online plan) purely to unlock the larger quota — the mailbox still can't be signed into directly, but it stops being genuinely free at that size. Separately, if a shared mailbox needs to be enabled for Microsoft 365 Copilot, in-place archiving beyond the default, or litigation hold, it typically needs an appropriately licensed user technically associated with it, since those capabilities are gated by licence regardless of the mailbox type. Treat "shared mailboxes are free" as true only for straightforward, moderate-volume use — anything approaching enterprise archival or AI-feature requirements needs the same licensing conversation a personal mailbox would.
Frequently asked questions
Can a shared mailbox send external mail without exposing which delegate actually replied? Yes — with Send As configured (rather than Send on Behalf), outbound mail shows only the shared mailbox's address as the sender, with no indication of which delegated staff member actually typed the reply; this is the standard configuration for support and sales addresses where a consistent single-sender identity matters more than internal attribution.
Do shared mailbox permissions show up in an access review? Not by default in most Entra ID access review configurations, since Full Access and Send As permissions are Exchange-native grants rather than group memberships — a periodic manual review (or a script pulling mailbox permissions via Graph PowerShell) is the practical way to audit who has access to a shared mailbox, since it won't automatically surface in the same governance tooling used for group-based access.
Was this useful?
Spot something wrong or want a topic covered? Send it through the contact form.