Reply All Storm Protection settings in Microsoft 365

• Author
• Recent Posts

Vignesh Mudliar

Vignesh has been working in the IT industry for the past 10 years. His main areas of focus are Microsoft 365, Exchange Online, PowerShell, Teams, SharePoint, Microsoft 365 Security, and GoLang. Follow his weblog.

Latest posts by Vignesh Mudliar (see all)

• Microsoft 365 mail flow reports in the Exchange Admin Center - Tue, Jul 20 2021
• Understanding Microsoft 365 Attack simulation training - Wed, Jun 23 2021
• Reply All Storm Protection settings in Microsoft 365 - Wed, Jun 16 2021

Reply All Storm Protection was rolled out in 2020 and was welcomed by the community. After all, it was the first time since the infamous Bedlam DL3 incident that everyone could sit back peacefully knowing that their users weren't creating a reply all storm. However, there were still some aspects of this feature that needed to be tweaked to suit all organizations. Now Microsoft has also enabled you to control the settings of reply all storm protection.

Background ^

Before we delve into the essence of this article, you need some historical background.

The Bedlam DL3 fiasco

Back in 1997, a Microsoft employee working on a new tool decided to create multiple distribution lists (DLs) and divide all the Microsoft employees equally into them as members. So, each DG had roughly 13,000 members, and each DL was named "Bedlam DL <n>". Quite an ironic name, considering what was to happen.

One day, someone checked the names of the DLs they belonged to and found this rather mysterious DL called "Bedlam DL3". That person then emailed the DL to ask why they had been added to it and asked to be removed.

This email was sent to all the 13,000 members. It triggered a chain reaction in which many other DL members started using Reply All and asked to be removed from the DL. The result was that almost 15.5 million emails were sent within an hour. It led to the entire messaging infrastructure being overwhelmed and took over two days to be restored.

This is how a reply all storm looks and feels. The incident is neatly covered in this article: "Me Too!" As part of the fallout of this disaster, Microsoft introduced some throttling measures in Exchange, such as limiting the number of recipients that can be added to an email. However, this wasn't going to be an enduring fix.

More incidents

In January 2019, another reply all storm was caused by GitHub sending email to over 11,000 Microsoft employees. You can find details about it here. Apparently, someone changed a setting on the corporate GitHub account, triggering email being sent to all those working on GitHub—that's over 11,000 users.

Even as recently as March 2020, there was a lot of talk about another reply all storm incident reported here. Indeed, many other organizations have had to endure such painful incidents all over the world.

It's now abundantly clear that you cannot underestimate the impact of a reply all storm. This led to several requests for protective coverage from this mishap. In the following sections, we'll see what's in store for you as an administrator to control this storm.

What is Reply All Storm Protection? ^

Now that we have discussed reply all storms and their related issues, it's time to get to the crux of this article.

If an email storm occurs in Microsoft 365 tenant, the Reply All Storm Protection feature would detect it and apply the settings that you have configured. Depending on the tenant's settings, it will block additional reply all emails in that email thread.

Is Reply All Storm Protection enabled in the tenant? ^

You can check the configuration in your tenant using this PowerShell script only for now. The command to do so is:

Get-TransportConfig | FL *ReplyAllStorm*

Check whether Reply All Storm Protection is enabled

The value of ReplyAllStormProtectionEnable' is Enabled, which means your tenant is protected. We will look at the other sections below.

What has changed? ^

When Microsoft released the Reply All Storm Protection feature in 2020, they didn't give any controls to the admins. However, with this release, you can modify the settings. Let's look at all those settings in this section.

Enable or disable

The first change is that you can now enable or disable the feature. This can be done via the following command:

Set-TransportConfig -ReplyAllStormProtectionEnabled $true

You can disable the setting, though it's recommended always to keep this setting enabled (true).

Minimum number of replies to all recipients

Next are the attributes that control the behavior of reply all protection in your tenant. Previously, certain values were set by default; now, however, you may modify them as per your tenant's requirements.

The minimum number of reply all recipients can be set to any value from 1,000 to 5,000. This is another change, as earlier this was set to 5,000 by default. Hence, the smaller tenants couldn't really take advantage of Reply All Protection. However, now you can set it to, say, 1,000, depending on your organization. This is controlled by the attribute ReplyAllStormDetectionMinimumRecipients. The following command is an example of how you can modify its value.

Set-TransportConfig -ReplyAllStormDetectionMinimumRecipients 1000

Setting the reply all storm minimum recipients parameter

Minimum number of reply alls

In addition, you can set the minimum number of reply alls to an email. The range is 5–20.

Set-TransportConfig -ReplyAllStormDetectionMinimumReplies 7

Setting the reply all storm minimum replies parameter

Duration of the block

Once a reply all storm is detected, you need to decide how many hours reply all should be blocked for that thread. The default setting is 6 hours; however, it can be set from 1–12 hours. It's better to keep this setting to, say, 6–8 hours, or even more.

If the block period is less, then there is a chance the users could accidently restart the reply all fiasco. Hence, a longer block time would make sense here.

Set-TransportConfig -ReplyAllStormBlockDurationHours 10

Setting the reply all storm block duration parameters

Detection time sliding window

This sliding window signifies the timeframe in which Microsoft 365 considers all the events of an email thread. This setting is still 60 minutes and isn't customizable.

Configure Reply All Storm Protection ^

You can configure the Reply All Storm Protection settings in one command, too:

Set-TransportConfig -ReplyAllStormProtectionEnabled $true -ReplyAllStormDetectionMinimumRecipients 1500 -ReplyAllStormDetectionMinimumReplies 8 -ReplyAllStormBlockDurationHours 10

Configuring all the properties in one PowerShell command

When a reply all storm is detected and a block is applied on that email thread, the users will see the following NDR when trying to use reply all there.

Reply All Storm Protection NDR when a block is in place

You may refer to this post for the same details.

Conclusion ^

This is an important development in the messaging area in Microsoft 365. It will be beneficial to almost all tenants, regardless of their size. Whether Microsoft releases this feature for the on-premises versions of Exchange remains to be seen. However, in my view, the following improvements are needed:

• Reporting—Administrators would benefit from a weekly or monthly report describing the reply all storms that were detected and stopped, or the individuals who were a part of one such storm.
• Exceptions—The ability to create exceptions for some DLs or applications.
• End User Communication—The ability to add something like 'trusted users' so that those users can still reply all to a blocked communication and inform the users about the storm and the resultant block.