On-Premises Delivery Failover

Organizations with on-premises mail environments often will have a primary site and at least one backup site. When Exchange Online Protection is being used to protect those on-premises mail environments, the ideal configuration would have EOP only delivering mail to the primary on-premises site, and only to the backup site if the primary site goes down. In EOP, you can add multiple smart hosts to an EOP outbound connector but cannot add priorities to them.

EOP Outbound Connector Refresher

For EOP to be able to deliver incoming messages to your on-premises mail environment you will need an outbound connector in the cloud that is of type on-premises. This connector will be setup with a smart host, which can be either IPs, Fully Qualified Domain Names (FQDN), or a combination of those two, which will point to your on-premises mail environment.

If you have multiple smart hosts entered, the outbound connector will initially choose one at random to deliver a message, and following that will use round-robin load balancing to distribute subsequent messages among the smart host entries. If the initial smart host does not respond, the connector will try the next one and if none of the entries respond, the message will be put into deferral and retried approximately every five minutes for 48 hours. See Inbound and Outbound connector FAQ for more information.

If you have a primary site and at least one backup site, you most likely want all mail to be delivered to the primary site and only delivered to the backup site if the primary fails. Well, this is indeed a possible setup and can be accomplished with some DNS configuration.

Setting up DNS

If you remember from my previous article, Outbound Connector Smart Host Behavior, when an FQDN is entered as an outbound connector smart host, the connector will perform an MX lookup on the FQDN and will take MX Priority into account when evaluating the results. Keeping this in mind, here’s an example.

Ex. Contoso.com has three on-premises sites with different public IPs. Note that in this example I’m using private IPs.

Site A –
Site B –
Site C –

Contoso.com wants EOP to route all incoming mail to site A, but if Site A goes down, then route all mail to Site B. They only want mail delivered to Site C as a last resort if both Site A and Site B are down. The following will need to be configured in DNS.

MX Records

Host MX Priority          Points To



onprem.contoso.com          10 mail-a.contoso.com
onprem.contoso.com 20 mail-b.contoso.com
onprem.contoso.com 30 mail-c.contoso.com

A Records

Host Points To

Now back in EOP, specify onprem.contoso.com as the only smart host in your outbound connector.

From this point on, when EOP needs to deliver mail on-premises, it will look up the MX for onprem.contoso.com and will respect the MX Priority weights that are specified in DNS. Keep in mind that a network hiccup could cause a failover.

Happy failover!

Comments (11)

  1. Ed (DareDevil57) says:


  2. Yes, that’s correct. If the FQDN that has been entered does not have an MX associated, then we will send to the A record. Otherwise, if an MX exists for the FQDN then we will send to the MX record.

  3. This solution will work with a hybrid setup as well.

  4. Hi there Roger, I believe I understand your question, but if I don’t please let me know.

    In your situation, you have a single EOP Outbound connector of type on-prem. The scope for this connector contains multiple domains.

    The above solution will still work as you only need to enter one smart host in your EOP outbound connector. All of your domains will be pointed towards .mail.protection.outlook.com. Once inbound messages arrive at EOP, they will be scanned and then sent out
    your EOP outbound connector. This connector will have a single smart host setup, and this smart host domain will have the MX setup that I laid out in this article.

    Does that make sense? Did I understand your question correctly?

  5. Hi there Anonymous, notice that the domains in my example that both have the same priority are actually different domains. The sender sending you a message would do an MX lookup on your domain, contoso.com, which will return contoso-com.mail.protection.outlook.com.

    EOP will receive and scan the message. Now, when EOP goes to deliver the message on-prem, the EOP outbound on-prem connector that you create will have onprem.contoso.com in the smart host field. This will cause EOP to do an MX lookup which will return the 3
    on-prem locations, each with a different weighting. EOP will first try the lowest priority, if that doesn’t work EOP will then try the next highest priority, and so on. This way, EOP should always deliver to your lowest priority MX record unless it doesn’t
    respond, then EOP will try the next highest priority. This is basically your failover setup in which EOP will only deliver to your failover box if the primary doesn’t respond.

  6. Junaid Mansoor Sootwala / TAJMAC IT Solutuons says:

    Any issues if we use this in Exchange Hybrid?

  7. Yesai Tchouldjian - SADA Systems says:

    I have a question… You mentioned. "When an FQDN is entered as a smarthost, it will perform an MX lookup on the FQDN" .. It actually does an A record lookup and sends directly. Are you saying it checks MX first on the FQDN, then it checks A record?

  8. Anonymous says:

    I only began this blog in June of this year and so it’s hard to believe that it is already six

  9. Roger Anderson - Aerospace Distributors says:


    I came across this solution today – sorry for the late post. I seems a good solution for a single domain – contoso.com

    How might this be modified if the environment has more than one domain, which all use the same outbound connector? I was stopped when trying to create the MX records, as each require the use of the same "onprem" reference – but the domain names are different.


  10. Anonymous says:

    Hi Andrew,

    I came across your solution while researching this very topic. In your example, when adding the additional MX record, isn't it possible for senders to use the onprem.contoso.com instead of the contoso.com MX record? Mail priorities aren't absolute, meaning
    senders will not just send to the lowest priority (and in your example there are two records that have the same priority wouldn't that just "load balance"), there may be occasion when mail is sent to the higher MX hosts – how can that be addressed?


  11. jack says:

    Which fqdn should be on the ssl cert that used?

Skip to main content