Share via

Office 365: SPAM detection and reverse DNS lookups.

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:


Submitting host
Receiving host

1 ([]) ([])
2/7/2018, 2:02:41 PM


2 ( (
2/7/2018, 2:02:41 PM

0 seconds

Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256)

3 ( (
2/7/2018, 2:02:43 PM

2 seconds

Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256)


In this case is the server initiating the connection to the receiving gateway.  This server identifies itself in that transmission as and the public IP address associated – in this instance


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
Default Server:

> set type=ptr

Non-authoritative answer: name =


In this case the reverse DNS lookup for IP address is


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 is not equal to  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 –>