Office 365 releases IP throttling

Update: This blog post is being deprecated and information has been moved to Configure mail flow using connectors in Office 365


One of the improvements to the Exchange Online Protection (EOP) service, also known as Office 365, that has been released over the past few weeks is IP throttling [1].

Office 365’s implementation looks at IP reputation, inspects the IP’s sending history, and makes decisions about whether or not to allow the message. The idea behind this is that spammers will routinely rotate through IP addresses every single day. The IP has no sending history and is not on any IP reputation list. So, they spin up a new spam campaign and pump as much spam through as they can before these reputation lists can catch up.

It was a pain point for our customers for a few months this year because of a new spammer that we saw that made extensive use of this.

No more.

Office 365 now makes use of basic IP throttling where sending email from a brand new IP is no longer advantageous; indeed, it now works against senders. For spammers, this is bad and for our customers, this is good. It means that this type of spam is greatly reduced (our internal statistics show a major decrease in spam from new IPs because of this). But the flip side is that there are lots of good senders that spin up email from new IPs, or have erratic sending patterns, but are not sending spam. Unfortunately, they sometimes trip up the same IP throttling patterns. We try to fix these as we encounter them.

If you do see an error related to this, it will resemble 451 5.7.500-699 (ASxxx) Please try again later.

There are three possible ways to fix this.

  1. If you are an Exchange Online Protection (EOP) customer who is trying to relay email from your on-premise email server through Office 365 out to either another receiver (hosted by Office 365 or a 3rd party), or to another user within your own organization, then to remove throttling from this scenario you should setup a connector to configure mail flow from your email server to Office 365.
  2. If you are an EOP customer who is receiving inbound email but you have another 3rd party service or on-premise appliance in front of Office 365, then to remove throttling from this scenario you should setup a connector to apply security restrictions to mail sent from your partner organization (or on-premise device) to Office 365.
    For either (1) or (2), you can validate your connectors in Office 365.
  3. If you are not an EOP customer (e.g., you are a 3rd party service), the error resolves itself as you slowly ramp up your email traffic over a period of a few days and you establish a sending history into the service.

That’s one of the recent changes to Office 365, as of January 2015. As always, if you have problems, you can open a support case per the following:


If you want to say “Hey, good to see this!”, let us know.

[1] My description of the algorithm we use is purposefully vague but you get the general idea.