Exchange Admin Center
      Back to home
      1. Sittadel Knowledge Base
      2. Management Guides
      3. Exchange Admin Center

      Email Connector TLS Exception

      This guide will establish the necessary steps required to create a TLS bypass for a trusted organization whose email servers do not allow TLS encryption. Additionally, there will be the inclusion of known errors that could encountered.

      Role Requirements

      Procedure Scope: Administrators

      Required Group Membership: Admin.Security

      Handbook Reference

      Package: TBD

      Domain: TBD

      Modifies: TBD

      Configuring a TLS Bypass

      1. Access the Connections – Exchange Admin Center portal. Select Add a connector, a pop out will be displayed where you will have to specify direction of the traffic. We will need to configure a bi-directional allowance so we will start with configuring an Outbound Rule.
      2. For an Outbound Rule configuration, specify the Connection From as Office 365 and the Connection to as Partner Organization, this will specify the connection from Outlook servers to your Partners Mail servers. Select Next to continue.
      3. You will be asked to supply a Name and Description; these fields should point to the organization that the TLS bypass is being created for. Name should follow the format of Outbound TLS Bypass for [Company Domain], Description should allude to the Creation of this rule is for unencrypted emails to be received by [Company Domain]. We will want to enable this Connector once it has been generated, this is achieved by checking the box next to Turn it on. Select Next to proceed.
      4. We will need to specify the Use of the connector, outlining the specific domains that it should enforce the TLS Bypass for since we do not want to remove the encryption enforcement on all mail sent from our domain to others. Select Only when email messages are sent to these domains, specify the desired domains within the provided field and select the Plus button to finalize the additions. Select Next to continue.
      5. You will be asked to specify Routing of the emails from Outlook to your Partners Mail servers, utilizing the existing records assigned by the partners domain is usually sufficient. Select Use the MX record associated with the partner’s domain and continue by selecting Next.
      6. We will need to remove Security restrictions that could be placed on the desired domain. Make sure to uncheck Always use TLS to secure the connection since this has been identified to not be supported from the partner organizations mail servers. Select Next to continue.
      7. The final step before reviewing the configuration of the connector involves sending a verification email to a live mailbox for the desired domain. Specify an address that you have verified has an active mailbox in the provided field followed by selecting the Plus button and hitting the Validate button, failure to provide an address with an active mailbox will result in a validation error and you will not be allowed to proceed through to the finalization process. Once validation has been fulfilled, select Next to proceed.
      8. To finalize the Outbound TLS bypass, verify that all the fields listed under the Review connector page are correct, if a misconfiguration is detected select the necessary Edit hyperlink under the section. Once reviewed select Create connector to finalize the Outbound bypass.
      9. When created select Done to return to the main page. We will now be configuring an Inbound Rule. Start by selecting Add a connector, from the New connector popup we will specify the Connection from as Partner Organization the default Connection to will be Office 365. This will specify communication from your Partners mail servers to internal Outlook mail servers. Select Next to proceed.
      10. You will be asked to supply a Name and Description; these fields should point to the organization that the TLS bypass is being created for. Name should follow the format of Inbound TLS Bypass for [Company Domain], Description should allude to the Creation of this rule is for unencrypted emails to be received by [Company Domain]. We will want to enable this Connector once it has been generated, this is achieved by checking the box next to Turn it on. Select Next to proceed.
      11. We will need to Authenticate sent mail received by the partner domain, outlining the specific domains that it should enforce the TLS Bypass for since we do not want to remove the encryption enforcement on all mail received by the internal Outlook server. Select By verifying that the sender domain matches one of the following domains, specify the desired domains within the provided field and select the Plus button to finalize the additions. Select Next to continue.
      12. We will need to remove Security restrictions that could be placed on the desired domain. Make sure to uncheck Reject email messages if they aren’t sent over TLS since this has been identified to not be supported from the partner organizations mail servers. Select Next to continue.
      13. To finalize the Inbound TLS bypass, verify that all the fields listed under the Review connector page are correct, if a misconfiguration is detected select the necessary Edit hyperlink under the section. Once reviewed select Create connector to finalize the Inbound bypass.
      14. When created select Done to return to the main page and finalize the bi-directional TLS Bypass process.

      Error Handling Based on User Feedback

      The following list includes screen captures of Errors that could impact Internal or External Users mail flow behavior either due to process break down or configuration constraints as well as possible ways to hotfix the issue.

      1. NDR(s) – While there are a multitude of codes that can associated with a TLS failure, the most common occurrences from Internal Users failing TLS comes from internal mail flowing towards an external server that does not support TLS, an External User failing TLS will not show up within the tenant since the mail has been rejected however, they will receive a NDR that should then be supplied to the intended recipient.
        Exchange Message Trace can be utilized to detect Internal Users who have had mail delivery failures, External Users will most likely inform their recipient with a generated NDR or a message detailing that they received a bounce back message that informed them that their mail had been blocked.
        Depending on the necessity of having an open line of communication with that partner will impact whether you deploy the TLS Bypass or not.
        Management will need to make the final decision on whether or not they want to accept the risk of having unencrypted mail being sent over the internet.
      2. How to alleviate this issue:
        1. Follow the steps listed in the Configuring a TLS Bypass section above to alleviate the error impacting the users.
      3. Phantom Message Trace or Quarantine Search – If you ever receive messages from an Internal User that has not received a message and both the Exchange Message trace and Quarantine Queue are showing no mail ever being received or held from the designated sender or domain, this is likely the cause of a server-to-server communication failure which is related to TLS enforcement being enabled.
        1. Follow the steps listed in the Configuring a TLS Bypass section above to alleviate the error impacting the users.

      Need Assistance?

      Reach out to your Customer Success Manager to discuss how a Sittadel cybersecurity analyst can assist in managing these tasks for you. New to our services? Inquire about arranging a consultation to explore optimizing your Azure environment for painless management.