Office 365 is available in a number of plans. Small business owners, like myself, find the low-cost entry point of Plan P1 very attractive while larger enterprises will find that the “E” plans better suit their needs (see this blog post for more information on the differences between Plans E and P). All hosting environments impose some limitations on users to prevent them absorbing more than their fair share of resources and this is the case in Office 365 where recipient limits are one of the more obvious restrictions that you might run into.
The recipient limit determines the total number of recipients to which a mailbox can send messages to in a 24-hour rolling period. Plan P sets a recipient limit of 500; Plan E increases the limit to 1,500 (see the Office 365 help for more detail). A recent ZDNet article advised small businesses to pay attention to the small print of Office 365 plans (good advice in itself) and cited recipient limits as an example. The article quoted Microsoft’s justification for setting recipient limits at these values as:
“In the world of email, one of the thresholds that must be enforced is the amount of email that is sent through the system by any one user or organization in order to combat spam, mass-mailing worms & viruses.”
This is reasonable as no hosting provider wants to get themselves into the situation where they are the host for a spammer. It’s fair and reasonable to impose a block on anyone sending vast quantities of spam to all and sundry. The problem here is that the limits chosen by Microsoft might be a tad low. That, allied to the fact that there’s no way for Office 365 support to release the guillotine if a user inadvertently exceeds the limit, creates the potential for customer dissatisfaction.
Consider the scenario where someone is sending messages to customers to inform them of a new business offer and therefore blasts out an email to all customers in their address book to then find that they have hit the limit and cannot send any further email until the 24-hour block elapses. They can continue to receive email but any attempt to send a response is rejected by Exchange. This isn’t good because it’s unlikely that many of the small businesses who use Office 365 Plan P will be aware of or understand recipient limits. On the other hand, it’s yet another example of how Microsoft has thoughtfully left a gap for other hosting providers to fill by offering similar plans and price points to those available with Office 365 but with higher limits.
But how are the recipient limits implemented? Apart from the help file (and who reads those unless absolutely necessary?), there’s no trace of any setting that an Office 365 tenant administrator can assign to a mailbox, at least not on the surface. But if you care to fire up PowerShell and poke around behind the scenes we can find out how recipient limits are applied.
First, you need to connect a remote PowerShell session to your Office 365 domain. Brian Desmond has published a tip showing how to insert some code in your PowerShell profile to make connections easy and there are many articles available that explain the various steps that are needed to connect. I’ll assume that you can do this and arrive at a point where you’re connected and ready to go.
Every Office 365 mailbox is assigned a mailbox plan that defines the settings that are applied to that mailbox. If you run Get-Mailbox | Select MailboxPlan you’ll see a pointer to the mailbox plan, which will be something like this:
MailboxPlan : eurprd04.prod.outlook.com/Microsoft Exchange Hosted Organizations/xxx.onmicrosoft.com/Defau
lt-f5eda48a-1df7-40ac-b99f-3a73a94f8a8d
This isn’t very human-friendly but just accept that it proves that the mailbox has been assigned a plan. You’re likely to find that there’s just one mailbox plan for a Plan P tenant while Plan E tenants might have several, depending on how many of the E variants they use.
Running Get-MailboxPlan | Format-List reveals all the settings applied to a mailbox or we can apply a filter (see below) to reveal just the settings that refer to recipient limits.
Aha… some light bulbs come on in heads around the world and ask “If I can use Get-MailboxPlan to view recipient settings, couldn’t I use something like the Set-MailboxPlan cmdlet to increase them?” Good idea, but the wonders of RBAC mean that tenant administrators can’t run a command like:
Get-MailboxPlan | Set-MailboxPlan -RecipientLimits 5000
The reason of course is that Exchange’s Role Based Access Control (RBAC) security model filters the available parameters for Set-MailboxPlan so that tenant administrators don’t see RecipientLimits as a valid option (RBAC allows you to define roles to the granular level of suppressing individual parameters for a command). If you attempt to set a value, PowerShell returns an error.
I would have been terrifically surprised had I been able to increase my recipient limit and it’s good to know that RBAC allows me to see information about mailbox plans but stops me playing with limits. While we might disagree with the limits Microsoft has set for the Office 365 plans, it’s nice to understand how they are implemented.
– Tony
This basically means that many SMBs that become aware of these limits before signing up will not be able to sign up for Office 365 email. At 500 and 1500 for the two plan types, both are too low and have no recourse to unlock a user (even if everyone in the company is well below the limits each day but the executive goes over). I can’t tell the executives “wait until tomorrow to reply to that critical email”. I doubt Steve Ballmer would be happy hearing that from his IT department. Imagine his expression.
Including internal emails in the quota and using spam email as the reason has no merit. Internal emails should not be counted at all against a limit.
There is a similar issue with legal hold and discovery in that it only applies to the most expensive plans.
yeah, I am running into this today with an HR person. being unable to clear the limit is not acceptable.