Edit

Outbound delivery pools

Tip

Did you know you can try the features in Microsoft Defender XDR for Office 365 Plan 2 for free? Use the 90-day Defender for Office 365 trial at the Microsoft Defender portal trials hub. Learn about who can sign up and trial terms here.

Email servers in the Microsoft 365 datacenters might be temporarily guilty of sending spam. For example, a malware or malicious spam attack in an on-premises email organization that sends outbound mail through Microsoft 365, or compromised Microsoft 365 accounts. Attackers also try to avoid detection by relaying messages through Microsoft 365 forwarding.

These scenarios can result in the IP address of the affected Microsoft 365 datacenter servers appearing on third-party blocklists. Destination email organizations that use these blocklists will reject email from those Microsoft 365 messages sources.

High-risk delivery pool

To prevent our IP addresses from being blocked, all outbound messages from Microsoft 365 datacenter servers that are determined to be spam are sent through the high-risk delivery pool.

The high risk delivery pool is a separate IP address pool for outbound email that's only used to send "low quality" messages (for example, spam and backscatter. Using the high risk delivery pool helps prevent the normal IP address pool for outbound email from sending spam. The normal IP address pool for outbound email maintains the reputation sending "high quality" messages, which reduces the likelihood that these IP addresses appear on IP blocklists.

The possibility that IP addresses in the high-risk delivery pool are placed on IP blocklists remains, but this behavior is by design. Delivery to the intended recipients isn't guaranteed, because many email organizations don't accept messages from the high risk delivery pool.

For more information, see Control outbound spam.

Note

Messages where the source email domain has no A record and no MX record defined in public DNS are always routed through the high-risk delivery pool, regardless of their spam or sending limit disposition.

Messages that exceed the following limits are blocked, so they aren't sent through the high-risk delivery pool:

Bounce messages

The outbound high-risk delivery pool manages the delivery of all non-delivery reports (also known as NDRs or bounce messages). Possible causes for a surge in NDRs include:

  • A spoofing campaign that affects one of the customers using the service.
  • A directory harvest attack.
  • A spam attack.
  • A rogue email server.

Any of these issues can result in a sudden increase in the number of NDRs being processed by the service. These NDRs often appear to be spam to other email servers and services (also known as backscatter).

Relay pool

In certain scenarios, messages that are forwarded or relayed via Microsoft 365 are sent using a special relay pool, because the destination shouldn't consider Microsoft 365 as the actual sender. It's important for us to isolate this email traffic, because there are legitimate and invalid scenarios for auto forwarding or relaying email out of Microsoft 365. Similar to the high-risk delivery pool, a separate IP address pool is used for relayed mail. This address pool isn't published because it can change often, and it's not part of published SPF record for Microsoft 365.

Microsoft 365 needs to verify that the original sender is legitimate so we can confidently deliver the forwarded message.

The forwarded or relayed message should meet one of the following criteria to avoid using the relay pool:

  • The outbound sender is in an accepted domain.
  • SPF passes when the message comes to Microsoft 365.
  • DKIM on the sender domain passes when the message comes to Microsoft 365.

You can tell that a message was sent via the relay pool by looking at the outbound server IP (the relay pool is in the 40.95.0.0/16 range).

In cases where we can authenticate the sender, we use Sender Rewriting Scheme (SRS) to help the recipient email system know that the forwarded message is from a trusted source. You can read more about how that works and what you can do to help make sure the sending domain passes authentication in Sender Rewriting Scheme (SRS) in Office 365.

For DKIM to work, make sure you enable DKIM for sending domain. For example, fabrikam.com is part of contoso.com and is defined in the accepted domains of the organization. If the message sender is sender@fabrikam.com, DKIM needs to be enabled for fabrikam.com. you can read on how to enable at Use DKIM to validate outbound email sent from your custom domain.

To add a custom domain, follow the steps in Add a domain to Microsoft 365.

If the MX record for your domain points to a third party service or an on-premises email server, you should use Enhanced Filtering for Connectors. Enhanced Filtering ensures SPF validation is correct for inbound mail and avoids sending email through the relay pool.

Find out which outbound pool was used

As an Exchange Service Administrator or Global Administrator, you might want to find out which outbound pool was used to send a message from Microsoft 365 to an external recipient.

To do so, you can use Message trace and look for the OutboundIpPoolName property in the output. This property contains a friendly name value for the outbound pool that was used.