I have clients asking if how we can stop email delivery on onmicrosoft.com (O365 / Exchange online) email addresses since we don’t have any control on this email domain along with DNS entries. The question becomes a priority question for companies having a hybrid setup with MX pointing to on-premise custom domains and emails to onmicrosoft.com IDS directly hit to O365 bypassing the on-premise gateway and thus causing a compliance issue.
Well, when we register an O365 tenant, by default it creates one default domain as "Tenant.onmicrosoft.com. This domain is fully functional and we can send/receive emails through this domain to/from the internet. Microsoft manages DNS records for this domain and we cannot control that. The purpose of this domain is to facilitate email migrations / co-existence scenarios.
Organisations having standalone O365 tenants don’t use onmicrosoft.com (they could if they wanted to), in fact, they don’t need it. They simply register their company domain with O365 and create email addresses in that domain and thus bypass default onmicrosoft.com domains.
Companies running hybrid setups, or companies switching to O365 do need this domain to establish co-existence and enable email migrations.
Hybrid setup – Here, hybrid setups can be considered as organisations syncing on-premise active directory identities to O365 with Azure AD connect and / or running an on-premise email system along with Exchange online (O365). On-premise email systems can be Exchange, Lotus Notes, or any other Linux based email platforms.
Also if you use Azure AD sync to synchronise on-premise identities to O365, it adds “Tenant.mail.onmicrosoft.com” as one more domain to an O365 tenant.
Once Directory sync is enabled, no matter how you create mailboxes / mail-enabled users in O365 directly or get them synced through on-premise active directory, it will append "Tenant.onmicrosoft.com" and / or "Tenant.mail.onmicrosoft.com" as additional aliases to O365 identity and cannot be removed unless we disable directory synchronisation at the tenant level.
One can think to build a simple transport rule with exchange online which will block emails to onmicrosoft.com domain from the internet. The fact is that the user primary SMTP address is set as their company (custom) domain in the majority of cases and transport rules apply after the recipient is resolved and the post-resolution email address is changed to the user custom domain, and here transport rules will get bypassed.
Transport rules would apply only if the primary SMTP address is resolved to domains restricted by a transport rule.
I've seen a few posts which insist on reading message headers through transport rules and then block onmicrosoft.com messages. Unfortunately, those never worked for me.
The simple solution to this issue is to point the MX to O365. Now even if emails sent on Tenant.onmicrosoft.com or Tenant.mail.onmicrosoft.com, O365 will resolve it to the user primary SMTP address and there should not be an issue from a compliance standpoint.
If a client disagrees to point MX to O365, it may be due to company policy / audit compliance issue, then only one option would be left, i.e. create a partner connector (certificate based / IP based) on the O365 side under Exchange online. The connector will ensure that all emails from the Internet to onmicrosoft.com IDs will get rejected at the O365 entry point and at the same time, any emails received from on-premise servers will be accepted though they are marked to onmicrosoft.com IDs to maintain co-existence.
To create a connector, navigate to O365 (Exchange Online) admin portal \ Mail flow \ connectors tab and click on plus sign as shown below:
This is an important step. If your on-premise email system is Microsoft Exchange, select the certificate option and add an exchange public certificate subject name and click next. This setting will force exchange online to receive emails only from TLS enabled transport servers having an SMTP certificate with the specified subject name which is nothing but on-premise exchange servers.
If the on-premise email system does not understand / use TLS such as the open source Linux systems or Lotus Notes, then choose an IP address range option so that exchange online will be forced to accept emails only from those on-premise servers.
Side Note :
Microsoft exchange uses opportunistic TLS on default send / receive connectors. The SMTP certificate used for TLS is chosen based on the "msExchServerInternalTLSCert" attribute found on exchange server objects in the AD configuration container. Usually, MS Exchange selects SMTP certificate for TLS with latest "valid from" date and PKI based certificate (3rd party public certificate in our case) and use its subject name. Refer TLS Certificates and Opportunistic TLS for more details.
When we run the hybrid configuration wizard, the wizard does ask us to select a certificate to be used for TLS along with send connectors and there we must select a public certificate. The certificate subject name is tagged by exchange online to the "inbound connector" which gets created as part of hybrid mail flow connectors. Exchange online "Get-InboundConnector" cmdlet shows our public certificate subject name mapped to the "TlsSerderCertificateName" attribute on an inbound connector as shown below:
Now, when we send email from Gmail to an O365 default domain email address, we have received NDR as shown above. The NDR clearly gives an indication about the partner connector.
If you have multiple MS exchange organisations configured in hybrid with a single O365 tenant, then multiple inbound connectors would get created in exchange online corresponding to each exchange organisation. In that case, multiple partner connectors would be required to work with each exchange organisation I believe.
Exceptions to the above:
Any customers using standalone O365 (Exchange Online) but also using the AD Sync tool to sync identities to O365 cannot bypass default O365 domain and email aliases pointing to onmicrosoft.com domain and same time cannot block emails sent on these default domain email aliases / addresses.
This is because of Azure AD Connect integration with Exchange online forces Exchange Online to add onmicrosoft.com email aliases to every mailbox which cannot be removed and any email received on the default domain (onmicrosoft.com) alias will eventually get resolved to the user primary SMTP email address before email delivery, thus transport rules to block default domain emails won't work. Also, partner connectors won't work here because MX remains with O365 only.
I hope you will find this article helpful.