Exchange Online – Stop external emails being sent directly to the onmicrosoft.com aliases

Many of us are managing Exchange Online and are still using the third-party filtering, you might have noticed that if email from internet is sent to onmicrosoft.com alias it does not route thru the third-party gateway.

If you have not thought about it than check yourself by sending to the onmicrosoft.com alias as spammers have already started using this strategy for attacks.

Another issue is –> it bypasses all the filtering rules that you have created on the third-party gateway that you are utilizing for fighting spam.

This is in user voice as well but we already have a solution that can be used to counter this scenario.

office365.uservoice.com/forums/289138-office-365-security-compliance/suggestions/34152823-stop-external-emails-being-sent-directly-to-the-on

There are two options either you can completely block the traffic towards onmicrosoft.com aliases or redirect it to your third-party gateway.

We like the later as we don’t want user should miss any email, we want to be flexible in our approach and still want that this traffic should go thru all the filters.

Here is the TEST: (I sent email from gmail to onmicrosoft.com alias and analyzed the headers using mxtoolbox.com)

You can see it is directly hitting Exchange online Protection and bypassing our Third-party gateway.

We can redirect these email to our third-party gateway by following below two steps

Step1 – Create Transport rule Scoped outbound Connector, below is the Command.

New-OutboundConnector -Name ‘Outside Traffic to MX Record‘ -ConnectorType ‘Partner‘ -UseMxRecord:$true -IsTransportRuleScoped:$True

Step2 – Create Transport Rule to Redirect the messages to MX record (i.e. Third party gateway)

New-TransportRule -Name ‘Redirect to MX Record Connector‘ -FromScope NotInOrganization -RecipientDomainIs ‘youractualdomain‘ -ExceptIfSenderIpRanges 10.10.10.11,10.10.10.12 -SetAuditSeverity Low -RouteMessageOutboundConnector ‘Outside Traffic to MX Record‘

Note the exception here -ExceptIfSenderIpRanges 10.10.10.11,10.10.10.12 – these should be any public addresses for your thirdparty gateway and any onpremise Public IP addresses that are routing email traffic to office 365.

If you do not have static range than you can also use other headers in transport rule exception, for example: for one customer We have used “X-OrganizationHeadersPreserved”

Now when you again test the email you will see that message has been redirected to third-party gateway where the filters that you have created will be applied 🙂

I have not tested on blocking it as we thought redirect is the better option but if you want to block this traffic completely than follow the below blog post.