Highly Available Office 365 to On-Premises Mail Routing

This article looks at how to configure mail flow from Office 365 (via Exchange Online Protection – EOP) to your On Premises organization to ensure that it is highly available and work in disaster recovery scenarios with no impact. It is based on exactly the same principle to that which I blogged about in 2012: http://c7solutions.com/2012/05/highly-available-geo-redundancy-with-html on creating redundant outbound connections from Exchange on premises.

The best way to explain this feature is to describe it in the way of an example:

For example MCMEmail Ltd have Hybrid set up, and delivery to the cloud first. So the DNS zone for mcmemail.co.uk has MX pointing to EOP.

They then create a new DNS zone at either a subzone (as in this example) or a different domain if they have one available. In the example this could be hybrid.mcmemail.co.uk. Into this zone they add the following records:

10 MX oxford-a.hybrid.mcmemail.co.uk

10 MX oxford-b.hybrid.mcmemail.co.uk

20 MX nuneaton.hybrid.mcmemail.co.uk

The below picture shows an example of this configured in AWS Route 53 DNS (though there are other DNS providers available)


In Exchange Online Protection administration pages (Office 365 Portal > Exchange Admin > Mail Flow > Connectors and modify your on-premises connector to point to the new zone. Example shown in the below picture:


Then all email is always delivered to the Oxford datacentre and nothing to the Nuneaton one (where the DR servers reside) unless the two Oxford datacentres (A and B) are both offline and so the 10 preference does not answer at all. At that time and that time only does the 20 preference get connected to.



24 responses to “Highly Available Office 365 to On-Premises Mail Routing”

  1. Ed Crowley avatar
    Ed Crowley

    Useful post. Thanks!

  2. filip avatar

    Does this also require that the ssl cert used for SMTP must contain all mx fqdn? So I need 3 external ip, 3 mx record & san cert with 4 fqdn?

    1. Brian Reid avatar

      No. The certificate name is does not need to match the FQDN for SMTP. For the connectors you can specify the certificate CN value that must be presented by the server when Office 365 connects (Outbound Connector) or when you connect to Office 365 (Inbound Connector). If the certificate name is correct then the connection will work. This is the TlsCertificateName property of the connector. Note that TechNet says “The TlsCertificateName parameter specifies the X.509 certificate to use with TLS sessions and secure mail. Valid input for this parameter is [I]Issuer[S]Subject. The Issuer value is found in the certificate’s Issuer field, and the Subject value is found in the certificate’s Subject field”, but you can just use the subject name as well.

      If you do not specify TlsCertificateName then SMTP will use Opportunistic TLS, which means any certificate (valid or not) will work.

      1. filip avatar

        Thanks Brian, all clear about the cert.
        Unfortunately external ips are scarce so not always applyable, but love your solution.
        On another note can we use a NLB or would a LB adjust the TLS SMTP as a smarthost would do ? And if we use LB we need to add its ip to the receive connector and we miss the source ip and see LB ip instead. How do you fix this?

      2. filip avatar

        Brian, I found this TechNet article that suggests you put a transport fqdn on the certificate. Is this the fqdn you enter during the HCW ?


        1. Brian Reid avatar

          The value of the FQDN is the endpoint you connect to. The certificate subject alternate name for transport does not need to match this

          1. filip avatar

            Hi Brian,
            Sorry to bother one more…
            I found this TechNet article also, they mention EOP drops if the FQDN is not on the cert/san.


            When using forced TLS transport, the sending and receiving servers examine the certificate configured on the other server. The subject name, or one of the subject alternative names (SANs), configured on the certificates must match the FQDN that an administrator has explicitly specified on the other server. For example, if EOP is configured to accept and secure messages sent from the mail.contoso.com FQDN, the sending on-premises Client Access or Edge Transport server must have an SSL certificate with mail.contoso.com in either the subject name or SAN. If this requirement isn’t met, the connection is refused by EOP.


            The FQDN used doesn’t need to match the email domain name of the recipients. The only requirement is that the FQDN in the certificate subject name or SAN must match the FQDN that the receiving or sending servers are configured to accept.

          2. Brian Reid avatar

            You are not doing “Forced TLS Transport” for hybrid. The wizard sets the inbound connector with the string that it expects to find in the certificate and is nothing to do with the FQDN of the domain. Then when on-premises connects to EOP, EOP validates the certificate matches the string and if so lets you in

          3. filip avatar

            Could not find that in any Microsoft documentation (about the fqdn not needed on cert), is it documented anywhere or a glitch in the Microsoft documentation πŸ™‚
            Is it advisable to put the HCW FQDN on the cert or do you consult/implement a certificate with only autodiscover and webmail.companyname.com on the certificate?

            So hybrid mail flow is Opportunistic TLS and not Forced TLS?

            Does this mean o365/connector checks the certificate string and if it’s on the on-prem connection it’s accepted and uses secure smtp? and does this secure smtp use port 25 or port 587 ?
            Do we need to publish/nat 25 and 587 on the firewall to the on-prem exchange servers?

          4. Brian Reid avatar

            Hybrid mail flow is TCP 25 only. And you only need to publish the Exchange Servers you list in the hybrid wizard.

            Hybrid mail flow sets the TLSCertificateName property on the connector and will only deliver if the Send Connector on-premises TLSCertificateName value matches the certificate offered by the receive connector in EOP. The reverse is also true, the Outbound Connector in EOP needs to have the TLSCertificateName value set to the subject name of your on-premises certificate (as selected in the hybrid wizard).

            This is not Opportunistic TLS (which will downgrade to plain text if no certificate is offered [no STARTTLS]) or Forced TLS where the certificate must match the FQDN of the server. The FQDN of the server is irrelevant for hybrid mail flow.

          5. filip avatar

            Cristal clear Brian!
            So you can even use a trusted 3rd party cert with a complete other fqdn then exchange uses cause the CN is used, interesting.

            Thanks for all your time, explanation & patience.
            Will you be attending/present on Ignite?
            If yes I’ll buy you a beer/pint πŸ™‚

          6. Brian Reid avatar

            Yes, I’ll be at Ignite. Not sure if presenting yet!

          7. Dave avatar

            Hi Brian, you mentioned below – The reverse is also true, the Outbound Connector in EOP needs to have the TLSCertificateName value set to the subject name of your on-premises certificate (as selected in the hybrid wizard).

            I have set TlsCertificateName and have found that the receive connector (on Edge server) is still accepting mail from clients with no certificate. Any advice? was looking to restrict access to the valid certificate (along with IP restriction)


          8. Brian Reid avatar

            If you use just the IP restriction, which the hybrid wizard does in later versions of Exchange, then you dont need the certificate restriction as well

  3. Brian Reid avatar

    Yes, you can use a load balancer. But unless you do “direct server return” feature of the load balancer you will see the IP of the load balancer. The DSR feature will be called different things in different makes of load balancer.
    A load balancer would not adjust the certificate (layer 4 load balancing), but would if layer 7 load balancing. Typically for SMTP you do layer 4 (TCP).

    1. filip avatar

      Brian, interesting and also thanks for pointing that layer 7 LB breaks β€œX-MS-Exchange-Organization-AuthAs”.
      For sinlge external ip it’s best to go for layer 4 DSR
      It’s never easy in the Exchange world πŸ™‚

  4. filip avatar

    On another note, is it supported to use ssl offloading for all Exchange services in a hybrid environment?

  5. Brian Reid avatar

    SSL offload – no. MRS does not support offloading.
    Regarding X-MS-Exchange-Organization-AuthAs I did not say Layer 7 load balancers changed anything. The load balancer should pass the data through untouched after inspection.

  6. filip avatar

    In Your previous post i read

    A load balancer would not adjust the certificate (layer 4 load balancing), but would if layer 7 load balancing.

    I understood ‘layer 4 not but layer 7 would’
    So neither layer 4 &7 will touch x header?
    Can we enable SSL offloading for ews but somehow leave SSL enabled for mrsproxy specific?

    1. Brian Reid avatar

      X-Header and certificate are not the same thing. Layer 7 and the certificate is in the load balancer, layer 4 and it is not. Headers nit modified at all.

      SSL offloading – not unless your LB allows it with complex rules.

  7. filip avatar

    Kuddo’s to you Brian. Again my big thanks. I need some load balancer schooling. Life as Exchange admin is though πŸ™‚
    Enjoy your weekend!

  8. Nick avatar


    Do you have any official documentation on this?

    I had my send connector in EXO configured using an MX record composed of 2 A records in separate datacenters of equal weight.

    When one DC was down message delivery to on-premise mailboxes was intermittent.

    Message trace in EXO shows failure to the one MX record and no reattempts to the alternate MX record.

    Microsoft support said I should configure multiple smart hosts in Exchange Online send connector instead.

    1. Brian Reid avatar

      So this article was written in 2014, so there is no guarantee it still works (I’ve certainly not tested it). If you create a single outbound connector with multiple smarthosts that will work.

      Exchange Online routes email and if the endpoint is unavailable it will mark the endpoint as such and recheck it intermittently (initially quickly incase of a network glitch, and then more infrequently like 15 or 30 minutes). Once the endpoint is back online, Exchange Server will reuse it. So if you have multiple smarthosts Exchange Online will only deliver to the ones that it thinks are online.

      The disadvantage of this is that it would route to both the primary and DR datacenters at the same time (as both are online). The MX record method (which though I have not tested I am sure is still working) relies on having two different preference values and not two of the equal weight (as in your example). There is no point doing the MX approach if you have equal weights as that means equal delivery, and this blog post is all about unequal delivery.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.