Exchange Hybrid Deployment Prerequisites: Checklist for Exchange Online

Exchange Hybrid Deployment Prerequisites: Checklist for Exchange Online

Originally published 27 September 2020 · Reviewed 5 November 2026

An Exchange hybrid deployment connects your on-premises Exchange organisation to Exchange Online so that mailboxes can live in either place while users see one organisation: shared calendars and free/busy, a single address book, and mail flow between the two. The Hybrid Configuration wizard (HCW) does the configuration, but it refuses to finish if the environment does not meet its prerequisites. This checklist follows Microsoft's published requirements, which change with Exchange releases and support dates, so confirm the current page before you start.

Exchange versions and updates

• Supported version pairing. Microsoft publishes a table showing which on-premises versions can host which hybrid version. In the table on the current page, an Exchange 2019 organisation supports a 2019-based hybrid deployment, an Exchange 2016 organisation supports 2016-based or 2019-based, and Exchange 2013 and 2010 appear in the table with older hybrid versions. Several of those versions are out of support, so treat them as migration problems, not designs. Exchange Server Subscription Edition also appears in Microsoft's documentation and uses a dedicated hybrid app for some features.
• Latest updates. Microsoft states that hybrid deployments require the latest cumulative update (CU) or update rollup that is available for your version, and that the immediately previous release is also supported. Because CUs are released regularly, falling behind is the most common reason a hybrid configuration stops working.
• Server roles. Exchange 2016 and newer need at least one Mailbox server. Older versions need specific role combinations. Edge Transport servers are supported, must be updated to the latest CU, and should sit in a perimeter network.

Microsoft 365 side

• A plan that supports hybrid. Microsoft states that hybrid deployments are supported in Microsoft 365 and Office 365 plans that support directory synchronisation, including Business Standard, Business Basic and the enterprise, government and education plans. Microsoft 365 Apps for business and Home plans do not support hybrid deployments.
• Registered domains. Add the custom domains you will use to the tenant and verify them.

Directory synchronisation

Deploy Microsoft Entra Connect or cloud sync so that on-premises users, groups and contacts appear in the cloud. A hybrid deployment with single sign-on is strongly recommended by Microsoft, using password hash synchronisation or Active Directory Federation Services, and very large organisations with several forests may need federation. Check the identity design before the mail design.

DNS and certificates

• Autodiscover. The Autodiscover record for your SMTP domains in public DNS must point to your on-premises Exchange servers.
• Public certificates. Exchange services must use a certificate from a trusted public certificate authority. Microsoft states that self-signed certificates cannot be used for Exchange services in a hybrid deployment. The external EWS URL and the Autodiscover name must appear in the certificate's Subject Alternative Name field, and the certificates used for hybrid mail flow must come from the same authority with the same subject.
• EdgeSync. If you use Edge Transport servers for hybrid mail transport, configure EdgeSync before running the wizard, and run it again after applying a CU to an Edge server.

Network and firewall

Microsoft documents the ports and endpoints that hybrid needs. In summary, Exchange Online must reach your on-premises servers on TCP 25 for secure mail flow, and on TCP 443 for Autodiscover and Exchange Web Services. Your servers must reach Exchange Online on TCP 25 and 443. Certificate revocation list endpoints must be reachable. The list of Microsoft 365 endpoints is large and changes, so use Microsoft's published URL and IP address ranges, not a hand-written list. If you publish Exchange through a reverse proxy, check that it does not break the pre-authentication model that hybrid expects.

Tools worth using first

• Microsoft Remote Connectivity Analyzer. Run it against your public Autodiscover and EWS endpoints before the wizard.
• Mail migration advisor. Microsoft's guided tool for planning hybrid or full migration.
• Hybrid Configuration wizard itself. Re-run it after changes; it detects most prerequisite problems.

Before you press go

Write down the answers to these questions. Which Exchange version and CU are we on, and when does support end? Which domains will we share? Who owns public DNS and certificates? Is directory sync working, and with which sign-in method? Which ports are open, and who controls the firewall? Where do we want mailboxes in a year, and should we be planning a full migration instead? If the honest answer to the last question is "all in the cloud", consider whether a hybrid deployment is only a temporary bridge, and plan its removal.

Common reasons the wizard fails

Most failed runs trace back to a short list: a certificate that does not contain the EWS or Autodiscover name, an Autodiscover record that points at the cloud too early, a reverse proxy that rewrites or blocks the hybrid authentication calls, an Exchange server that is two CUs behind, or a firewall rule that allows port 443 but not port 25. Read the wizard's log, fix one cause at a time, and re-run it. Keep a note of the working configuration, because hybrid settings are easy to overwrite during later changes.

Microsoft references

• Hybrid deployment prerequisites, reviewed 5 November 2026.
• Microsoft Remote Connectivity Analyzer, reviewed 5 November 2026.

This article was first published on 27 September 2020. It was rewritten on 5 November 2026 to follow Microsoft's current prerequisites page. Microsoft's live documentation takes precedence if it has changed.