Outlook shared mailbox or a shared inbox tool: what Microsoft 365 gives you free, and where it stops

If your company runs on Microsoft 365, you almost certainly already have a shared inbox. It is called a shared mailbox, an admin created it in about a minute, it costs nothing, and several people open it in Outlook every day. For a lot of teams that is the whole story and it should stay the whole story. This article is for the teams where it has stopped being enough, and its aim is to be precise about where a shared mailbox stops rather than to talk anyone into software they do not need.

We build Sektra, which connects to Microsoft 365 shared mailboxes among other things, so we have an interest here. The facts about shared mailboxes below are from Microsoft's own documentation as of September 2026.

What is an Outlook shared mailbox?

A shared mailbox is a Microsoft 365 mailbox that several licensed users can open from their own accounts. It has an address, such as support@ or info@, and members can read it, reply from it, and send as it or on its behalf, depending on the permissions they are given. It needs no license of its own for up to 50 GB of storage, it is not meant to be signed into directly, and only people inside your organization can be members. Microsoft's guidance is that a shared mailbox supports up to 25 users before connection problems and duplicated messages start to appear.

What a shared mailbox does well

Quite a lot, and for free. Everyone sees the same mail. Replies go out from the shared address rather than from an individual, so the customer sees one identity. Permissions are managed by an admin in one place. It works in Outlook on the desktop, on the web and on mobile. Categories, flags and folders give a team a lightweight way to mark state, and inbox rules can do basic sorting. If your team is small, the volume is modest, and everyone is disciplined about categories, a shared mailbox can run a support address for years.

The five places it stops

1. Nobody owns anything

A shared mailbox has no concept of assignment. A message is either read or unread, and read by whom is not recorded in any way the rest of the team can see. Teams work around this with categories named after people, or a rule that whoever opens it owns it, and both work until the day two people reply to the same customer or nobody replies at all because each assumed the other had it. The collision problem is the one that usually sends teams looking.

2. Who replied, and what they said, lives in Sent Items

Replies sent as the shared mailbox land in the shared mailbox's Sent Items, and replies sent from a member's own account land in theirs. Reconstructing what a customer was told last month can mean checking several Sent folders and hoping the thread stayed intact. There is no internal note on a message, so the context a colleague needs gets forwarded, or said out loud, or lost.

3. State is a convention, not a system

Categories and flags are shared, but they mean whatever the team agreed they mean, and there is nothing to enforce it. A flag that means waiting on customer to one person means follow up on Friday to another. The tooling cannot tell you how many messages are waiting on a reply from your side, how old the oldest one is, or who is carrying the most, because none of that is modeled.

4. It reacts to messages; it does not remember relationships

A shared mailbox holds every message a client ever sent, and that is exactly all it holds. What was promised in a thread from March, whether the client's question in paragraph three ever got answered, and the fact that a client who used to write weekly has not written in a month are all in there somewhere, but nothing surfaces them. Search finds what you already know to look for.

5. The practical limits

Fifty gigabytes without a license, and a license is needed for a larger mailbox, for archiving or for litigation hold. A soft ceiling of 25 users. No direct sign-in, so mobile access goes through a member's account. No external members. Encryption from the shared address is not available because the mailbox has no security context of its own. None of these is a defect. They are the boundaries of a feature that was designed for a front desk, not for a team running client relationships at volume.

How to tell which side of the line you are on

• Count the double replies and the dropped threads in the last quarter. More than a couple means ownership is the problem, and no category scheme fixes it.
• Ask how long it takes to answer where do we stand with this client. If the answer involves three Sent folders and a colleague's memory, the mailbox has stopped being a system of record.
• Look at who writes in. Mostly new names: a queue, and a queue tool or a well-run shared mailbox will do. Mostly the same names: relationships, and the mailbox is carrying context it cannot show you.
• Check the storage and the member count against the limits above. Growth alone can force the decision.

What to look for in a shared inbox tool for Outlook

Most shared inbox tools grew up on Gmail, and Microsoft 365 support ranges from complete to nominal. Before anything else, confirm that the tool connects a shared mailbox itself, not only individual user mailboxes, that it authenticates through Microsoft's OAuth consent flow rather than a stored password, and that it handles the admin consent step some tenants require. Then the practical questions: do categories and flags keep their meaning on both sides, does Focused Inbox still mean something, and does the shared mailbox stay in Microsoft 365 with the tool working on top of it, so the exit is a disconnect rather than a migration.

After that, the questions are the same as for any team: ownership and assignment, internal notes on the thread, collision detection, and whether the tool models anything beyond the message. Queue tools add assignment and state and stop there, which is right for a support address. Relationship tools add a record of each client: what was promised, what is unanswered, and how the relationship's rhythm is trending.

Where Sektra fits

Sektra connects Microsoft 365 mailboxes, including shared mailboxes, over Microsoft's consent flow, and the shared mailbox stays in Microsoft 365 underneath. Categories map to tags, flags to stars, and read state moves both ways, so colleagues who never open Sektra see the same state in Outlook. On top, every thread gets an owner, notes and collision detection, and the memory layer reads the existing mailbox history to build a record per client: commitments, open questions, and each relationship's normal cadence, so a quiet account is flagged while it is still recoverable. The Outlook integration page covers the setup details and the admin consent step.

Keep the shared mailbox if it is working. Free and familiar are real virtues. The moment to look further is when the team is paying for its limits in dropped threads, double replies and clients nobody remembered to check on, because by then the mailbox is no longer free; it is just unbilled.