Centralized Mail Flow (also known as Centralized Mail Transport, CMT) is an option in Exchange hybrid environments whereby all outgoing Internet messages from mailboxes in Exchange Online are first routed through the local Exchange organization before being delivered to the Internet. Similarly, depending on the MX strategy, incoming Internet messages can first pass through the local environment before being delivered to cloud mailboxes. The goal is usually to continue applying central compliance, DLP, encryption, journaling, or gateway functions in the local infrastructure. As a rule, CMT is configured as part of the hybrid configuration using the Hybrid Configuration Wizard (HCW).
Microsoft generally recommends pointing MX records to Exchange Online Protection (EOP) and filtering emails in the cloud, as this provides "the most accurate spam filtering." In hybrid environments, this is the preferred default setting. This is because CMT increases complexity, bandwidth requirements (additional hops), and creates a technical dependency on the local infrastructure. The Exchange engineering team, therefore, advises enabling CMT only if there are compelling transport requirements (e.g., Edge address rewriting, special transport agents) that Exchange Online does not yet support. For these reasons, the CMT configuration option is also disabled by default in HCW.
In the centralized model, outgoing messages from Exchange Online are not delivered directly to the Internet by Microsoft. Instead, EOP routes them via a TLS-encrypted SMTP connection through an outgoing connector to the on-premises Exchange organization, where local policies, gateways, and signatures apply. Only then is the message delivered to external recipient addresses on the internet. This applies to all internet destinations, except for internal cloud recipients in the same Exchange Online organization.
For incoming messages, the routes depend on the MX strategy. If the MX points to EOP, EOP accepts the message and, if CMT is desired for incoming traffic, can first route it to the local organization before delivering it to the cloud mailbox. However, this is a relatively rare use case.
In most cases, when using CMT, the MX points to the local messaging infrastructure. In this case, incoming messages from external senders are first processed on-premises and then, for recipient addresses in Exchange Online, routed to Exchange Online Protection.
Important: There must be no SMTP-modifying systems between Exchange Online and the local Exchange organization; otherwise, the "internal" trust relationship will be lost.
The following high-level diagrams illustrate the difference. Variant A illustrates a direct relationship between an Exchange mailbox server and Exchange Online, while variant B illustrates a relationship between an Edge Transport Server and Exchange Online.
Figure 1: Centralized Mail Transport Figure 2: Decentralized Mail Transport
Reuse of existing gateways
Disclaimers, signatures, S/MIME/PGP encryption, DLP, archiving/journaling, without having to immediately operate cloud equivalents
Address rewriting
Customization of sender addresses on Edge Transport Servers, e.g., for M&A implementations that Exchange Online does not offer natively
Uniform compliance enforcement
The same rules are applied to all mailboxes (on-premises & Exchange Online) in the local IT infrastructure
Microsoft warns us, of course, about side effects such as additional latency/hops, increased bandwidth requirements, greater complexity in troubleshooting, and permanent dependence on the local Exchange infrastructure.
Microsoft has introduced a Tenant External Recipient Rate Limit (TERRL) in Exchange Online. TERRL defines a tenant-wide upper limit on how many external recipients (domains not accepted in the tenant) may be contacted within a rolling 24-hour window.
This limit scales with the number of licensed email plans in the tenant according to the formula:
TERRL = 500 × (number of non-trial email licenses^0.7) + 9500.
Trial tenants have a fixed limit of 5,000.
If the TERRL is exceeded, Exchange Online blocks further external mailings with an NDR 550 5.7.233 (or 5.7.232 for trials).
Microsoft started in April 2025 with small tenants (≤ 25, then ≤ 200, then ≤ 500 licenses). The final phase for "all remaining" tenants is currently paused. A new EAC report ("Tenant Outbound External Recipients") shows the limit, usage, and enforcement status for your tenant.
It is important to distinguish this from the Mailbox External Recipient Rate Limit (MERRL/ERR). This is a limit at the mailbox level. A limit of 2,000 external recipients per 24 hours is planned.
Short answer: Yes. TERRL is enforced in Exchange Online and counts all messages to recipients with recipient domains outside the accepted domains that are routed through Exchange Online. This is independent of the subsequent routing, i.e., directly to the Internet or first back to on-premises via CMT. CMT does not bypass the limit.
Why is that? The definition of "external recipient" depends on the recipient domain type, not the delivery route. If a cloud mailbox in EXO sends to user@contoso.com, this recipient address is counted as external, even if CMT first routes the message to the local organization and only then delivers it to the internet. TERRL, therefore, counts on exit from Exchange Online.
Special cases and stumbling blocks:
When sending on-premises directly to the internet (i.e., without transit through Exchange Online), TERRL does not apply because the limit is enforced and counted by the EXO service. In mixed hybrid setups with many purely local outgoing emails, TERRL usage can therefore be significantly lower. Until EXO mailboxes come into play.
CMT does not reduce TERRL
Every EXO mailbox that sends messages to external recipient addresses whose domain is not one of the accepted domains in Exchange Online contributes to the TERRL balance.
Additional hops increase complexity
Each hop in SMTP communication is another point where delivery problems and thus NDRs can occur.
Be sparing with detours
If you need to use third-party systems (e.g., for signatures), limit the scope of messages to be routed and avoid round-trips through EXO. When using cloud signature solutions, an outgoing message may contribute twice to TERRL.
Yes, and not only is it possible, but it is also the recommended approach. Microsoft has developed Exchange Online Protection (EOP) and Defender for Office 365 (MDO) to provide you with comprehensive and modern protection. And that without the additional complexity that a centralized message flow entails.
When you set the MX record directly to EOP, you leverage the full power of cloud security mechanisms. This means that your incoming emails are immediately checked by the latest anti-spam, anti-malware, and anti-phishing filters. With the "Standard" and "Strict" preset security policies in Defender for Office 365, you get additional protection against targeted attacks such as impersonation, as well as features such as Safe Links and Safe Attachments, which analyze suspicious content in real time. At least, if the appropriate MDO licensing is active in your tenant.
Of course, there are exceptions. If you have specific requirements that only your local environment can meet, such as industry-specific compliance requirements, CMT may still be useful. But for most companies, direct delivery via EOP is secure, efficient, and future-proof.
Regardless of whether you opt for centralized message flow or direct delivery via EOP, monitoring is the key to identifying problems early and avoiding outages. Exchange hybrid environments are complex – transport paths, connectors, authentication, and limits such as TERRL must always be kept in mind. Without good monitoring, you often notice something is wrong when the first emails stop being delivered or when users complain.
This is where ENow's monitoring solution for Microsoft Exchange comes in. ENow offers you a central platform that not only monitors the availability and performance of your Exchange servers, but also hybrid components, mail flow, and important Microsoft 365 services. With clear dashboards and proactive alerts, you know immediately where action is needed, before it becomes critical.
In short, monitoring for Exchange is not a 'nice to have,' it’s a must if you want to operate a stable and secure messaging infrastructure. With ENow, you have the right solution at your fingertips.
"Centralized message flow – yes or no?"
No, if it's not necessary. CMT was and is a useful bridge concept for preserving existing on-premises processes. But the clear recommendation is that direct delivery via EOP with the integrated protection mechanisms of EOP/Microsoft Defender for Office 365 is less complex and offers better filter accuracy.
And TERRL? CMT does not change the TERRL principle. Every EXO message to external recipients counts, even if it is routed via CMT on-premises. If you use third-party services in the cloud, you should check the email routing carefully to avoid double-counting or unnecessary utilization of the tenant limit once it is active for your client.
Trust in EOP/MDO? Yes. With an EOP MX, the recommended Defender baselines, and clean authentication, you can confidently cover most requirements. CMT remains the exception for a few clearly defined special cases.