Inbound Connector Configuration You’ll Want to Avoid
I recently worked with a customer who had a configuration in their EOP outbound connector that broke inbound mail for a newly added domain. I want to share this tale in hopes that you not only learn more about EOP partner connectors, but that you decrease the change of breaking your own mail flow. So grab your favourite caffeinated beverage, tilt back in your office chair, and read along.
To begin, let’s first look at what the inbound mail flow looks like.
It is against best practices to daisy chain services like this (ie. Pointing your MX towards a 3rd party filtering service which then relays to EOP). I won’t get into the disadvantages of this setup here but will write about it soon. For EOP to accept mail from the 3rd Party spam filter, the following connector was created in Office 365 (note: this connector is actually not required in this situation, more on this further down in the article).
Mail flow with this setup worked fine. The MX records for all accepted domains pointed towards the third party filtering service, and the IP in the Partner Connector is the IP that this 3rd party service used to relay the message to EOP.
Everything was perfect… until a new domain was added, let’s use contoso.com to protect the innocent. The MX record for contoso.com was set to point towards EOP and not the third party filtering service (the plan was to have all MX records pointed towards EOP, but this had not yet happened, except for contoso.com). All mail sent to contoso.com would be directed to EOP, which would result in an NDR (sent from EOP) back to the sender which included the following error.
BN1BFFO11FD051.mail.protection.outlook.com gave this error:
Relay Access Denied ATTR1
Your message wasn't delivered due to a permission or security issue. The address may only accept email from certain senders or another restriction may be preventing delivery. For more tips to resolve this issue see DSN code 5.7.1 in Exchange Online. If the problem continues contact your help desk.
This is certainly not an ideal situation, unless of course you don’t want anyone to email you.
What’s happening here?
How come EOP is rejecting inbound mail which is destined for contoso.com? Let’s take a look back at the EOP partner connector. Two things here, this connector has the following configuration.
- Connector type: Partner
- Domain restrictions: Restrict domains by IP addresses
- Sender domains: *
All externally originating mail that comes in to EOP will hit this connector because the type is set to partner and the sender domain is set to *. This connector will then check if the message came from the IP(s) listed in the “sender IP addresses” field of this connector and if there is not a match then EOP will reject the message. For mail that was being relayed from the 3rd party filtering service everything was fine because the IP of this service was in the partner inbound connector. For mail that arrived from a different IP, EOP would reject the message, as was the case with contoso.com because the MX for that domain was pointed directly at EOP.
In this particular case there were two options if this connector was going to remain enabled. Either set the Domain Restrictions to None, or remove the * from Sender domains and manually type the domains in. Since this connector is picking up all inbound mail, typing in all the domains on the Internet is not exactly an option. Instead, we need to remove the Domain Restrictions on this inbound connector and set this option to none.
Typically Partner Inbound connectors are used to force TLS with a subset of domains so it is very rare to see both an IP Address restriction along with a * for the sender domains. In this scenario, a connector in EOP DOES NOT need to be created to accept mail from the Internet as EOP will accept all mail destined for your domain. This particular customer had created this connector to work around an issue in EOP which has since been fixed.