Exchange SE Hybrid (DAG) - Receive Default Frontend Connector

Question

Hello,

I have a question regarding the Exchange SE Default Frontend Receive Connector.

We did not make any custom changes to this connector, however we have noticed that it currently allows anonymous connections from all IPv4 and IPv6 addresses on port 25, and those connections are able to send email to internal domains.

Our intention is to restrict the Remote IP Address scope of this connector, but I am concerned that doing so might impact mail flow, especially communication:

     between on-premises Exchange servers

     between on-premises Exchange and Exchange Online

Our environment details:

No Edge Transport servers

MX records point directly to O365

We use hybrid connectors:

   On‑Premises > Exchange Online

   Exchange Online > On‑Premises

My questions are:

1. Is it safe to limit the Remote IP scope of the Default Frontend Receive Connector to only the IP addresses of our on‑premises Mailbox servers?
2. Could restricting this connector break hybrid mail flow with Exchange Online? If yes which scope of Ip's should I setup?
3. Are there any Microsoft‑recommended best practices for securing this connector in a hybrid environment without Edge servers?

Thank you.

Answer 1

Hi @Checior200

Thank you for sharing your concerns regarding the Default Frontend Receive Connector in your Exchange hybrid environment. 

You could refer to AI's suggestion first. As far as I know, on Mailbox servers the Default Frontend <ServerName> Receive Connector listens on TCP port 25, accepts anonymous inbound SMTP connections, and is designed to receive mail from the internet (when MX records point to on‑premises), from other on‑premises Exchange servers, and from Exchange Online in hybrid scenarios, depending on the configured routing.  

After accepting the SMTP connection, the connector hands messages off to the Transport service for further processing. Allowing anonymous SMTP connections that can deliver messages to internal recipients is by design and does not in itself make the server an open relay, as Exchange enforces strict internal anti‑relay controls to prevent unauthorized message forwarding. 

Regarding your concerns: 

For limiting the Remote IP scope of the Default Frontend Receive Connector to only on‑premises Mailbox server IPs 

I would not recommend this approach, and it is not considered safe in a hybrid environment. 

If the Remote IP ranges are restricted to only on‑premises Mailbox server IPs, mail originating from Exchange Online (via Exchange Online Protection) might be blocked. This is because Exchange Online delivers inbound hybrid mail from Microsoft‑owned EOP IP ranges, not from internal Exchange server IP addresses. 

Could restricting this connector break hybrid mail flow, and which IP scope should be configured if restriction is required? 

Restricting the connector to only on‑premises IP addresses might break your hybrid mail flow from Exchange Online to on‑premises Exchange. 

In scenarios where the connector must be restricted, the Remote IP scope would need to include the following: 

The IP addresses of all on‑premises Exchange Mailbox servers. 

All Exchange Online Protection (EOP) outbound IP ranges used to deliver mail to on‑premises environments 

These Microsoft IP ranges are relatively large and can change over time, making manual maintenance error‑prone and operationally risky. 

Microsoft‑recommended best practices for securing this connector in a hybrid environment without Edge servers 

As my research, you could consider to the following approach:

You should not modify the Default Frontend Receive Connector (leave Remote IP Ranges as “All” and Anonymous authentication enabled). The Hybrid Configuration Wizard (HCW) already configures the necessary TLS settings on this connector for secure hybrid mail flow. 

Secure at the firewall level: Block inbound TCP port 25 from the public internet. 

Allow inbound TCP port 25 only from the official Exchange Online Protection IP ranges (published in the Microsoft 365 URLs and IP address ranges document). 

 

For any internal applications, scanners, or printers that need to send/relay email anonymously, create a separate custom Receive Connector (on the Frontend Transport role) with a very narrow Remote IP scope limited to those specific devices only. Never use the default connector for this. 

I have found some relevant articles that might help, you could refer via: 

Receive connectors | Microsoft Learn 

Set up the Built-in security add-on for on-premises mailboxes  

Scenarios for custom Receive connectors in Exchange Server  

Please note that this summary is based on my own findings and may not fully address your concerns. To help you reach your goal more effectively, I recommend engaging with [GitHub Community Forum] for a deeper technical dive or to connect with individuals who have relevant experience and expertise. Some approaches may behave differently or be restricted depending on your specific environment and configuration. These forums include many experienced developers and Microsoft specialists who can assist with troubleshooting and guidance.  

Apologies for redirecting you to the related development team support. As moderators in this community, we do not have access to your specific tenant configuration, and my testing environment is limited. Therefore, my guidance is based on available Microsoft documentation and resources. That said, I’ll do my best to provide additional insight where possible.  

I hope this helps.  

If you have any additional concerns, feel free to comment below. I would be more than happy to assist. 

---

Note: Please follow the steps in [our documentation] to enable e-mail notifications if you want to receive the related email notification for this thread. 

Answer 2

1. It is not recommended to restrict the Remote IP scope of the Default Frontend <ServerName> Receive connector to only the IPs of on‑premises Mailbox servers. In Exchange Server, the Default Frontend <ServerName> connector is explicitly designed as the common SMTP entry point that:
   • Listens on TCP 25 on all local IPs.
   • Accepts anonymous connections from all remote IPs.
   This behavior is by design and is the standard way to receive email from the internet when MX records point to the on‑premises server. Even though MX records in this environment point to Exchange Online, the same connector is still the default “internet‑style” entry point for any SMTP traffic that does reach the on‑premises server. If the remote IP scope is restricted only to on‑premises Mailbox server IPs, any other SMTP source (for example, internal devices, applications, or future mail‑flow changes) that relies on anonymous SMTP to this server could fail. Microsoft guidance for scenarios that require restriction is to create additional, more specific connectors rather than tightening the default one.
2. Restricting the Default Frontend connector can break mail flow, including hybrid, depending on how hybrid is configured and which IPs Exchange Online uses to reach on‑premises. Key points from the documented behavior:
   • The Default Frontend <ServerName> connector is the “common messaging entry point into your Exchange organization” and is configured to accept SMTP from all IP ranges on port 25.
   • When multiple Receive connectors exist on the same server with the same local IP/port, the connector with the most specific remote IP match is chosen for a given connection.
   In a hybrid configuration, Exchange Online typically connects to the on‑premises endpoint defined in the “From: Office 365 → To: Your on‑premises mail server” connector. If that endpoint resolves to this server and port 25, then Exchange Online’s IPs must be allowed by at least one Receive connector on that server. If the Default Frontend connector is restricted to only on‑premises Mailbox server IPs and no other connector on port 25 includes Exchange Online’s IP ranges, inbound hybrid mail from Exchange Online to on‑premises will fail. Microsoft guidance for similar scenarios (for example, anonymous relay) is:
   • Keep Default Frontend <ServerName> as the general‑purpose, internet‑style connector.
   • Create an additional Front End Transport Receive connector on the same port 25, but with a restricted Remote IP list for specific hosts. The connector with the most specific remote IP match wins.
   By analogy, if a dedicated connector for Exchange Online IPs is desired, it should be created as an additional Front End connector with:
   • Local binding: same IP/port (25) as Default Frontend, or a specific IP if the design requires it.
   • Remote IPs: the specific Exchange Online outbound IP ranges used for hybrid.
   This avoids breaking hybrid while still allowing more granular control.
3. Microsoft‑aligned best practices for securing Receive connectors in a hybrid environment without Edge servers are:
   • Do not convert the Default Frontend <ServerName> connector into a restricted or “special‑purpose” connector. It is intended to:
     • Listen on port 25 on all local IPs.
     • Accept anonymous connections from all remote IPs.
   • For special scenarios (anonymous relay, restricted sources, appliances, or specific IP ranges), create additional custom Receive connectors in the Front End Transport service rather than modifying the default one. For example:
     • A dedicated anonymous relay connector on port 25 with a restricted Remote IP list for internal devices, as described in the anonymous relay guidance.
     • Additional connectors bound to specific local IP addresses or restricted remote IP ranges when needed.
   • When multiple connectors share the same local IP/port, rely on the documented behavior that the connector with the most specific remote IP match is selected. This allows keeping Default Frontend open for general use while enforcing restrictions for specific hosts via dedicated connectors.
   • If a custom internet‑facing connector is ever needed on port 25, ensure that either:
     • The default connector is removed and the new connector uses the same binding, or
     • The default connector’s local binding is changed to a different IP, and the new connector uses a different local IP on port 25, as documented for custom internet connectors.
   Overall, the recommended pattern is:
   • Leave Default Frontend <ServerName> in its default, broadly open configuration.
   • Add dedicated, more specific Front End connectors for restricted IP ranges (including Exchange Online IPs if desired), rather than tightening the default connector’s Remote IP scope.

---

References:

• Receive connectors in Exchange Server
• Scenarios for custom Receive connectors in Exchange Server
• Receive connectors
• Allow anonymous relay on Exchange servers
• Configure mail flow using connectors in Exchange Online
• Do I need to create a connector in Exchange Online?