skip to Main Content

High Risk Delivery Pool and Exchange Online | Part 10#17

The current article is the continuation of the previous article: High Risk Delivery Pool and Exchange Online | Part 9#17
In this article we will focus on the following subjects:

  • How does Exchange Online “decide” to classify particular E-mail as spam\junk mail?
  • Description of the internal spam E-mail message flow

Who is the authority who approves or identifies E-mail as spam/junk mail?

When Office 365 recipients ask to “deliver” E-mail to another recipient, Exchange Online (EOP if we want to be more accurate) must check the E-mail and verify that the E-mail is “OK” or not consider as spam\junk mail.

The “Security scanning process” of outbound E-mail message, is implemented by addressing two types of “security infrastructures”:

  1. Proprietary block lists – that are not “exposed to the general public.”
  2. Third-party (partner) public block lists providers.

Exchange Online Protection (EOP) uses its own proprietary block lists as well as third-party (partner) block lists. If a user added to our block lists after sending outbound messages through the service, they’ll receive a 550 5.1.8 Access Denied, Bad Sender message.

Additionally, the domain administrator address configured via the sends a notification to the following email address when a sender is blocked sending outbound spam setting in the outbound spam policy will receive a message that the sender added to our block lists.

In the following diagram, we can see a “high level” flow of the process, in which Exchange Online scan outgoing E-mail message that is sent by Office 365 users by using the help of the “black and blocklist databases.”

Note – the popular term is “black list” providers. In the Office 365 and Exchange Online articles, the term that used most of the time is: “Block list” providers.
We can relate to these two different terms as synonyms.

Internal spam scenario - mail flow

Q: Who are these “mysterious” Third-party (partner) public blocks lists providers?

A: Information about this “Third-party (partner) public block lists providers” is publicly published

In the article we can see, a list of Third-party (partner) block lists providers who are used by Exchange Online infrastructure.

Exchange Online - Partner block list

Outbound spam scenario flows in an Office 365 environment

To demonstrate the flow of “internal spam E-mail”, let’s use the following scenario:

Office 365 users sent E-mail to a “destination recipient”. The E-mail message is scanned and identified as spam\junk mail.

For this reason, the E-mail is routed to the Exchange Online High Risk Delivery Pool and will be sent by the Exchange Online High Risk Delivery Pool to “her destination”.
The “end” of the scenario is not known because we are not able to find out what is the security policy is, and the rules that will be implemented by the mail destination infrastructure.

Step 1 – Office 365 recipients, send E-mail to an external recipient. Exchange Online server accepts the request.

Outbound spam scenario flow in Office 365 -01

Step 2 – Exchange Online accepts the E-mail, and forward the E-mail to Exchange EOP (Exchange Online Protection) for further analyses.

Outbound spam scenario flow in Office 365 -02

Step 3 – Exchange EOP, accept the E-mail message and, forward the E-mail to the Proprietary block lists + Third-party (partner) block lists.

Outbound spam scenario flow in Office 365 -03

Step 4 – the E-mail is examined by the block lists providers. In our scenario, the E-mail was identified as spam\junk mail.
The block lists a provider send back underlying to Exchange EOP and “inform” EOP that the E-mail is a “problematic E-mail message.”

Outbound spam scenario flow in Office 365 -04
Step 5 – because the E-mail was identified as spam\junk mail, Exchange EOP will not “forward” the E-mail to the standard Exchange Online server pool, but instead, the E-mail forwarded to the “Exchange Online High Risk Delivery Pool.”

Outbound spam scenario flow in Office 365 -05

Step 6 – one of the “High Risk Delivery Pool” members, will try to deliver the E-mail message to the destination mail server.

The underlying assumption is that – the “destination mail server” use security services in which the incoming E-mail is scanned and verified via the blacklist provider and another security mechanism.

In our scenario, there is a high chance that the E-mail be classified as spam\junk mail by the “destination mail server” because the IP address of the Exchange Online High Risk Delivery Pool appears in well-known blacklists.

Note – other possible scenarios is that the E-mail message will be identified as spam\junk mail because of the E-mail content and not because the E-mail sent via the Exchange Online- High Risk Delivery Pool.

Outbound spam scenario flow in Office 365 -06

Step 7 – The Mail security infrastructure that is used by the “destination mail server”.

Each of the “external mail infrastructure” uses a different mail security policy and services.

  • In some scenario, the “destination security mail gateway” will block the E-mail message and reply back with an NDR message.
  • In some scenario, the “destination security mail gateway” will send the E-mail to quarantine.
  • In some scenario, the “destination security mail gateway” Will Increase the value of the SCL (spam confidence level) and forward the E-mail message to the target recipient.

Outbound spam scenario flow in Office 365 -07

An example for NDR message

In the following section, we can see an example of an NDR message that returned to Office 365 recipients by the “destination mail server.”

P.” attention to the IP address that appear on the NDR message. This is an IP address that “belong” to the IP range of the “High Risk Delivery Pool”

Remote Server returned ‘550-5.7.1 [ ] our system has detected an unusual rate of 550-5.7.1 unsolicited mail originating from your IP address. To protect our 550-5.7.1 users from spam, mail sent from your IP address has been blocked. 550-5.7.1 Please visit to review 550 5.7.1 our Bulk Email Senders Guidelines. p10si13699322wje.90 – gsmtp’

Recap and final conclusions

In a scenario in which we are notified, that mail that was sent from our organization is classified as spam\junk mail the main question now is:

What is the reason (the causes) that mail sent from our organization identified as spam\junk mail? Or in simple words: who can we blame?

  • Is it the Office 365 users?
  • Is it the specific E-mail message content?
  • Is it the Exchange Online server who route the E-mail message to the “High Risk Delivery Pool”?
  • Is it the “High Risk Delivery Pool”?
  • Is it the Office 365 blacklist providers?
  • Is it the destination mail security gateway?

Most of the time, our natural tendency will be to blame the “other side”. The “other side” could be the destination mail server or in our scenario, the Office 365 mail servers.

The actual answer is that in most of the scenarios the opposite truth.

The element that is responsible (guilty) for the reason in which E-mail message that was sent by our organization user identified as spam\junk mail is located on “our side”!

If we want to be very specific: the Office 365 users who “write and send the particular E-mail message”.

The “source of the problem” start with the “problematic E-mail message” that was created by the Office 365 users. The “problematic E-mail message” Is the root of all the rest of the process.

Note – in a scenario of malware, the “problematic E-mail message” is created by the malware and not by the user himself.

When Exchange Online recognizes the E-mail that was created by the Office 365 user as spam\junk mail, he routes the E-mail to Exchange Online “High Risk Delivery Pool” and so on.

When the E-mail reaches his destination, there is reasonable chance that the “destination mail server” will block the E-mail because the E-mail was sent by the Exchange Online- High Risk Delivery Pool or, because he also “sees” to a questionable content of the E-mail .

My mail consider as spam mail - Who to blame

The o365info Team

The o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *