The outbound IP and HELO format for Office 365

Regularly, Office 365 is asked by other email receivers about the way our mail servers and IP addresses are set up, and the need to conform to a particular standard. That standard (which is more of a convention implemented by some receivers, not all of them) is that the IPs have Forward-Confirmed Reverse DNS, and these also conform to the HELO/EHLO strings that are used when sending outbound email. For example, suppose Office 365 was sending from the IP 1.2.3.4. This would require the following:

1. The IP 1.2.3.4 has the reverse DNS (PTR) 4.3.2.1.protection.outlook.com
2. The domain 4.3.2.1.protection.outlook.com has the A-record 1.2.3.4. Combined with #1, this is Forward Confirmed Reverse DNS (FC-rDNS)
3. The outbound mail servers HELO/EHLO as 4.3.2.1.protection.outlook.com

This is a view of the world that assumes that we have one-mail-server, one-HELO, one-sending-IP, like this:

Office 365 aligns with the first 2 requirements above, but not the third. Instead:

1. Our sending IPs have PTR records (so far, the same)
2. All of those PTR records have A-records that point back to the same IP (so far, the same)
3. Our EHLO/HELO strings are all generic, that is, they would be something like mail.protection.outlook.com. This is the first difference (our EHLO/HELO strings also include the data center, so it would be more like northamerica.city.mail.protection.outlook.com).
4. The EHLO/HELO strings all have A-records with some IPs in them, but not all of the sending IPs per data center. You can only fit so many IPs into a UDP packet (it’s less than 16) whereas we have over a hundred outbound IPs that would use this same EHLO/HELO string. Thus, it is not possible to conform to get every IP to point back to the EHLO string.
5. The PTR domain and the EHLO domain each align with *.protection.outlook.com, and that’s as close as they will get in most cases.
6. Each EHLO/HELO string has an SPF record which will contain the sending IP

Thus, the architecture of the mail server is that it uses a generic EHLO and can go out any IP within the data center that is in our outbound IP pool, like the below:

We do it this way because it makes it more flexible when we have delivery problems. Since we are a cloud service, we can’t lock ourselves into certain IPs and need to allow the mail servers to route to a different set of IP addresses when needed (e.g., for load balancing). The one, one, one model may have made sense when the Internet was running on on-premise mail servers, but not now with the advent of cloud services.

As an example, here’s a message I sent from my work account to my Gmail account:

HELO: NAM02-BL2-obe.outbound.protection.outlook.com (PTR: mail-bl2nam02on0131.outbound.protection.outlook.com. [sending IP: 104.47.38.131])

– PTR record of 104.47.38.131 = mail-bl2nam02on0131.outbound.protection.outlook.com

– A-record of mail-bl2nam02on0131.outbound.protection.outlook.com = 104.47.38.131 (matches sending IP, so we have FC-rDNS)

– A-record of NAM02-BL2-obe.outbound.protection.outlook.com = 207.46.163.79 (this is not the sending IP, nor is it even in the same /8)

– SPF record of NAM02-BL2-obe.outbound.protection.outlook.com = v=spf1 include:spf.protection.outlook.com -all (covers both 104.47.38.131 and 207.46.163.79)

– HELO and PTR domains each contain outbound.protection.outlook.com

The PTR and HELO each contain nam02 (North America, #2) and BL2 (referring to the data center). But the PTR has more information in it than the HELO.

That’s how our outbound IPs and EHLO strings currently work, any 3rd parties who require them to match more strict requirements would need to allow Office 365’s IP ranges to bypass this if they want to receive email from customers that are hosted by Office 365.