In a multi-forest Exchange Server/Exchange Online (single tenant) configuration, you are likely to have multiple inbound connectors to receive email from the different on-premises environments. There are scenarios where it is important to ensure that the correct connector is used for the inbound message rather than any of your connectors. Here is one such example.
With multiple inbound connectors you might be happy and successfully complete your testing if the email from on-premises appears in the correct cloud mailbox. But what about when you use Enhanced Filtering. Here you need to add the intermediate IP addresses of all the hops the message can go through to the specific connector so that Exchange Online Protection can determine the real source IP address and then do spam/spf etc. on the true sender IP and not the hop before Exchange Online Protection (likely your on-premises server and not the actual source).
For example, lets send an email from SenderDomain.com to RecipientDomain.com, where RecipientDomain.com uses Mimecast, has Exchange Servers and has moved mailboxes to Exchange Online. The mail flow for this scenario is:
SenderDomainServer Public IP > MX (Mimecast) > Mimecast IPs > On-Premises IPs (internal) > Public IP for on-premises servers > EOP
From the EOP view point, the email is received from the public IP for the on-premises servers and not from the actual sending IP address. This means that the message will fail SPF as you have complex routing in-front of the receipt by EOP. This, out of interest, is the reason why EOP will not reject SPF failures even if DMARC reject is in place.
When the message arrives at EOP, the message needs to be attributed to the correct connector. If you have multiple Exchange Server orgs in separate on-premises environments you need to make sure that the message is associated (attributed) to the correct Inbound Connector.
This message attribution is done by looking for all Inbound Connectors of type On-Premises in your tenant. If you have more than one connector of type On-Premises, looking up the TlsSenderCertificateName value on the Inbound Connectors to find the connector that best matches the certificate used to encrypt the inbound message. So lets take a look at the example above again. In the “Public IP for on-premises servers > EOP” hop this message will be encrypted with a certificate called (lets say) “mail.recipientdomain.com” and the Exchange Hybrid Wizard will have created the Inbound Connector for this mail flow with TlsSenderCertificateName set to *.recipientdomain.com. Other Inbound Connectors from other on-premises orgs are possibly going to have similar certificates (they should not have the same one) with similar subject names and the Hybrid Wizard could have made more than one Inbound Connector with *.recipientdomain.com as the TlsSenderCertificateName value. If you have multiple Inbound Connectors of type On-Premises and more than one connector with TlsSenderCertificateName set to *.recipientdomain.com then the message could be attributed to the wrong connector.
If you have set Enhanced Filtering IPs to the other connector though, the Enhanced Filtering will not work because the message is not received by the connector you think it should be received by.
So how do you fix this. You modify the Hybrid Wizard created Inbound Connector TlsSenderCertificateName value to be the subject name of the certificate, so not *.recipientdomain.com but mail.recipientdomain.com and you register mail.recipientdomain.com as a domain in Office 365. You need to do both. The reason the Hybrid Wizard sets TlsSenderCertificateName to *.recipientdomain.com is to avoid you needing to add domains to Office 365 that match your certificate precisely, but if you have multiple connectors this is the only way to guarantee message attribution to the correct connector.
Now you can add the IPs you want to skip with Enhanced Filtering to the specific connector, mail flow will use the specific connector and the IPs will be skipped. EOP will resolve the correct sender IP (SenderDomain Public IP in the above example) even though the message has gone through Mimecast and on-premises servers as well. The message headers will now show:
X-MS-Exchange-SkipListedInternetSender ip=[Sender Server IP Address];domain=FQDN of sender
And not list Mimecast (or whomever you are using as a second cloud filter) or your on-premises IP addresses as the true sender.
Leave a Reply