Exchange Online and Non-MX Delivery

When first designing Exchange hybrid between their on-premises Exchange infrastructure and their Exchange Online tenant, some customers insist that they maintain their current mail flow particularly for mail flow to and from the internet.

A very common pre-hybrid inbound mail flow configuration consists of the organization's MX record pointing to a third-party hygiene service, which delivers the organization's sanitized email directly to one or more public IPs that get NATed to typically either on-premises Edge Transport or Hub Transport servers for delivery to destination recipients (generally mailboxes, groups). In a strictly on-premises environment the mail will be mainly delivered to local, on-premises Exchange recipients. In a hybrid environment with directory objects synchronized between Exchange orgs, recipients could be located in on-premises Exchange or in Exchange Online. If the later, the on-premises servers would route those emails out to the cloud mailboxes via hybrid mail flow setup.

An equally common recommendation for securing inbound mail delivery, is for organizations to also restrict inbound and only allow SMTP (tcp 25) traffic from their third-party hygiene service to the public IPs/NATs of their on-premises Exchange transport servers. However when establishing hybrid mail routing, organizations will also be required to add the range it IP subnets that make up Exchange Online Protection (EOP) to their external firewall to allow inbound mail flow from Exchange Online mailboxes. This is depicted as follows:

For a detailed account of IP subnets that need to be added to allow inbound mail flow from EOP see "Office 365 URLs and IP Address Ranges" (link).

The mail flow works and customers are generally happy with this basic design until they realize that senders (spammers) can bypass their published MX record (and third-party hygiene service) and deliver directly to Exchange Online mailboxes by sending to the "contoso-com.mail.protection.outlook.com". This is also the hostname used if the organization was to point their MX record directly to Exchange Online. In this example, although the organization's MX record is still pointing to a third-party service this record is still available for direct routing to Exchange Online mailboxes. Further since directory synchronization is in place, unmigrated recipients in the on-premises organization that are being synced to the cloud can also receive email directly via direct send to EOP.

This may be acceptable for some organizations who do not rely on mail flowing on-premises first or for those who are planning on moving their MX record to point to EOP anyway. However, this could be more of an issue for organizations that require all of their inbound email flow through a single path for either auditing, tracking, content inspection or even archive/journaling purposes.

An argument could be made for EOP identifying and dealing with the spam that could be coming in directly. However, if the organization followed our advice for configuring EOP when it sits in the inbound mail flow behind another hygiene service, then a lot of functionality in EOP may have been turned down/off.

How do organizations prevent direct delivery to this EOP hostname? There is a solution in which an organization can create an inbound "partner" type connect to restrict delivery only from certain sending IP addresses (RestrictDomainsToIPAddresses:$True, SenderIPAddresses:{<IPAddressList>}) or from systems with a specific TLS certificate (RestrictDomainsToCertificate:$True, TlsSenderCertificateName:<CertSubjectName>) such as the certificate that contains the namespace for hybrid mail flow. This will NDR messages sent directly to EOP unless they come from the on-premises Exchange infrastructure.

However, there is another potential issue if a customer is keen to prevent all non-MX mail flow into their organization. If a spammer is able to determine the public IPs for an org's on-premises Exchange infrastructure, they could setup a new tenant in EOP and create a partner connector to deliver spam directly to the on-premises environment. This is course assumes that the spammer can find out one or more IP addresses but arguably would not be too difficult for many environments. Further, since the firewall is already configured to allow SPTM (tcp 25) traffic from EOP per hybrid requirements, the spam emails would flow in to the on-premises Exchange. Depending on the current state of hybrid and where mailboxes reside, the emails may be delivered to on-prem recipients or for migrated recipients route those out to the cloud mailboxes via hybrid mail flow setup.

To continue exploring this, we also need to consider the potential here even outside of the non-MX mail delivery issue. This could potentially be an issue for all hybrid organizations, even if their MX records point to EOP. Inbound connectivity to the organization's on-premises Exchange transport servers is still reachable by any EOP tenant. It really becomes less of an issue as mailboxes are migrated to the service but with our long-term hybrid recommendation, at a minimum it could result in unnecessary resource and bandwidth consumption.

There is not really a simple solution for this issue however. One reasonably easy option involves creating an on-premises Exchange Transport Rule (ETR) to look for certain message headers as emails are coming into on-premises Exchange. In a properly setup Exchange hybrid environment, an ETR could be configured to allow only messages with the header "X-MS-Exchange-Organization-AuthAs" set to "Internal" which should be the case for all email coming from the Exchange Online tenant. Alternatively, the "X-MS-Exchange-Organization-AuthSource" header could be used and look for matches to ".prod.outlook.com".

However, this ETR will also apply to all messages submitted to on-premises transport and not just those coming in from Exchange Online. Therefore, devices set to relay emails through on-premises Exchange could get caught by this rule and therefore an exception to this rule would need to be put. The exception could be based off of sender IP address ranges or by using externally-secured receive connectors, the latter of which is not ideal for many organizations.

This ETR should be placed in test mode first though, to detect any potential impact to existing mail flow within the organization. An ETR could be set to generate an incident report first, which would be helpful to determine what messages would be flagged and possibly dropped by an ETR.  Once any mail flow issues have been mitigated, the ETR would be replaced with one that would actually reject mail matching the criteria rather than generate an incident report.