Office 365 releases IP throttling


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 (23)

  1. Jeff Ordon says:

    I use Barracuda Networks for my front end anti-virus/anti-virus scrubbing before forwarding to O365. I am seeing MUCH more deferring from Microsoft for absolutely valid messages. I have the Barracuda block IP's in the safe senders list. Now, Barracuda has had some delivery issues of its own due to DOS attacks in the past two weeks…How do I deal with this issue?

  2. tzink says:

    @Jeff: What sort of SMTP responses are you seeing?

  3. Jeff Ordon says:

    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.

  4. tzink says:

    @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.

  5. Jeff Ordon says:

    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..

  6. tzink says:

    @Jeff: AS815 means it is being blocked by real time IP reputation. Submitting a delisting request should help.

  7. Jeff Ordon says:

    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.

  8. tzink says:

    @Jeff: That's why it is a 4xx response. IP throttling is both sender-history based and time-based.

  9. Jeff Ordon says:

    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…

  10. Brian T. Grant says:

    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.

  11. Brian T. Grant says:

    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.

  12. Michael Exner - Barracuda Service Technician says:

    Barracuda has unsuccessfully requested dozens of times to Microsoft to exempt our IP range from their RBL and Throttling. Our range of 64.235.144.0/20 is used across multiple datacenters for our corporate services and is used by the Barracuda Email Security service for hosted spam and virus filtering.

    Microsoft however refuses to exempt our range from any of their filtering leaving us with only the option of retrying mail until it is eventually delivered.

    As far as I know we are the only major mail service that is treated this way.

  13. rdub says:

    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.  

  14. Noel Negron says:

    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.

  15. Andrea Mondello says:

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

  16. Chris Porosky says:

    We worked this week with Microsoft and Barracuda support.  Of course MS pointed finger at Barracuda, but we ended up proving it was the MS mail servers causing our Deferred / Server Busy email issues.  It seemed that MS doesn't understand that BESS is just passing through the email to the MS servers (it is not storing the email then forwarding it).  Here is the fix that worked for us and was recommended by Barracuda support:

    In the Office 365 Exchange Admin Center

    1. Go to Protection, Connection Filter, edit Default, in IP Allow list add individual entries for 64.235.144.0/24 through 64.235.159.0/24

    2. Important, also check the box at the bottom "Enable Safe List", then Save.

    3. Optional (not sure if this is required but doesn't hurt):  

    Under Mail Flow, Rules, create new rule, apply If Sender's IP address is in range then enter in each individual BESS IP as #1 above, Condition set to Bypass Spam Filtering, Save.

  17. Email from AOL blocked with error: 451 4.3.2 Server busy. Please try again later. (AS815) says:

    I have a client who got notified by one of his long time business contact with an AOL.com account. AOL.com user got bounced back message

    Reporting-MTA: dns; omr-m3.mx.aol.com

    X-Outbound-Mail-Relay-Queue-ID: 3B8CF38001821

    X-Outbound-Mail-Relay-Sender: rfc822; %AOLuser%@aol.com

    Arrival-Date: Mon,  9 Feb 2015 17:23:41 -0500 (EST)

    Final-Recipient: rfc822; %Office365User%@%userdomain%.com

    Original-Recipient: rfc822;%Office365User%@%userdomain%.com

    Action: failed

    Status: 4.3.2

    Remote-MTA: dns; %userdomain%.com-com01b.mail.protection.outlook.com

    Diagnostic-Code: smtp; 451 4.3.2 Server busy. Please try again later. (AS815)

    What needs to be done?

  18. Bob Neville says:

    how do I stop getting throttled by O365

  19. Chris Porosky says:

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

  20. Andrew Marsland says:

    We've similarly had this issue with emails passing through McAfee's Email protection servers before being sent on to 365. We tried the connection filter method however if you read the detail carefully it's implied that Microsoft have the last word and can/will block the messages anyway.

    The issue was finally resolved when Microsoft whitelisted the McAfee ip's at source.

  21. Nico says:

    What does (AS22) mean?

  22. 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.

  23. Lisa Collins says:

    No matter how many times I try (and it’s been hundreds) to use the Delist IP page, I have NEVER received the Step 2-“An email with instructions has been sent to [my email domain] and my customers are still not receiving emails from me. My log files continue to show:
    Remote-MTA: dns; [CustomersEmailDomain].mail.protection.outlook.com
    Diagnostic-Code: smtp; 550 5.7.606 Access denied, banned sending IP
    [45.79.6.118].

    What can I do to fix this?

Skip to main content