A reader emailed to ask:
During a Hybrid deployment, where should the MX records point for mail flow?
This question is asked quite often during customer projects, and the answer is really “it depends”. Let’s take a look at some of the common scenarios I encounter in the field for configuring MX records in a Hybrid deployment.
Scenario 1 – MX Records Pointing to On-Premises Exchange Servers
This scenario of MX records pointing to on-premises Exchange servers is usually due to one or both of the following business and technical requirements:
- The majority of the organization’s mailboxes are on-premises
- The customer needs to use centralized transport to meet their compliance requirements
The effect of this configuration is that email from the internet is received first by on-premises Exchange, and then routed to Exchange Online for any cloud mailboxes. Often when customers are beginning a Hybrid deployment and are only moving a small number of pilot users to the cloud they will retain the MX records pointing to on-premises Exchange. Later as the migration progresses they may choose to cut the MX records over to Office 365 instead, especially if going “full cloud” is the plan.
MX records pointing at on-premises Exchange is often combined with centralized transport, which means that outbound email from Exchange Online mailboxes is routed via on-premises Exchange as well. Centralized transport is often used to meet a compliance requirement, for example journalling all email messages, holding outbound email messages for moderation, or stamping all outbound emails with a disclaimer.
The on-premises server used in this topology may also be an Edge Transport server if the organization requires SMTP traffic to traverse a perimeter network instead of internal servers.
Scenario 2 – MX Records Pointing to Office 365
This scenario of MX records pointing to Office 365 is usually due to one or both of the following requirements:
- The majority of mailboxes are in Exchange Online
- The customer is using Exchange Online Protection for email hygiene
The effect of this configuration is that inbound email is first received by Office 365 where it is scanned by Exchange Online Protection before it is routed to cloud or on-premises mailboxes. This solution can replace third party email hygiene products and services, which is convenient for customers that want to reduce costs and leverage the security of Exchange Online Protection to protect their email.
As with the first scenario the routing between Exchange on-premises and Exchange Online can be via an Edge Transport server if the organization requires it.
In this configuration you should take care to configure your firewall to only allow inbound SMTP from the Office 365 IP ranges. Otherwise you may find that even though no MX records are pointing to the Exchange server, attackers will still detect an open SMTP port with an active server listening and will target it with spam, malware and phishing emails anyway.
Scenario 3 – MX Records Pointing to a Third Party Device or Service
In this final scenario the MX records for the domain are pointing to a third party email security device or service. This may be a cloud-hosted service, or it may be a virtual appliance running inside of the corporate network. This solution is often used when the company has a third party email security device or service that they wish to continue using, either due to a subscription that is yet to expire, a specific feature that they rely on, or a determination that it will provide more effective protection than Exchange Online Protection.
Where the email is routed after the third party device or service processes it can be either Exchange on-premises, or Exchange Online.
This decision usually depends on the same factors as the previous scenarios – whether the majority of mailboxes are on-premises or online, and whether centralized transport is used.
Again, care should be taken to ensure that the internal Exchange server is not exposed to direct SMTP connection from the internet. The firewall should only allow inbound SMTP to Exchange by the email security device or service, Office 365, or both, depending on the mail routing requirements.
Summary
As you can see MX records for Hybrid deployments do not have a single solution that fits all scenarios. It all depends on your business and technical requirements, and whether any third party products are involved in your mail routing. Always take the to carefully plan your MX records and firewall rules for Exchange Hybrid deployments to ensure you do not have any unwanted connections hitting the on-premises Exchange servers directly.
[adrotate banner=”50″]
Hi Paul,
we have exchange 2016 on prem and outlook2013 auto discover configure after the mailbox migration to exchange online. we will point the MX record to O365.
users need to reconfigure mailbox again on pcs ? and what about the mailbox configured on mobile devices ?
Hi Paul,
IF MX Pointed to On-prem.Then how can we go for DKIM,Dmarc in on-prem exchange server.
Hi.
Ok so we have scenario 1 and has been working fine for a year. We now want to move to scenario 2.
Updating the MX record is fairly straight forward but do we need to make changes to the hybrid setup wizard to tell if primary mail flow is now going to O365?
Thanks
Rick.
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
It depends. Most likely yes, the HCW will be re-run if you need to turn off centralized transport or adjust the connectors. There’s some more detailed documentation on TechNet now for the various mail flow scenarios:
https://technet.microsoft.com/en-us/library/jj937232(v=exchg.150).aspx
Hi Paul,
Thanks for article, i have a question and a problem with my configuration:
We setup a hybrid environment with Exchange 2010, however onpremises users cant send email to some destinations, outlook, google and majority ar ok but with few recipients i got error(O365 accounts does not have this problem):
451 4.4.0 Primary target IP address responded with: “421 bosimpinc14 bizsmtp Temporarily rejected. Reverse DNS for xxx.xx.xx.xx failed..” Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.
i am using an edge to route external onpremises mail.
My DNS configurations are:
MX> Actual record 10 @ mail.messaging.microsoft.com. 3600
SPF> Actual record @ v=spf1 ip4:external ip mx include:spf.protection.outlook.com ~all
(external ip is mail.domain.com, my onpremises owa is, solmail.domain.com)
hope you can help me
thanks
Armando
Hi Paul,
Based on your article here we are setup similar to scenario # 3. For some reason the routing isn’t working properly. Our on-premise Exchange 2010 functions but the Office 365 test mailbox is only able to send out but not receive. I sent a test to myself internally and externally. The email came to my outlook inbox but when I log into Office 365 web mail there is nothing there. The MX record points to our Barracuda Spam filter appliance. I do have port 25 enabled inbound / outbound on our firewall to allow the block of Microsoft IP addresses. Thanks in advance for any help you could provide.
Al
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
“The email came to my outlook inbox but when I log into Office 365 web mail there is nothing there.”
What is Outlook connecting to? Your on-premises server, or a cloud mailbox?
Thx for this article
If I want to use “SCENARIO 2 – MX RECORDS POINTING TO OFFICE 365” with 1000 mailboxes on-premise and 50 mailboxes in Office 365 (for VIP only for example)
Do I have to pay “only” 50 Office 365 subscription (for my 50 Office 365 mailboxes) with a mailflow cleaning done by EOP for my 1050 mailboxes or do I have to pay something else to MS ?
https://products.office.com/en-us/exchange/microsoft-exchange-online-protection-email-filter-and-anti-spam-protection-email-security-email-spam
Or does MS only apply EOP on my 50 Office 365 mailboxes and redirect to my Exchange on-premise servers the native mailflow (not cleaned) for my 1000 on-premise mailboxes ?
thx in advance
Jean
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
EOP is licensed per user. Beyond that I can’t give you licensing advice. You should speak to your license reseller to determine the correct licensing for your situation.
@Brandon makes a good point. It was surprising (and somewhat disconcerting) to learn this was happening. I’m pretty sure it applies to both Scenario 1 and Scenario 3 (really, any scenario where the MX records don’t point to Office 365/EOP). Basically, if you have Exchange Hybrid configured and *think* you have configured it so that all inbound mail routes first through something other than O365, that is likely not the case. I also think there is some danger in situations were you may not have completely/correctly configured your Hybrid deployment for mail flow that some mail won’t get through. It’s a mail flow situation that isn’t necessarily obvious/noticeable until you start digging into O365 mail traces and email headers but, could be pretty important – especially to organizations that have strict compliance requirements. As Brandon mentions, there ARE workarounds but, those aren’t the most obvious either.
Agree with Brandon that it is ‘pretty goofy’ and, more importantly, isn’t really documented anywhere that I could find (by Microsoft or the community).
I think one thing that should be mentioned in a Hybrid scenario like #3 is that it doesn’t actually completely work like this as per Microsoft with cases we have opened. If you have split setup w/ Mailboxes in O365 and on-Premise and your MX is pointed to a 3rd party device (say another anti-spam provider), any senders who are customers of O365 (I believe their EOP) will actually ignore your MX record and will instead deliver directly to O365. This is pretty goofy IMO, but something to consider if you expect all traffic to flow through something else first – you will have to add connector and rule to force traffic coming directly from outside the organization to instead be sent to your external MX (indirect, but forces what you had intended).
Thanks Paul! Great article as usual. Have a good use case for option #3. I have a client who is primarily on-prem with a few test mailboxes w/ O365. The use case for pointing MX records to third-party mail hygiene provider but with the ability to switch MX records (with low TTLs) to EO, should the provider encounter an issue (again). I think this recent outage of the third party provider raised many questions regarding redundancy of the provider and to find some alternatives.
Thanks Paul,
I love your idea to share common questions in an easy understandable way
Super class blog as always….
Perfect timing. Thanks Paul – great explanation.