Shared Mailboxes: The Blind Spot in Your Microsoft 365 Monitoring

This blog is part of a series of technical articles on Microsoft 365 products in general and Microsoft Teams specifically.

Shared mailboxes are one of those things that exist in every Microsoft 365 tenant but rarely get the attention they deserve. They’re not glamorous. They’re not exciting. And with everything else going on in a typical IT environment, from Teams call quality issues to new features rolling out and network migrations, they tend to just sit there doing their thing.

So, let’s dive into this somewhat overlooked topic and why it matters.

Your support@, info@, helpdesk@, billing@ addresses are often the first touchpoint customers have with your organization and a crucial part of internal operations. They handle critical communication streams: customer complaints, invoice disputes, internal IT requests. And yet, they fall into this weird no man’s land. They don’t belong to a specific person. There’s no user logging in every morning thinking: “hmm, something feels off today.” Instead, five, maybe ten people dip in and out during the day, and every one of them assumes someone else has it covered.

Most M365 admins work with shared mailboxes daily, but there are a few characteristics that tend to catch people off guard.

Free, unlimited, and ungoverned. Shared mailboxes up to 50GB don’t require a license (note: users using them do need to have an Exchange subscription) and there is no limit to how many Shared Mailboxes you can create per tenant. Great for the budget, not so great for governance. In practice this means shared mailboxes tend to accumulate over the years without anyone keeping track.

25 users is the safe maximum. Microsoft states that a shared mailbox supports up to 25 concurrent users. Beyond that, connection failures and weird sync issues can occur. For a busy support mailbox during peak hours, that limit of 25 users is easier to hit than you’d think. Microsoft actually recommends using a Microsoft 365 Group instead but that raises a whole different set of questions on why you should use either a shared mailbox or a M365 Group. For now, let’s use what Copilot’s has to say about that when asked about the difference: “Shared Mailboxes are better used when the mail in it is the work (HR@…, Support@…, Etc.), while a Microsoft 365 Group is used to support the work”.

No encryption on outbound mail. Because a shared mailbox has no security context of its own (no username/password), emails sent from it can’t be encrypted. If members would encrypt with their own keys, other members wouldn’t be able to read those messages.

Licensing would unlock more than just storage. Most organizations run shared mailboxes unlicensed. That works fine until you need litigation hold, in-place archiving, Microsoft Defender for Office 365, eDiscovery, or retention policies. All of these require assigning a license (typically Exchange Online Plan 2). Many admins only discover this gap when legal or compliance actually comes knocking.

Legacy mailboxes may behave differently. Unlicensed shared mailboxes created before July 2018 were provisioned with 100GB instead of 50GB. If you’re wondering why some of your mailboxes have more space than others, that’s likely why.

If reading the above made you want to check what’s actually going on in your tenant, here’s where to look.

In the Microsoft 365 Admin Center, go to Teams & Groups > Shared mailboxes for a dedicated overview. For storage and quota info, go to Reports > Usage > Exchange > Mailbox usage and switch the dropdown at the top right to “Shared.”

Alternatively, use PowerShell to get info:

will provide you with all info available. Note! Microsoft recommends using

instead for any Exchange Online environments.

It is worth doing an audit periodically. You might be surprised by how many shared mailboxes exist that nobody actively uses or even remembers creating.

So, we know shared mailboxes are free, easy to create, hard to track, and central to business communication. The Admin center provides information on usage, storages and quotas but what about performance monitoring?

Reality is that when users report “it’s slow”, in most organizations IT starts guessing…

Shared mailboxes are created in the region where the tenant resides. For organizations with offices across multiple geographies, that means users may be accessing mailboxes hosted on the other side of the world. Some latency is expected in those cases, but the question is: how do you tell the difference between normal geographic delay, a network problem, or actual service degradation?

The short answer is, without active measurement, you can’t.

The Microsoft admin center won’t help you here. It gives you mailbox counts, storage stats, and quota info. What it doesn’t give you is actual access performance data from the user’s perspective.

At panagenda, we work closely with our customers to identify where more insight into user experience is needed and Shared mailboxes kept coming up. That’s why we’re currently in the final phases of testing new M365 scans that measure shared mailbox access latency per user, identify which backend servers are involved, and surface performance differences across regions and locations.

Contact us if you’re interested in learning more about these and other Exchange scans that we are planning to release. As “somebody will probably notice”, is not a reliable monitoring strategy. Especially not when it comes to the mailboxes that make your organization run smoothly.