ENow Blog | Exchange Center

Centralized Mail Transport in Multi-Forest Exchange Environments

Written by Dominik Hoefling MVP | Jul 19, 2018 5:52:40 AM

Outbound messages to the Internet are routed from the Exchange Online organization through your on-premises organization. With the exception of messages sent to other recipients in the same Exchange Online organization, all messages sent from recipients in the Exchange Online organization are sent through the on-premises organization. This enables you to apply compliance rules to these messages and any other processes or requirements, like digital sign emails at your smtp gateway, or to compliance rules that must be applied to all of your recipients, regardless of whether they're located in the Exchange Online organization or the on-premises organization.

 

Source:

  1. David, who has a mailbox in the Exchange Online organization, sends a message to an external Internet recipient, erin@cpandl.com.
  2. Exchange Online scans the message for viruses and sends the message to EOP.
  3. EOP is configured to send all Internet-bound messages to an on-premises server, so the message is routed to an on-premises Exchange server. The message is sent using TLS.
  4. The on-premises Exchange server performs compliance, anti-virus and any other processes configured by the administrator on David's message.
  5. The on-premises Exchange server looks up the MX record for cpandl.com and sends the message to the cpandl.com mail servers located on the Internet.

Note: Microsoft recommends using centralized mail transport only for organization with specific compliance-related transport needs. For typical, no compliance-related and “simple” Exchange organizations you should not enable centralized mail transport.

Centralized Mail Transport In Single-Forest Environment

A typical Exchange hybrid centralized mail transport configuration after configuring the Hybrid Configuration Wizard (HCW) setting looks like this:

PS C:\Users\domi> Get-OutboundConnector

Enabled                       : True
UseMXRecord                   : False
ConnectorType                 : OnPremises
ConnectorSource               : HybridWizard
RecipientDomains              : {*}
SmartHosts                    : {[192.168.0.1], [192.168.0.2]}
TlsDomain                     : mail.dominikhoefling.com
TlsSettings                   : DomainValidation
IsTransportRuleScoped         : False
RouteAllMessagesViaOnPremises : True
CloudServicesMailEnabled      : True

Centralized Mail Transport in Multi-Forest Environments

For multi-forest Exchange hybrid environments, you must configure Conditional Mail Routing (CMR), also known as Criteria Based Routing. Let’s assume you configure both forest for centralized mail transport with the Hybrid Configuration Wizard (HCW):

PS C:\Users\domi> Get-OutboundConnector

Name                                             RecipientDomains SmartHosts                 Enabled
----                                             ---------------- ----------                 -------

Outbound to 073f4e37-817b-4e4f-8335-fb5ee35195f5 {*} {[192.168.0.1], [192.168.0.2]}             {mail.exchange-lab.de}     True
Outbound to 98224df6-9d55-4716-b248-1cf393803c22 {*} {[192.168.0.3], [192.168.0.4]}             {mail.dominikhoefling.com} True

Of course, you have different smart hosts (for example Exchange EDGE in every organization), but HCW will configure the RecipientDomains attribute with “{*}” and set the attribute RouteAllMessagesViaOnPremises to true. This causes NDR’s for every Exchange organization that will be added to the Office 365 tenant via HCW if the centralized mail transport option is enabled.

Configure Centralized Mail Transport In Multi-Forest Environments

In advance, there are many different configurations available how to route outbound (and maybe inbound messages) via specific connectors with Conditional Mail Routing. Based on a customer requirement to route all outbound messages via on-premises, the configuration can look like this:

  1. Don’t enable centralized mail transport for every Exchange organization via the HCW. This is the default outbound connector which is created after the HCW setup and responsible for the mail flow between Exchange on-premises and Exchange Online:

    PS C:\Users\domi> Get-OutboundConnector

    Enabled                       : True
    UseMXRecord                   : False
    ConnectorType                 : OnPremises
    ConnectorSource               : HybridWizard
    RecipientDomains              : {dominikhoefling.com}
    SmartHosts                    : {[192.168.0.1], [192.168.0.2]}
    TlsDomain                     : mail.dominikhoefling.com
    TlsSettings                   : DomainValidation
    IsTransportRuleScoped         : False
    RouteAllMessagesViaOnPremises : False
    CloudServicesMailEnabled      : True
  1. Create a new outbound connector in Exchange Online which is transport rule scoped, has empty recipient domains, and don’t route messages via on-premises: 

    PS C:\Users\domi> Get-OutboundConnector

    Enabled                       : True
    UseMXRecord                   : False
    ConnectorType                 : OnPremises
    ConnectorSource               : AdminUI
    RecipientDomains              : {}
    SmartHosts                    : {[192.168.0.1], [192.168.0.2]}
    TlsDomain                     : mail.dominikhoefling.com
    TlsSettings                   : DomainValidation
    IsTransportRuleScoped         : True
    RouteAllMessagesViaOnPremises : False
    CloudServicesMailEnabled      : True
  1.  Create a transport rule and scope this rule to the outbound connector created in step 2 in this article:

     

Step 1 to 3 must be done for every Exchange organization that is part of the Office 365 tenant and wants to use centralized mail transport with their on-premises smtp gateway.

Meeting Forward Notification

If you enable meeting forward notification for your remote domains, keep in mind that it will cause NDR’s if someone from the other Exchange organization forwards meeting requests because the FROM header will contain the original sender and tries to send it via the wrong connector. We decided to configure an exception for meeting forwarding notifications so they will be sent out through EOP.

Summary

This configuration example was a requirement in a pilot-stage of an Exchange multi-forest environment. Because of the many different organizations and complexity in mail-routing, we will disable centralized mail transport in the future and configure EOP and ATP to have the same functionality regarding security and compliance like they have it now with a third party smtp gateway.