Currently when configuring an inbound receive connector in Exchange Online (EXO), there are two sets of options:
1. "Authenticating sent email" - sender domain match OR list of IP ranges
2. "Security restrictions" - reject email messages based on TLS or if they aren't in a list of IP ranges (same as above)
The result of the limited options is that there is no obvious way to setup direct communication between two partners who both use EXO, or in the case of a migration between two tenants under the control of one organization, to ensure routing directly between those tenants. The assumption in a partner relationship is that the sending tenant is sending out directly from EXO OR can be configured to create a new send connector in EXO.
There are two known workarounds:
1. Resend email through non-EXO servers in order to then re-accept email in another EXO tenant
2. Develop and maintain automation (as a customer) that checks for the list of EXO public IP ranges and updates a connector.
The feature request is primarily designed to allow direct communication between EXO tenants in a partner relationship, but can be extended to more easily allow for receiving email from partners that aren't only sending email from EXO. Specifically, I suggest adding two security restrictions for specified domains:
1. Reject emails messages if they are not sent from Exchange Online servers
2. Reject email messages if they are not sent from servers in the sender domain's SPF record (with an option to treat soft fail as a hard fail)
Adding this will address a long-standing issue which is how to setup relationships between EXO tenants, especially as organizations move fully to Exchange Online.
It may also be useful to have one more restriction: Reject emails if the FROM header does not match the FROM envelope OR specify a list of FROM header domains to allow for a specific FROM envelope. Although I can also see how the FROM matching could be part of an anti-spam policy instead. However, for the IP based restrictions that needs to be done from a receive connector since most organizations utilize a separate anti-spam filtering service and have no receive connectors in EXO allowing emails from other IPs.