Outbound delivery pools
The improved Microsoft 365 Defender portal is now available. This new experience brings Defender for Endpoint, Defender for Office 365, Microsoft 365 Defender, and more into the Microsoft 365 security center. Learn what's new.
- Exchange Online Protection
- Microsoft Defender for Office 365 plan 1 and plan 2
- Microsoft 365 Defender
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 messages sources.
High-risk delivery pool
To prevent this, all outbound messages from Microsoft 365 datacenter servers that's determined to be spam or that exceeds the sending limits of the service or outbound spam policies 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 address will appear on IP blocklists.
The very real possibility that IP addresses in the high-risk delivery pool will be placed on IP blocklists remains, but this is by design. Delivery to the intended recipients isn't guaranteed, because many email organizations won't accept messages from the high risk delivery pool.
For more information, see Control outbound spam.
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.
The outbound high-risk delivery pool manages the delivery for all non-delivery reports (also known as NDRs, bounce messages, delivery status notifications, or DSNs).
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.
All of these issues can result in a sudden increase in the number of NDRs being processed by the service. Many times, these NDRs appear to be spam to other email servers and services (also known as backscatter).
Messages that are forwarded or relayed via Microsoft 365 in certain scenarios will be sent using a special relay pool, because the destination should not 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 is not 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/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 will be in the 188.8.131.52/16 range), or by looking at the outbound server name (will have "rly" in the name).
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 email@example.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 domains 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 will avoid sending email through the relay pool.