Share via


Office 365 releases IP throttling


Update: This blog post is being deprecated and information has been moved to docs.microsoft.com: 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.

Comments

  • Anonymous
    January 07, 2015
    The comment has been removed

  • Anonymous
    January 07, 2015
    @Jeff: What sort of SMTP responses are you seeing?

  • Anonymous
    January 07, 2015
    a lot of deferred messages, with the response "4.3.2 server busy Please try again later". They seem to eventually get delivered, but it can be a while. It doesn't seem to be every host. But, we have a lot of informational messages (i.e. online order confirmations) coming from the same domain that seem to get held up. We also have a lyris listserve that it happens to as well.

  • Anonymous
    January 08, 2015
    @Jeff: Is there a number after that error message (e.g., ASxxx)? That will help because it tells us what kind of block it is; you can send a delist request to delist at messaging dot microsoft dot com with the IP (or IPs) along with the error message including the ASxxx and we can take a look.

  • Anonymous
    January 08, 2015
    Thanks... The AS number on most that I see is AS815 I also see this once in a while "451 Temporary local problem - please retry later" What does as815 mean? I will send a note off in the next day or so..

  • Anonymous
    January 09, 2015
    @Jeff: AS815 means it is being blocked by real time IP reputation. Submitting a delisting request should help.

  • Anonymous
    January 11, 2015
    That doesn't make any sense... These domains (and there are MANY) that get these as815 deferrals eventually get their messages delivered. It can take anywhere from 30 to 60 minutes but they do get through.

  • Anonymous
    January 12, 2015
    @Jeff: That's why it is a 4xx response. IP throttling is both sender-history based and time-based.

  • Anonymous
    January 12, 2015
    I see... unfortunately, that is a problem.. We are an association of Attorneys..Our annual meeting is this month, so we are having firms email us frequently that might have not emailed us for months. The amount of IP's I would need to delist would be large..so I guess I will just pick a few..disappointing...

  • Anonymous
    January 18, 2015
    This was introduced at least last month to some of my customers' tenant from my understanding from MS. And creating connectors or Transport Rule for IP addresses is supposed to be the solution.

  • Anonymous
    January 19, 2015
    we have had two incidents now at the beginning of December and January where our Relay serfvice was refused connections and it took hours and sometimes days before hundreds of mails were sent.

  • Anonymous
    January 26, 2015
    The comment has been removed

  • Anonymous
    January 30, 2015
    This month we've had several incidents where our mail was deferred significantly, as we use the Barracuda Email Security Service to scan for incoming spam.  Today I saw one example incoming email that was delayed over 90 minutes as a result, and left me with a very unhappy user.  We've used Barracuda for years very happily, and have begun moving in the direction of Office 365 over the past year with about 10% of my users in Office 365 now.  But if emails aren't getting through, the cloud doesn't look like a good enterprise solution.  

  • Anonymous
    February 03, 2015
    We are experiencing the same thing (sporadic message delays).  We are an NGO which relies greatly on good communication systems.  One missed or late communication can result is a loss of millions of dollars in lost opportunity.  Microsoft needs to address this immediately.

  • Anonymous
    February 03, 2015
    As a Microsoft Partner, I can tell you that the Barracuda blocking is a HUGE issue. MSFT needs to rectify this FAST!

  • Anonymous
    February 06, 2015
    The comment has been removed

  • Anonymous
    February 09, 2015
    The comment has been removed

  • Anonymous
    February 24, 2015
    how do I stop getting throttled by O365

  • Anonymous
    February 24, 2015
    see the throttling workaround I posted in my Feb 6, 2015 comment. Microsoft support is completely oblivious.

  • Anonymous
    February 24, 2015
    The comment has been removed

  • Anonymous
    May 21, 2015
    What does (AS22) mean?

  • Anonymous
    January 26, 2017
    So... Because you lack a proper spam detecting techniques you decided to break busy servers by using a extremely restrictive policy on perfectly clean IP addresses that you did not see lately... We run a service that scrubs and sends out e-mail for thousands of legitimate businesses and we had to change IP's yesterday because of a migration. Guess what happened! I literally had thousands of e-mails stuck in my queues. I sincerely fail to see how legitimate e-mail being delayed for hours for your customers is 'good' as you state in the article, but ok, we worked around it.

  • Anonymous
    May 16, 2017
    The comment has been removed