Block emails delivered directly to user@domain.onmicrosoft.com or user@domain.mail.onmicrosoft.com (MX Bypass)

Let’s assume I have my mailbox in Exchange Online with an email address of nuno@domain.com. External users can send emails directly to nuno@domain.onmicrosft.com (the tenant’s default domain) or to nuno@domain.mail.onmicrosoft.com (typically used in Hybrid environments) and they will be delivered to my mailbox. This is because these two managed domains are fully managed by Microsoft and have internet-routable MX records:

Not a big problem for “pure” Office 365 organizations as these emails are still subject to Exchange Online Protection (EOP) policies such as anti-spam and anti-malware. However, this is a problem for organizations that use a 3^rd-party service for message hygiene. In this scenario, these emails would completely bypass the 3^rd-party and all the security measures it enforces.

There are a few solutions out there that rely on mail flow (transport) rules to either reject or redirect these emails back to the 3^rd-party provider, but these never quite worked for me... The main reason is that transport rules are processed post onresolveMessage event and when this happens the email address for the recipient changes to the PrimarySMTPAddress which has the domain.com suffix.

The solution I ended up implementing was slightly different. I created an Inbound Partner Connector, set the sender domain address space to *, and restricted it to only accept emails if the sender presents the certificate I have configured on my on-prem Hybrid servers (you can also restrict it to your on-prem or 3^rd-party IP addresses). The following procedure assumes that we have a setup in which we have executed the Hybrid Configuration Wizard (HCW) successfully (which would have created the required connectors for mail flow).

First, we run the following command to get a list of inbound connectors configured by HCW. If you have Hybrid across multiple Exchange Organizations, then you’ll see more than one entry.

$onpremorg = Get-OnPremisesOrganization | Select OrganizationGuid, InboundConnector | Where {$_.InboundConnector -ne $null}

$onpremorg

If the Inbound Connector was configured by the HCW, then the attribute TlsSenderCertificateName will map either to the domain name included in the subject or subject alternate name attribute of the 3^rd-party certificate used, or it will contain the details of the certificate.

Next, we create the inbound partner connector using the following command:

New-InboundConnector -Name “Block Direct Delivery” -ConnectorType Partner -SenderDomains * -TlsSenderCertificateName (Get-InboundConnector $onpremorg[0].InboundConnector).TlsSenderCertificateName -RestrictDomainsToCertificate $True -RequireTls $True

Once this connector is in place, any external senders that try to email nuno@domain.onmicrosft.com or nuno@domain.mail.onmicrosoft.com will receive the following NDR:

Emails sent to Exchange Online mailboxes routed through the on-prem Exchange servers, will always use the Inbound connector created by the HCW, while service emails like notifications from Teams, SharePoint Online, etc., will use the default connectors.

If you use a 3^rd-party service for message hygiene but your emails flow directly from the 3^rd-party to Exchange Online, you can still use this method, but instead of restricting the connector to a certificate using the RestrictDomainsToCertificate parameter, you can restrict it to the IP(s) of your 3^rd-party service by using the RestrictDomainsToIPAddresses parameter.