Office 365: Mail flow delays through third party SPAM gateways…

This week I had a customer present with an interesting issue.  They have a partner company they work with that users a third party spam filtering gateway prior to allowing mail into their on premises environment.  They were observing that emails to this partner company were often delayed.  When engaging with the partner company it was determined that their mail was being greylisted by the third party device.  The reason for the grey listing was due to the fact that the server advertised in the EHLO did not match the name of the server making the underlying connection.

 

It is not uncommon that the server name listed in the EHLO string does not match the server that is making the underlying outbound connection.  If we were to compare this to on premises concepts I would have a series of servers that act as my mail bridgeheads.  These servers would be subscribed to an outbound send connector – and that send connector would have a fully qualified domain name on it.  Regardless of which outbound bridge head was utilized it would always connect to the remote host and advertise the same EHLO name that would apply to the group through the send connector configuration.

 

In Office 365 we have a very similar concept.  Our array of bridgeheads each have individual server names and publically routable IP addresses assigned to them.  The names also are available in reverse DNS such that performing a reverse DNS query against the connections IP address would return the name of the individual bridge head making the connection.  When the individual bridgehead connects to a remote SMTP service it issues an EHLO command that represents a namespace that is assigned to a group of servers.  This namespace is resolvable also and also has it’s own corresponding DNS entries.  Let’s take a look at a sample.

 

I have addressed an email to a user at hotmail.com.  The bridge head that has picked up the connection is NAM01BR5.protection.outlook.com with IP address 192.168.200.1.  When connecting to the MX record for hotmail.com an EHLO is issued.  In this case EHLO NAM01.protection.outlook.com 172.16.16.1.  Notice that NAM01.protection.outlook.com is not NAM01BR5.protection.outlook.com.  In this case the third party gateway performs a reverse DNS lookup on the connecting IP address 192.168.200.1 and discovers that the host connecting is NAM01BR5 and not NAM01.  When this discover is made the solution determines that a SPAM rule has been violated – and bans the connection for 15 minutes then allowing the mail to go through.

 

Given that it is not uncommon that the EHLO domain advertised does not match the underlying connection this type of checking may be slightly aggressive.  Unfortunately on the Office 365 side the administrator cannot control this therefore all of their email will be delayed by 15 minutes until the third party addresses this configuration.