Replacing X-Anonymous TLS with Mutual TLS (mTLS) on Exchange Server Default Receive Connectors

Question

Hello,

I am hoping that someone can provide some insight and direction for a request that my organizations' Cybersecurity Team made.

I am being requested to replace X-Anonymous TLS with Mutual TLS on Exchange Server SE Default Receive Connectors in the Transport (Hub) service that is using port 2525 for server-to-server communication to meet a Zero Trust requirement.

Is it possible to be done?

Should the Default Receive Connectors in the Transport (Hub) service using port 2525 be modified?

Or, should the Default Receive Connectors in the Transport (Hub) service using port 2525 be disabled and replaced with new custom Receive Connectors to me this Zero Trust requirement?

Answer 1

To replace X-Anonymous TLS with Mutual TLS (mTLS) on Exchange Server Default Receive Connectors, you will need to consider the following:

1. Mutual TLS Configuration: You can configure Receive connectors to use Mutual TLS by enabling the appropriate authentication mechanisms. This involves ensuring that the connectors are set up to require client certificates for authentication. You may need to modify the existing Default Receive Connectors to include the ExchangeServer authentication mechanism, which is necessary for mTLS.
2. Modifying Default Receive Connectors: It is generally possible to modify the Default Receive Connectors, but you should proceed with caution. Ensure that any changes made do not disrupt existing mail flow or connectivity. It is advisable to test the changes in a controlled environment before applying them to production.
3. Creating Custom Receive Connectors: If the modifications to the Default Receive Connectors seem too risky or complex, you can create new custom Receive Connectors specifically designed to meet your Zero Trust requirements. This approach allows for more granular control over the settings and configurations, ensuring that they align with your organization's security policies.
4. Best Practices: Regardless of whether you modify the existing connectors or create new ones, ensure that you document the changes and have a rollback plan in case of issues. Additionally, monitor the performance and security of the connectors after implementation to ensure compliance with your cybersecurity requirements.

In summary, both modifying the Default Receive Connectors and creating new custom ones are viable options. The choice depends on your organization's specific needs, risk assessment, and testing capabilities.

---

References:

• Receive connector changes in Exchange Server

Answer 2

Hi @Harris, Ricardo

Thank you for posting your question in the Q&A Forum.

Transitioning to a Zero Trust architecture in an Exchange environment is an important goal, but it requires carefully balancing security requirements with the stability of internal mail flow. 

The Default Receive Connectors in the Transport (Hub) service are system‑critical. They support internal mail routing, Shadow Redundancy, Safety Net, and Managed Availability health probes. Because these connectors rely on the Kerberos/Active Directory boundary for authenticated encryption (X‑Anonymous TLS), modifying them to strictly enforce Mutual TLS (mTLS) is generally not recommended. Any certificate validation failure, such as an expired certificate or a CRL timeout could disrupt these internal services and halt mail delivery across the organization. 

Exchange already uses X‑Anonymous TLS internally, which provides authenticated encryption within the AD boundary and meets many compliance requirements. If explicit certificate‑based validation (mTLS) is required to align with Zero Trust mandates, a more targeted approach is advisable. 

• Keep Default Connectors as-is: Preserve the original settings to maintain internal system heartbeats and background processes, ensuring core Exchange functionality continues uninterrupted. 
• Create Custom Connectors for mTLS traffic: Set up dedicated connectors specifically for servers or partners that require certificate-based authentication. 
• Scope and bind certificates appropriately: Restrict these custom connectors to specific Remote IP ranges and associate them with trusted certificates using the TlsCertificateName attribute. Please note that for mTLS to work, the Subject Name or Subject Alternative Name (SAN) on the certificate must match the FQDN configured on the Receive Connector. 
• Test in a staging environment: Validate certificate trust across all Exchange nodes, monitor certificate lifecycles, and confirm mail flow before rolling out to production. 

For guidance and technical details, you may find the following official Microsoft documentation useful: 

• Receive connectors | Microsoft Learn 
• Scenarios for custom Receive connectors in Exchange Server | Microsoft Learn 

In practice, leaving the Default Receive Connectors untouched while configuring dedicated custom connectors for mTLS traffic is the supported and safer path. This approach balances Zero Trust security requirements with Exchange’s operational stability. 

I hope this provides a clear and practical path forward for your organization’s security goals. Please let us know if you have any further questions. 

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".  

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.