MDO Licensing Required for Shared Mailboxes but Not for Groups

Some Microsoft representatives expressed disappointment after the publication of the article about unexpected costs to license shared mailboxes for Microsoft Defender for Office 365 (MDO). They felt that I didn’t do MDO justice. Let me be clear: MDO covers a wide range of functionality to protect user communications (not just email, but also Teams and the Office apps) from threat. MDO Plan 2 also includes some neat SOC and attack simulation tools. Overall, MDO Plan 2 is a strong package that adds a lot of value to the Office 365 E5 and Microsoft 365 E5 SKUs.

The point of the article was not to discuss MDO capabilities. Instead, it turned a light on the unexpected licensing consequences of MDO becoming active within a tenant. Once MDO protects tenant communications, all user mailboxes and all shared mailboxes must be licensed for MDO Plan 2. That’s an unfair and unexpected consequence of upgrading a tenant from E3 to E5 licenses, something that Microsoft wants customers to do.

Indeed, at the analyst call following quarterly Microsoft results, CFO Amy Hood invariably mentions the success Microsoft has in driving higher Average Revenue Per User (ARPU) due to E5 upgrades and add-on licenses. In the Q4 FY25 call, she noted “ARPU growth again driven by E5 and M365 Copilot.” This kind of management commentary must have an effect on those who make licensing decisions for products.

Microsoft pointed out to me that they have not changed their guidance or documentation on this topic. This is accurate. The same guidance has been in place for several years. The MDO service description covers licensing, and anyone who takes the time to peruse that text will discover just how many MDO licenses their tenant needs. In terms of unexpected licensing consequences, if you don’t read what Microsoft says about a product, you won’t understand the rules of the game and surprises are almost inevitable.

Consequences of Previous Microsoft Decisions

But here’s the thing. The situation around MDO licensing for shared mailboxes is the consequence of two Microsoft decisions taken in the past. The first is that when Exchange Server launched shared mailboxes, Exchange created a user account for each shared mailbox. In an on-premises environment, the extra user accounts made no difference to licensing costs.

Entra ID and Exchange Online took the on-premises model and applied it to the cloud. I’ve often been critical of Entra ID’s inability to identify utility accounts used for purposes like shared and room mailboxes or break glass accounts. Treating these accounts like regular user accounts is nonsense. Failing to disable the accounts created for utility Exchange objects is silly, and allowing people to sign into those accounts (which creates a whole new can of licensing worms) isn’t much better. Exchange Online uses accounts for shared mailboxes like it does on-premises, and that’s the root of the problem created for MDO licensing.

Shared Mailboxes and Group Mailboxes Can Receive and Send Mail

Microsoft says that they require MDO licenses for shared mailboxes because the mailboxes can send and receive email and therefore benefit from the MDO service. Well, the group mailboxes created for Microsoft 365 groups can also send and receive email and those mailboxes support many (but not all) of the features found in shared mailboxes. The fact is that the current implementation of mail-based Microsoft 365 groups (Figure 1) operate very much like shared mailboxes when it comes to sending and receiving mail. Both types of mailbox receive the same level of protection from MDO.

Overall, Microsoft 365 groups are used far more extensively than shared mailboxes, mainly to support Teams, but I can’t find a single reference to an MDO licensing requirement for Microsoft 365 groups in the MDO service description. The reason why MDO ignores licensing for Microsoft 365 groups is simple: Microsoft 365 groups don’t have any form of Entra ID account. They exist as an Entra ID group that just happens to be connected to a set of resources like a plan, team, SharePoint site and group mailbox.

It’s possible to assign licenses to a Microsoft 365 group, but only for the purpose of group-based license assignments managed through the Microsoft 365 admin center (you can also manage group-based license assignments with PowerShell). Because Microsoft 365 groups don’t have user accounts, they don’t follow the normal licensing regime, so MDO cannot be licensed.

Drop the Need for MDO to License Shared Mailboxes

Microsoft has long recommended that customers should replace distribution lists and shared mailboxes by Microsoft 365 groups. Indeed, a great deal of engineering effort went into the addition of capabilities like delegated send for Microsoft 365 groups. After 2019, Microsoft dedicated less attention to the email side of Microsoft 365 groups because of the emphasis on Teams, but the debate about whether to use Groups or shared mailboxes remains active.

Today, far fewer Microsoft 365 groups support email-based communication than those used with Teams. However, the fact remains that a dichotomy exists between how MDO treats the licensing of shared mailboxes and Microsoft 365 groups.

A case could be argued that email-based Microsoft 365 Groups operate by distributing copies of email to group members, and those user accounts should have MDO licenses. That’s true, but group mailboxes receive email processed by MDO, just like shared mailboxes do, so shouldn’t the same rule apply? To solve the conundrum, Microsoft should simplify the situation by dropping the need for MDO licenses for shared mailboxes. I suspect that internal budgets, revenue recognition, and a myriad of other issues will stop this happening, but that’s what should be done.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365. Only humans contribute to our work!