In Office 365 support we occasionally receive requests to review non-deliverable reports. In some instances the non-deliverable reports are generated by remote mail systems antispam technologies – specific reverse DNS looksups.
What is a reverse DNS lookup. Let’s take a look.
An email is addressed from an Office 365 mailbox to a remote mail system. Our outbound gateways connect to the remote mail system to begin the SMTP transmission. Here is a sample header:
2/7/2018, 2:02:41 PM
2/7/2018, 2:02:41 PM
Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256)
2/7/2018, 2:02:43 PM
Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256)
In this case NAM01-SN1-obe.outbound.protection.outlook.com is the server initiating the connection to the receiving gateway. This server identifies itself in that transmission as NAM01-SN1-obe.outbound.protection.outlook.com and the public IP address associated – in this instance 188.8.131.52.
When a reverse DNS lookup is performed – the IP address of the connection is utilized to return the hostname assigned by the ISP hosting the reverse dns namespace. Here is an example from nslookup:
Default Server: UnKnown
> server 184.108.40.206
Default Server: google-public-dns-a.google.com
> set type=ptr
220.127.116.11.in-addr.arpa name = mail-sn1nam01on0055.outbound.protection.outlook.com
In this case the reverse DNS lookup for IP address 18.104.22.168 is mail-sn1nam01on0055.outbound.protection.outlook.com.
At one time in the antispam world a protection that was often utilized was to compare the connecting host name to the reverse DNS name. If the names matched the host was considered valid. In the case of Office 365 the reverse dns record may not match the name of the host initiating the connection. As you can see here NAM01-SN1-obe.outbound.protection.outlook.com is not equal to mail-sn1nam01on0055.outbound.protection.outlook.com. There is no requirement within the mail flow RFCs that the connecting host name or the name provided within the connections EHLO request must match a reverse DNS lookup of the connecting IP address.
In the case of the NDRS presented from the customer the NDR is due to antispam on the receiving servers blocking connections from servers that do not pass a successful reverse DNS check.
Unfortunately from the Office 365 standpoint there is little that can be done. Reverse DNS looks ups are largely unreliable in todays transport environments to feed antispam decisions and have arguably been replaced by more reliable technologies like SPF and DKIM. Administrators experiencing these types of NDRs should engage with the third party blocking the messages and request whitelisting for their domains.
You can find some more specific and detailed information regarding server naming conventions and Office 365 here –> https://blogs.msdn.microsoft.com/tzink/2016/07/15/the-outbound-ip-and-helo-format-for-office-365/