Persistently Vulnerable Exchange Servers: prepare for email throttling & blocking

[Update]: There was a change in the rollout timeline. We’ve also shown how to pause email throttling and blocking if your Microsoft 365 tenant is affected.

Microsoft throttles and even blocks emails sent from Exchange Server to Exchange Online. The transport-based enforcement system reports emails sent from vulnerable Exchange Servers and gradually delays and blocks mail flow to force admins to update their on-prem environments. This is to ensure superior security of Microsoft 365 organizations. See if the feature affects you and what you can do to keep your mail flow running.

Transport-based enforcement system blocks emails from persistently vulnerable Exchange servers

Who will be affected by the new Exchange throttling policy?

According to this Exchange Team article, the update is aimed to combat “persistently vulnerable Exchange Servers”.

The system will be rolled out in stages. At first, the transport-based enforcement system will only apply to Exchange Servers that connect to Exchange Online using an inbound OnPremises connector. In other words, only hybrid environments will be affected at first. However, according to Microsoft, the system’s primary objective is to prevent potentially malicious emails from entering Exchange Online and to force organizations to patch their on-premises servers. So it’s safe to expect that eventually it will also affect organizations that fail to secure their on-prem environments, even when they’re not in hybrid.

Transport-based enforcement system applies only to high-risk environments, that is “persistently vulnerable Exchange Servers”. Let’s see what it means.

What is a persistently vulnerable Exchange Server?

A persistently vulnerable Exchange Server is an Exchange Server instance for which there are known vulnerabilities that have not been addressed yet. So, if there is a security update (SU) you’ve been saving for later, know that the clock is ticking.

The bigger problem is when you’re on an Exchange Server version that has reached its end of life (or “end of extended support” if you prefer official names). This means that this version will not receive any further SUs. In other words, it’s in the transport-based enforcement system’s crosshairs already.

How to check if my tenant is affected?

The Exchange admin center (EAC) features reports dedicated to this specific scenario. Head on over to the Exchange admin center > Reports > Mail flow > Out-of-date connecting on-premises Exchange servers or use this direct link.

You can also connect to your Exchange Online organization using Connect-ExchangeOnline and then run

Get-OnPremServerReportInfo

If you get the following message, there’s nothing you need to do at the moment.

PowerShell cmdlet Get-OnPremServerReportInfo

Email throttling & blocking timeline

There are two timelines that apply to Exchange Server’s mail flow throttling and blocking:

  • Transport-based enforcement system’s stages. In other words, how the system handles reporting, throttling and blocking.
  • Feature rollout. Since the email throttling and blocking can potentially affect (and harm) multiple organizations, Microsoft starts with the oldest on-premises environment that supports hybrid and will gradually add newer (less vulnerable) servers.

Transport-based enforcement system stages

There are 8 stages in total. Stage 1 begins as soon as the system detects a non-compliant server. If the vulnerability is not resolved, the system will progress to the next stage after a specified period of time.

The first stage lasts 30 days, each next stage lasts 10 days.

  1. For the first 30 days, non-compliant server(s) will appear in the new mail flow report. During this period, there is no email throttling or blocking. It’s a warning phase that gives time to install the newest SU.
  2. Mail flow throttling begins. For 5 minutes every hour, emails will bounce with an SMTP 450 error. As a result, email delivery will be delayed.
  3. Throttle increases to 10 minutes per hour.
  4. Throttling period increases to 20 minutes per hour.
  5. Throttling caps at 30 minutes per hour. Email blocking begins. Since this moment, for 5 minutes every hour, Exchange Online will bounce emails with a permanent SMTP 550 error. Those emails will not reach final recipients and senders will need to send them again.
  6. Blocking period increases to 10 minutes per hour.
  7. Blocking period increases to 20 minutes per hour.
  8. The final stage, enforced after 90 days of non-compliance. That’s when all emails from vulnerable server(s) will be blocked.

Rollout stages

The transport-based enforcement system will be introduced gradually. The start date is when a certain Exchange distribution (version) will be first scanned for vulnerabilities and the Stage 1 Enforcement can begin. So, if your Exchange 2019 is patched, it will not be treated as persistently vulnerable.

The original timeline was changed, the dates below are the most up-to-date information we have. I wouldn’t treat them as set in stone, though.

  1. August 9, 2023 – Exchange 2007
  2. September 23, 2023 – Exchange 2010
  3. December 22, 2023 – Exchange 2013
  4. March 21, 2024 – Exchange 2016 & 2019

Exchange Team revealed plans relating to the Transport Enforcement System

Ways to stay compliant

To prevent mail flow throttling and blocking don’t be behind with security updates of your Exchange Server. And, above all, make sure you don’t have any unpatched Exchange 2007 lurking somewhere in the basement.

If you have some legacy third-party solution that depends on an old Exchange 2010, it might be a good time to look for alternatives.

A short-term solution is to pause enforcement. You can request this option directly from the EAC mail flow report and you can use this option for up to 90 days per year to temporarily stop mail flow throttling and blocking if you let the system get beyond the Stage 1 (see enforcement stages). It’s an option that will be probably used a lot. Many companies follow a policy to wait before deploying SU on production environment to prevent rollbacks in case something breaks after an update.

The 90-day limit is reset on the first day of the year.

Unfortunately, you won’t be able to ensure your on-premises environment’s security if you have an Exchange version that has reached its end of life. In this case, the only real way to move forward is to migrate to a supported Exchange version or to a cloud only environment.

How to pause throttling and blocking by transport-enabled enforcement system

There are two ways to pause throttling and blocking of affected Exchange servers. Using either of them, you can ensure that your Microsoft 365 receives emails, even when your connected on-premises servers are not on schedule when it comes to updating.

In the Exchange admin center

Head over to Exchange admin center > Reports > Mail flow > Out-of-date connecting on-premises Exchange servers > Enforcement Pause. You will see this option only if you have servers that were identified by the transport-enabled enforcement system as persistently vulnerable.

Using PowerShell

  1. First, connect to your Exchange Online organization using Connect-ExchangeOnline,
  2. Then, use the cmdlet below to check if there is an active enforcement pause:
    Get-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer
    Side note: The documentation on the cmdlet is limited at the moment. That’s why I’ll add that there are two additional blocking scenarios that you can check using it. To do this, change the “-BlockingScenario” attribute value to: TenantRelayMessageRate or TenantOnPremRate.
  3. Next, run the following cmdlet to create a pause (effective immediately) or to extend the pause that’s already in place:
    New-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer -Number of Days /* Value up to 90 */

Interestingly, currently there is no cmdlet to cancel the enforcement pause, after you’ve updated the affected servers.

How to migrate?

Migration under the pressure of time poses a lot of risks. Quite ironic, since in this scenario the migration is forced by a feature that should counter risks.

To migrate with confidence, use a dedicated migration tool. This way, you can benefit from:

  • 24/5 technical assistance from people who handle complex migration projects on a daily basis.
  • Streamlined and simplified migration process (no scripting or complex planning).
  • Advanced reporting.
  • Unlimited delta migrations to make sure each mailbox item is migrated.
Tools for Microsoft 365

5 thoughts on “Persistently Vulnerable Exchange Servers: prepare for email throttling & blocking


  1. Running Exchange 2013 on Server 2012 R2 – and when connected to exchange-online via powershell 5.1 with my own creds, trying to run this command:

    Get-OnPremServerReportInfo but getting ” is not recognized as the name of a cmdlet”

    Is it my creds ? something else?

    • My bet is that you either have insufficient permissions (although the role required to run this cmdlet is pretty basic: View-Only Recipients) or you are using an outdated Exchange Online PowerShell module. Are other cmdlets working for you? You can try updating the PowerShell module by using the following cmdlet (remember to run PowerShell console with admin permissions):
      Update-Module -Name ExchangeOnlineManagement
      Once updated, reconnect and check if any other Exchange Online cmdlets are working when using your credentials. If the issue persists, you can try updating to PowerShell 7 (or install it on another machine and try there).

  2. unfortunately, I have just tried the command
    New-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer -NumberOfDays 90
    in powershell (after succesfully checking that the date throttling starts is this sunday, unfortunately it’s sat with a blinking cursor for the past 15 minutes
    Even checking
    Get-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer
    It just sits there
    anyone else enabled this delay successfully?

  3. We have sevral Exchanage 2010 servers due to legacy systems and are now being throttled for rmwial from Exch to O365. Is there no way around this, except for upgrading then ?

    • Unfortunately, the only real way to move forward is to upgrade to a supported Exchange version or to a cloud only environment. That’s why Microsoft announced the transport-based enforcement system earlier and is implementing it gradually. If the legacy systems you mention are based on Exchange 2010, this may be a sign that they also require upgrading.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

CodeTwo sp. z o.o. sp. k. is a controller of your personal data.
See our Privacy Policy to learn more.