A shared mailbox is the cheapest thing in Microsoft 365 that solves a real problem. An address several people have to answer gets its own mailbox, members see the incoming mail and the outgoing replies, and nobody pays for another licence. For a reception address or an accounts address it is usually the right answer on the first day and still the right answer three years later.
It also has a specific published set of limits, and most of the trouble teams run into comes from hitting one of them without knowing it existed. Below is what Microsoft documents about the mechanism, followed by the questions a mailbox cannot answer no matter how it is configured.
What it is, and what it does not cost
A shared mailbox stores up to 50 GB of data without a licence being assigned to it. Members with the right permissions can send as the mailbox or send on behalf of it, so replies go out from the address rather than from a person, which is the whole point for an address like support@ or reception@.
The part that is easy to misread is which side needs a licence. The shared mailbox itself does not need one. Every person who opens it does: to access a shared mailbox, a user must have a licensed Exchange Online mailbox of their own. The subscription also has to include Exchange Online at all. Microsoft 365 Apps for business does not include email, while Microsoft 365 Business Standard does, so the plan matters before anything is created.
One more thing is worth knowing before an address is created rather than after. Two shared mailboxes cannot be given the same name, even on different domains. Trying it returns an error about the proxy address already being in use by another object, which is a confusing message for what is really a naming collision.
The limits worth knowing before it fills up
| Limit | What Microsoft publishes |
|---|---|
| Storage | 50 GB without a licence. To raise it to 100 GB the mailbox needs an Exchange Online Plan 2 licence |
| Concurrent users | A shared mailbox supports a maximum of 25 users |
| External access | People outside the organisation cannot be given access |
| Deleting messages | Users cannot be prevented from deleting messages |
| Encryption | Mail sent from a shared mailbox cannot be encrypted |
| Litigation hold | Requires additional licensing |
The 25 user ceiling is the one that decides whether the arrangement will scale. Microsoft states plainly that if too many users access the mailbox at the same time they may see connection failures or duplicated messages, and that teams needing more should use a Microsoft 365 group instead. A team of six will never notice. A support rota of thirty will, and the symptom looks like a sync bug rather than a capacity limit.
The storage limit deserves attention because of how it fails. When a shared mailbox reaches its limit it keeps receiving mail for a while but cannot send. After a while it stops receiving too, and senders start getting non delivery receipts. An address that quietly stops accepting customer mail is a worse failure than one that throws an obvious error, and for an address that receives attachments all day, 50 GB arrives sooner than expected.
Two footnotes save an argument later. Unlicensed shared mailboxes created before July 2018 are 100 GB rather than 50 GB, so an old mailbox and a new one in the same tenant can behave differently. And the inability to prevent deletion is not a permissions oversight: Microsoft's stated route to restricting deletion is to use a Microsoft 365 group instead of a shared mailbox.
Sign-in, permissions and the automapping trap
Every shared mailbox has a corresponding user account with a system generated password that nobody knows and nobody is meant to use. Microsoft's guidance is direct: always block sign in for that account and keep it blocked. Teams that try to treat the mailbox as an account to log into are working against the design, and the workarounds tend to end with a password reset that breaks access for everybody.
Access comes from permissions granted through membership instead. That has a consequence for security posture that surprises people: because the mailbox has no security context of its own, no username and no password, it cannot be assigned an encryption key, which is why mail sent from it cannot be encrypted. If members encrypt messages with their own keys, other members may not be able to read them, which turns a shared queue into a set of private ones.
Automapping is where a working setup breaks for reasons nobody can see. Automapping is on by default, and it is what makes the shared mailbox appear in a member's Outlook automatically after they restart it. The catch is that automapping is set on the user's mailbox, not on the shared mailbox. Manage access with a security group and automapping will not work, so permissions have to be assigned explicitly for the mailbox to appear on its own. A great many "it does not show up in Outlook" tickets are this and nothing else.
Access from a phone works, through the Outlook app for iOS and Android, and through Outlook on the web in a browser. Members of the mailbox can also all create, view and manage appointments on its calendar, and everyone sees each other's changes.
The three permissions, and why replies fail
Access to a shared mailbox is granted through three permissions that do different jobs, and the most common setup failure is granting one and expecting the behaviour of another.
Full Access lets somebody open the mailbox and act as its owner. They can read, change and delete messages, create calendar items, and add tasks and contacts. What they cannot do is send anything, unless they also hold one of the other two permissions. A member with Full Access alone can read the whole queue and cannot answer it, which reads on screen as a broken mailbox rather than a missing permission.
Send As makes the reply come from the address. When somebody sends from a shared mailbox called Marketing Department with this permission, the message looks like it came from Marketing Department. For a customer facing address this is almost always the one wanted, because it keeps the conversation attached to the address instead of to whoever happened to be on shift.
Send on Behalf shows both names. A reply from a mailbox called Reception Building 32 arrives as sent by the person on behalf of Reception Building 32. That is the right choice for an internal address where the recipient should know who actually typed it, and the wrong choice for a support queue where the customer only needs one address to reply to.
Microsoft's own note on the admin screen is that Full Access and Send As are both required for a shared mailbox to work properly, which is a reasonable default to start from. One trap is documented and easy to hit: Send As and Send on Behalf do not work in the Outlook desktop client when the mailbox is hidden from address lists, because both require the mailbox to be visible through the Global Address List. Hiding a shared mailbox to keep the directory tidy can therefore break sending for everyone who uses the desktop client, while the browser stays fine.
Shared mailbox or Microsoft 365 group
The two are close enough that teams pick by habit, and Microsoft's documentation points from one to the other at three separate decision points.
| Situation | What the documentation points to |
|---|---|
| More than 25 people need access | A Microsoft 365 group |
| Deletion has to be restricted | A Microsoft 365 group |
| People outside the organisation need access | A group for Outlook |
| Replies must come from the address itself | A shared mailbox |
One conversion path is worth knowing because it saves a licence. An existing user mailbox can be converted into a shared mailbox, which is the usual move when somebody leaves and their address still receives mail that the team has to answer. The mail stays where it is, the licence comes back, and the address keeps working.
That pattern is worth reading as a shape rather than a list. A shared mailbox is built for a small group of insiders replying as an address. Once a requirement involves scale, control over what members can destroy, or anyone outside the company, the mailbox stops being the intended tool.
What a mailbox cannot record
Everything above is about mail. The questions teams actually bring to a shared mailbox are usually about work, and that is where the container runs out.
A mailbox has one axis, which is time. Anything else has to be faked. Who owns this request becomes a folder, or a colour category, or a convention nobody wrote down. What state is it in becomes read or unread, which is a per person flag rather than a fact about the request. When did this arrive and how long did it take becomes a manual count through a folder. None of those are configuration problems. A mailbox stores messages, and a request is not a message: it is a thing with an owner, a state, a few fields, and a history that includes the reply.
The gap widens the moment the incoming mail is generated rather than written. A form submission arriving as a notification email carries its answers as text in the body. The answers cannot be filtered, sorted or counted, so a queue of fifty applications is fifty near identical emails, and the only way to find the ones nobody has contacted is to open each one. Mark them read and the list looks calmer, and the question of how many arrived, how many were accepted, and how long the average reply took still cannot be answered from the mailbox.
This is the point at which most teams add a spreadsheet next to the mailbox, and the spreadsheet is the real diagnosis. Its columns are exactly the fields the mailbox has nowhere to store. A form tool with response management keeps those columns on the record itself, along with the reply that was sent, which removes the retyping rather than organising it. The cases where that matters most are applications, event sign ups and support intake, because each has a middle state that lasts days and fields a mailbox cannot hold.
What to change first
Two habits prevent most of the trouble above. Assign permissions explicitly rather than through a security group, so automapping keeps working and the mailbox appears in Outlook without a support ticket. And watch the storage number rather than waiting for a complaint, because the failure mode is an address that stops accepting customer mail before anybody inside notices.
Take last month's mail to the address and split it into replies written by a person and submissions generated by a form. For the first pile, a shared mailbox with permissions assigned explicitly rather than through a security group is the right tool and needs no replacing. For the second pile, look at what a record per submission holds that a message cannot, and try it on real answers before pointing any address anywhere new. Halict charges by the number of people answering rather than by how much arrives.
Q1. How many people can use one Microsoft 365 shared mailbox?
Microsoft documents a maximum of 25 users. Beyond that, people accessing it at the same time may see connection failures or duplicated messages, and the documented alternative is to use a Microsoft 365 group instead. The limit is about concurrent access rather than how many members are listed.
Q2. Does a shared mailbox need its own licence?
Not for the first 50 GB. Raising the limit to 100 GB requires an Exchange Online Plan 2 licence on the mailbox, and litigation hold or a larger archive also needs additional licensing. Everyone who opens the mailbox does need a licensed Exchange Online mailbox of their own.
Q3. Can somebody sign in to a shared mailbox directly?
No, and the account should be left blocked. Each shared mailbox has an associated user account with a system generated password that is not known and not intended for use, and Microsoft's guidance is to block sign in for it and keep it blocked. Access is meant to come from permissions granted to members.
Q4. Why does the shared mailbox not appear in Outlook for some people?
Usually because permissions were granted through a security group. Automapping, which puts the mailbox into Outlook automatically, is set on the user's own mailbox rather than on the shared one, so it does not work when access is managed by a group. Assigning permissions explicitly restores it, after Outlook is closed and restarted.
Q5. Can a shared mailbox track who is handling each request?
Not as a field. There is no owner and no status on a message, so teams improvise with folders, categories or the read flag, none of which is a fact about the request that everyone can see. Tracking that needs to survive a handover generally has to live outside the mailbox.