This article contain security best practices to use when you’re designing, deploying, and managing your Exchange Hybrid solution by using on-premises Exchange and Microsoft 365. The best practices are intended to be a resource for IT pros. This might include designers, architects, developers, and testers who build and work with secure Exchange Hybrid solutions.
Note: An overall security model is needed for today’s organizations that can better adjust to the modern environment’s complexity, support the hybrid workplace, and secure people, devices, apps, and data in any location. This is why you should follow the guidelines in our Zero Trust Guidance Center to learn security guidelines across the entire Microsoft and Azure cloud, its principles, and how to implement a Zero Trust architecture using the deployment plans.
1. Entra ID Synchronization
Exchange hybrid deployments typically need a directory synchronization tool in place to replicate on-premises Active Directory information for mail-enabled objects to the cloud. You can either use cloud sync or connect sync to achieve the directory replication.
Whereas cloud sync just uses a light-weight agent that acts as a bridge between Entra ID and Active Directory, connect sync requires a more complex infrastructure. Microsoft recommends hardening your Entra ID Connect server to decrease the security attack surface for this critical component of your IT environment. How can I harden my Entra ID Connect server gives you more information for our security best practices design.
2. Exchange Patch Management
To ensure the security of our cloud services, Microsoft follows the Zero Trust model, which only allows devices and servers that are verified and updated to connect. Servers that are outdated or unpatched are constantly exposed to threats and cannot be trusted, so their email messages are also unreliable. These servers pose a high risk of breaches, malware, hacking, data theft, and other attacks.
We have implemented a transport-based enforcement system in Exchange Online to deal with this issue. This system has three main functions: reporting, throttling, and blocking. It alerts an admin when there are Exchange servers in their on-premises environment that are unsupported or unpatched and need to be fixed (upgraded or patched). It also has the ability to throttle (delay) and block mail flow from those servers if they are not fixed.
Our goal is not to interfere with legitimate email, but to reduce the risk of malicious email coming into Exchange Online by enforcing safeguards and standards for email entering our cloud service. We also want to urge customers who have unsupported or unpatched Exchange servers to secure their on-premises environments. More information about the reporting, throttling, and blocking components and what you need to do as an admin can be found in this blog post.
3. Understanding Exchange Hybrid Mail Flow
Hybrid deployments allow you to have mailboxes in both your on-premises Exchange organization and your Exchange Online organization. To make these two separate organizations look like one unified organization to users and messages, you need hybrid transport. Hybrid transport uses Transport Layer Security (TLS) to authenticate, encrypt, and transfer messages between recipients in either organization. These messages are treated as “internal” by Exchange components such as transport rules, journaling, and anti-spam policies.
Note: Make sure there is nothing that interferes with or changes SMTP traffic between your on-premises Exchange servers and Microsoft 365. The security of mail flow between your on-premises Exchange organization and Microsoft 365 relies on the information in the messages sent between them.
Pointing the MX record for your custom smtp domains in Exchange hybrid environments to Exchange Online Protection (EOPO) is the recommended configuration. All messages sent to any recipient in either organization will be routed through the Exchange Online organization first. Please see mail flow best practices for Exchange Online for more information.
4. Email Authentication
To prevent email messages from fake senders (also known as spoofing), email authentication (also known as email validation) uses a set of rules that check if the messages are genuine and come from expected sources for that email domain (for example, contoso.com). Microsoft 365 checks inbound email using these rules:
- Sender Policy Framework (SPF): helps validate outbound email sent from your smtp domain. In Microsoft 365, the SPF TXT record will be created in your external DNS system for any custom domains or subdomains. This kind of allow list verifies the outbound hostname or IP address and validates the sender to prevent spoofing. In hybrid environments with on-premises mailboxes and mailboxes in Microsoft 365, you also need to specify the IP addresses of all email servers, devices, or third-party services that are authoritzed to send email from your domain. Read more on how to implement and configure SPF TXT record in hybrid environments.
- DomainKeys Identified Mail (DKIM): you can attach a digital signature to the message header of outbound email messages. This signature uses cryptographic authentication to authorize your domain to associate, or sign, its name to an email message. Email systems that receive email from your domain can use this signature to help confirm whether incoming email is genuine. The public key is published in your external domain’s DNS record, and the private key encrypts the header in a domain’s outgoing email. Microsoft is taking care of key management and exchange for your Microsoft 365 custom domains. You can enable DKIM for your Exchange hybrid environment as well, as long as outbound mail flow will be routed through Exchange Online Protection. You just need to follow the same steps as mentioned in the link below.
The addition of using SPF and DKIM is important, because email forwarding might change or remove portions of the message’s envelope. Since DKIM works even when a message has been forwarded, it preserves the encrypted signature. Read more on how to implement and configure DKIM for your custom domains in Exchange Online.
- Domain-based Message Authentication, Reporting, and Conformance (DMARC): works with SPF and DKIM to authenticate mail senders. DMARC makes the destination email systems trust messages sent from your domain. By using DMARC with SPF and DKIM, organizations can get more protection against spoofing and phishing email. It helps receiving mail systems decide what to do with messages from your domain by authorization and that the email (including attachments) has not been modified during transport. It also helps you to decide what should happen if the email fail SPF or DKIM checks by configuring your domain’s external DNS record. You can enable DMARC for your Exchange hybrid environment as well. The MX record must point to Exchange Online Protection (EOP) for both hybrid and cloud-only environments. You just need to follow the same steps as mentioned in the link below. Please note that you should implement this step-by-step and monitor the emails sent by your systems, because it might block legitimate sender systems as well if they are not configured correctly. Read more on how to implement and configure DMARC for your custom domains in Exchange Online.
Email authentication confirms that email messages from a sender (for example, dominik@contoso.com) are valid and match the email domain.
Note: there might some legitimate services which are making changes to the email between the sender and recipient, for example a third-party disclaimer software. In Microsoft 365 Defender, Authenticated Received Chain (ARC) will help reduce SPF, DKIM, and DMARC delivery failures that happen due to legitimate indirect mail flows. More information about ARC can be found here.
5. Directory-Based Edge Blocking
There are many Open Source Intelligence (OSINT) tools available to collect, analyze, and disseminate public available data. Even if attackers are not aware of your mail-enabled objects, organizations often use a postmaster address where emails to invalid recipients will be collected. Thus, a phishing campaign may result in malicious emails being delivered to the postmaster mailbox and malicious code is spreading through your organization.
Directory-Based Edge Blocking (DBEB) allows you to block messages for recipients who don’t exist at the edge of the service network in Microsoft 365 organizations that have Exchange Online mailboxes or in Exchange Online Protection (EOP) organizations that don’t have Exchange Online mailboxes. The service filters messages for valid email addresses in Microsoft 365. If the address exists, the message goes through anti-malware, anti-spam, and mail flow rules. If the address doesn’t exist, the service rejects the message before filtering and sends a non-delivery report to the sender.
Important note: As this feature is working for Exchange hybrid organizations too, please make sure to read the documentation on how to use DBEB to reject messages sent to invalid recipients in Exchange Online carefully, as there might some circumstances where DBEB not work for you.
6. Enhanced Filtering for Connectors
The source of the inbound connector may not show you where the message really came from, if your email for your Microsoft 365 domain is routed through a different email gateway first. This is possible in cases where the email routing is not simple, such as:
- Third-party cloud filtering services
- Managed filtering appliances
- Exchange hybrid environments
Messages adopting the source IP of the service, appliance, or on-premises Exchange organization that sits in front of Microsoft 365. The message in Exchange Online arrives with a different source IP address. This behavior isn’t a limitation of Exchange Online, it’s simply how SMTP works.
Enhanced filtering for connectors (also known as skip listing) allows IP address and sender information to be preserved:
This has the following benefits:
- You can use explicit email authentication (SPF, DKIM, DMARC) to verify the reputation of the sending domain.
- Better post-breach capabilities in Microsoft 365 Defender’s Automated Investigation and Response (AIR)
- Improved accuracy within the filtering stack and machine learning models, like heuristic clustering, anti-spoofing, and anti-phishing.
For more information, please have a look at the Enhanced filtering for Connectors in Exchange Online documentation.
7. Hybrid Modern Authentication
For hybrid deployments of Exchange server on-premises, Hybrid Modern Authentication (HMA) is a way of managing identity that provides more security for user authentication and authorization. You are still authenticating against your on-premises Exchange environment, but how your users are authorizing access to resources like emails changes.
EvoSTS (a Security Token Service used by Entra AD) acts as the Auth Server for Exchange on-premises, which allows to use OAuth to authorize your clients. That in turn allows you to configure Multi-Factor Authentication (MFA), take advantage of using Mobile Application Management (MAM) app protection policies, get access to resources without supplying the users’ password as part of the request, and much more. Please have a look at the doc Additional information on Hybrid modern authentication overview and prerequisites for more information.