Exchange Online Protection Conditional Mail Routing

Introduction

Simply put, Conditional Mail Routing, also known as Criteria Based Routing, is a way of configuring Exchange Online Protection [EOP] connectors in order to send or receive mail a certain way based on the condition of the individual email. For example, we can force TLS for a specific sender or route email based on recipients’ properties to different email server locations.

I was recently working on a global Exchange migration to Office 365. This particular client had an Office 365 tenant hosted in Europe with a Hybrid deployment in India. On top of that, there was a separate Exchange organization deployed across the United Kingdom and the United States of America.

For us to be able to update the MX records to point to the client’s Office 365 tenant, two requirements had to be met because of security and legal reasons:

• Requirement 1: emails sent from partners to certain business application mailboxes (hosted on-premises in the UK) had to go directly from Office 365 to the Exchange servers in the UK, i.e., without being routed through India;
• Requirement 2: emails addressed to US users had to go directly from Office 365 to the Exchange server on-premises in the US, i.e., without being routed through India.

So let us see how we can meet these 2 requirements using Conditional Mail Routing. As they are both very similar, I will use the Exchange Admin Centre for one and PowerShell for the other.

Requirement 1 – Directly to UK

In order to redirect emails sent to particular mailboxes directly to the UK servers, we will use a transport rule to analyze a particular AD attribute for all recipients and an outbound connector to forward those emails to a UK server if a particular condition is met.

For this scenario I am using AD attribute CustomAttribute10 for the condition, but several other AD attributes can be used instead, as we will see. The condition (transport rule) checks if a particular recipient’s CustomAttribute10 is set to “UK Application”. As such, the accuracy of user attributes in AD is crucial for the transport rule to work as intended.

Before we create our outbound connector and transport rule, there is an extra step we need to make beforehand. As I mentioned, these mailboxes are hosted by an on-premises server, meaning Office 365 does not know anything about those mailboxes. To ensure that our transport rule works, we need to create in Office 365 the AD user accounts associated with all application mailboxes (for which we want to change mail flow for). To achieve this, there are two options:

1. Using DirSync. Placing these accounts under DirSync scope will ensure they get replicated to Office 365 with all the attributes we need (not forgetting to configure CustomAttribute10);
2. Manually creating them. The other alternative is to manually (or through a script) create a Mail Contact for each application mailbox directly in Office 365. Here we will simply need to configure the Display Name, Alias, Email Address and CustomAttribute10.

The only difference between both options is the way these are managed going forward: on-premises vs in the cloud.

To demonstrate this scenario, I simply created a mail contact in Exchange Online:

Figure 1

Now we are ready to start. As already mentioned, first we need to create a new outbound connector and configure it to use criteria-based routing to route mail directly to the UK:

1. In the EAC, navigate to mail flow > connectors. Under Outbound Connectors, click  to create a new connector;

Figure 2

2. Give the connector a name, such as UK Applications. For Connector Type, choose On-premises;
3. Decide if you want to select the Retain service headers on transmission option (used for Hybrid deployments);
4. Optionally, add a description for the connector in the Comment text box;

Figure 3

5. For the security connectivity requirements, select Opportunistic TLS (a TLS connection is attempted, but reverts to an SMTP connection if the receiving email server is not configured to use TLS);
6. In the Outbound Delivery section, choose Route mail through smart hosts, and enter the IP address(es) or hostname(s) of the servers you want these particular emails to be delivered to. In this example I am using an IP address, but a generic hostname is recommended to facilitate any possible future changes;
7. For scope, choose Use for Criteria Based Routing (CBR). This will allow us to assign a specific transport rule to this connector;

Figure 4

8. Click save to save the connector. It should now appear in the list of connectors;
9. Make sure ENABLED is checked. We can later edit the connector’s settings by clicking .

Figure 5

Now we need to create a transport rule and configure it to use the outbound connector we have just created:

1. In the EAC, navigate to mail flow > rules. Click  and choose Create a new rule…;

Figure 6

2. Give the rule a name such as UK Applications. Click the More options… link to make all selections available for the rule;
3. For *Apply this rule if…, choose The recipient… and has specific properties including any of these words. The select user properties box appears;
4. Click  and under User properties: choose CustomAttribute10. Specify “UK Application”. Click ok, and then click ok again to close the select user properties box;
5. For *Do the following…, choose Redirect the message to… and then specify the following outbound connector;
6. The select outbound connector box appears. Choose the Outbound connector created previously. Only connectors that are enabled for CBR appear in the list;

Figure 7

7. You can choose additional properties for the rule, such as the test mode and when to activate the rule;
8. Click save to save the connector.

Once all these steps have been completed, the transport rule redirects messages addressed to users whose CustomAttribute10 property is set to UK Application to the IP address(es)/hostname specified in the Outbound connector.

As such, it is now time to test that emails sent to these applications’ mailboxes are taking the correct path of Sender > Internet > Office 365 > UK Server. To do this:

1. I sent an email from my Gmail account to the test contact I created earlier (which has the same email address of an on-premises mailbox and CustomAttribute10 set to UK Application). Also, this assumes the MX records are already pointing to Office 365;
2. In Exchange Online navigate to mail flow > message trace, enter the recipient’s address and click search:

Figure 8

3. Verify that the email was received By Office 365:

Figure 9

4. Double click the email to see further details. Verify it was forwarded using an outbound connector and the right Transport Rule:

Figure 10

5. Next, confirm email arrived in the on-premises mailbox;
6. Finally, analyze its header using the Message Analyzer of the Microsoft Remote Connectivity Analyzer tool and confirm the path email took is as expected. In the following screenshot we can see the email was sent from a Google server to EOP (sets 1 to 3), then from Exchange Online directly to my on-premises server EXAIO.letsexchange.com as I wanted it to (steps 4 to 6):

Figure 11

Requirement 2 – Directly to US

As already mentioned, requirements 1 and 2 are very similar, so I will use PowerShell for this one. So let us start by creating our Outbound Connector. To achieve our goal we have to use at least the following three parameters of the New-OutboundConnector cmdlet:

• The IsTransportRuleScoped parameter associates the outbound connector with a transport rule;
• UseMxRecord needs to be set to $False as we want the connector to send mail to a particular IP or hostname;
• The SmartHosts parameter specifies the smart host(s) the outbound connector uses to route mail. This parameter takes one or more FQDNs, such as server.letsexchange.com, one or more IP addresses, or a combination of both FQDNs and IP addresses.

The final cmdlet looks like this:

New-OutboundConnector -Name “To USA Users” -ConnectorType OnPremises -IsTransportRuleScoped $True -UseMXRecord $False –SmartHosts 154.58.xxx.xx

Figure 12

Once created, we can use the EAC to ensure everything was configured as expected:

Figure 13

The next step, as before, is to create the Transport Rule that will look into recipients’ attributes and decide if emails addressed to them are to be forwarded directly to a server in the US. In this scenario I will be using users’ Country AD attribute and check if it is set to USA. We achieve this by using the RecipientADAttributeContainsWords parameter which we can use to check against any of the following AD attributes: DisplayName, FirstName, Initials, LastName, Office, PhoneNumber, OtherPhoneNumber, Email, Street, POBox, City, State, ZipCode, Country, UserLogonName, HomePhoneNumber, OtherHomePhoneNumber, PagerNumber, MobileNumber, FaxNumber, OtherFaxNumber, Notes, Title, Department, Company, Manager or CustomAttribute1 to CustomAttribute15.

To specify a value for an AD attribute, we use the name of the attribute followed by a colon and the words we want to check. For example, to look for the word USA in the Country attribute, we set this parameter to Country:USA. To specify multiple values for multiple attributes, separate them with commas.

Next we need to configure the rule to redirect emails to the outbound connector by using the RouteMessageOutboundConnector parameter and specifying the name of the connector (which in this case is identical to the name of the rule).

The final cmdlet looks like this:

New-TransportRule “To USA Users” –RecipientADAttributeContainsWords Country:USA –RouteMessageOutboundConnector “To USA Users”

Figure 14

Once more, we can use the EAC to ensure everything was configured as expected:

Figure 15

As before, all we have to do now is verify that everything is working as expected by sending a few test emails and analyzing them.

Conclusion

In this article we looked at what Conditional Mail Routing is in Exchange Online by exploring a couple of simple scenarios. Remember that this is a powerful feature that can be used to meet a variety of different requirements.