Customizable Tenant-level Recipient Limits

[The_Exchange_Team]

Controlling the number of recipients per message that your users can send to is one of several measures email admins can use to help curtail the risk of email abuse and spamming from compromised accounts. Earlier this year the Exchange Online Transport team introduced customizable Recipient Limits in Exchange Online. With it you can customize the setting on a mailbox or mail user object, you can bulk edit multiple existing mailboxes or mail users at the same time, and you can even set the default for new ones. Yet, that update didn’t offer a single, master tenant-wide setting. It gave Exchange Online admins more control than they had before, but it still wasn’t as comprehensive as what Exchange Server on-premises offers.

Today we’re announcing the immediate availability of a super useful extension of the mailbox customizable recipient limits feature that helps deliver a more complete solution: The ability to use Remote PowerShell to customize a tenant-wide recipient limit with the MaxRecipientEnvelopeLimit property on the TransportConfig object (Set-TransportConfig -MaxRecipientEnvelopeLimit).

Similar to how it works in Exchange Server on-premises, the MaxRecipientEnvelopeLimit property is the authoritative or fall back setting for recipient limits when a mailbox’s or mail user’s RecipientLimits property is set to “Unlimited”. Now, just because it says ”Unlimited” doesn’t mean that it is. It actually means “fall back to the next higher level setting,” which for a mailbox or mail user is to fall back to the value on the tenant-level setting, the tenant’s TransportConfig MaxRecipientEnvelopeLimit setting. And “Unlimited” on the tenant-level setting, in turn, means to “fall back to the Exchange Online service-level setting” – which in the Exchange Online multi-tenant environment is currently 1,000 recipients.

Here are the guiding principles in pseudo-code style that the Exchange Online service uses to determine the maximum number of recipients a sender can send to per message:

• If the mailbox or mailuser RecipientLimits property value
  • Is a numeric value then
    • Use that value as the maximum number of recipients a sender can send to per message
  • Else if the mailbox or mailuser RecipientLimits value is “Unlimited” then
    • Use the tenant-level setting (the value on the MaxRecipientEnvelopeLimit property on the tenant’s TransportConfig) instead
    • If the tenant-level setting is also “Unlimited” then
      • Use the Exchange Online service-level setting (1000 as of this writing)

Note: It’s easy to fall into the mistake of thinking that the tenant-level setting is the most-restrictive setting regardless of what the mailbox or mailuser setting is. But that’s not true. As shown above, the only time the tenant-level setting is used is if the mailbox or mailuser setting is “Unlimited.” This is the same as how it works in Exchange Server on-premises.

Here are several examples of how this works:

Mailbox Setting	TransportConfig Setting (tenant-level)	Behavior	Explanation
Set-Mailbox Mailbox1 -RecipientLimits 50	Set-TransportConfig -MaxRecipientEnvelopeLimit 1000	Mailbox1 can send to a maximum of 50 recipients per message.	The mailbox setting is authoritative because the rule is if the mailbox setting is a numeric value (it’s 50) then use that. The tenant-level setting for this mailbox is thus ignored.
Set-Mailbox Mailbox1 -RecipientLimits 50	Set-TransportConfig -MaxRecipientEnvelopeLimit 10	Mailbox1 can send to a maximum of 50 recipients per message.	The mailbox setting is authoritative because the rule is if the mailbox setting is a numeric value then use that. The mailbox setting is 50, so that’s the value that’s used. The tenant-level setting for this mailbox is ignored, even though it’s more restrictive than the mailbox setting.
Set-Mailbox Mailbox2 -RecipientLimits Unlimited	Set-TransportConfig -MaxRecipientEnvelopeLimit 500	Mailbox2 can send to 500 recipients per message.	The mailbox setting is “Unlimited” so the rule is to use the tenant-level setting (500).
Set-Mailuser User1 -RecipientLimits Unlimited	Set-TransportConfig -MaxRecipientEnvelopeLimit Unlimited	User1 mail user can send to 1000 recipients.	The Exchange Online setting (1000) is authoritative because both the mail user and tenant-level settings are “Unlimited” and thus fall back to the service level setting, 1000 recipients as of this writing.

So, managing recipient limits in Exchange Online now works pretty much like it does in Exchange Server on-premises. Do note that one significant difference is that while the default MaxReceipientEnvelopeLimit for new tenants in Exchange Online will still be “Unlimited”, the allowable range for customizing it in Exchange Online is 1 to 1000, while in Exchange Server on-prem the allowable range is from 0 to 2147483647.

While it might appear to be a minor update, we believe this change will prove to be quite valuable for email admins so they can more simply and flexibly manage and control a variety of recipient limits scenarios. It’s a new Exchange Online capability that continues to demonstrate our commitment to delivering more control, more “knobs and dials,” to manage your organization’s mail flow. Let us know what you think!

Kevin Shaughnessy

[Manoj Kumar]

If flag is set to unlimited - why its not unlimited so even if we use command - Set-Mailuser User1
-RecipientLimits Unlimited . We can only send upto 1000 email per message and not more than 1000 ?

[KevinShaughnessy]

@Manoj Kumar - The max allowed in the service is 1000. So even if both your MailUser setting and your TransportConfig (tenant-level) settings are Unlimited the EXO service setting of 1000 is then used. As noted in the article above, "Unlimited" means fallback to the next higher level setting: 

"Now, just because it says ”Unlimited” doesn’t mean that it is. It actually means “fall back to the next higher level setting,” which for a mailbox or mail user is to fall back to the value on the tenant-level setting, the tenant’s TransportConfig MaxRecipientEnvelopeLimit setting. And “Unlimited” on the tenant-level setting, in turn, means to “fall back to the Exchange Online service-level setting” – which in the Exchange Online multi-tenant environment is currently 1,000 recipients."

Hope this helps!

[Manoj Kumar]

Thank you Kevin, this helps and makes sense.

[Rodolfo Trevizo]

Can using Distribution List of greater than 1000 recipients  bypass these limits values?

[Rodolfo Trevizo]

@KevinShaughnessy 

Can using Distribution List of greater than 1000 recipients  bypass these limits values?

[KevinShaughnessy]

@Rodolfo Trevizo Yes, a distribution group (stored in shared address book) counts as one recipient. This is documented in the admittedly long public article, Exchange Online Limits:

For the purposes of the recipient rate limit and the recipient limit, a distribution group that is stored in the organization's shared address book counts as one recipient. In a personal distribution list, each recipient is counted separately. 

Cheers!

Kevin

[JeanNoel]

Hello Exchange Team,

I have a question regarding this limit : is it applicable to meeting invites ?

Have a nice day,

Regards,

Jean-Noël GELIS

[MsPostmaster]

Thanks for this article @The_Exchange_Team 

[KevinShaughnessy]

@JeanNoel sorry for not seeing this sooner. No, it's not applicable to meeting invites - the calendar team chose to hard code the limit for meeting invites at a much higher limit (2.5k for multitenant, 5k for dedicated). At least one of the reasons for that is because if you send out invites to a large DL (e.g. 2k members) that DL gets counted as 1 recipient. But when the recipients ack the invite it adds them to the list of recipients in the originator's meeting. Now if the originator updates the meeting in some way (e.g. changes the date) it will send the message to all recipients (both the DL and the individual recipients who ack'd) and if the recipient count is > than the max for the sender/mailbox then it'd fail to send the update. So having a separate global upper limit for invites was how the Calendar team chose to reduce the chance of that happening for customers. 

Hope this helps and again apologies for the delay!