Currently there is not an option to Force TLS delivery from the FOPE service to an org as the FOPE customer.

The servers do attempt opportunistic TLS however if STARTTLS is presented to the FOPE servers delivering email to the FOPE customer MTA.

Unfortunately this does not appear in the MTRT logs or the logging that support can pull to verify whether or not TLS actually occurred with the email delivery.

 In order to verify that TLS delivery is or is not occurring we could use a couple of methods:

  • The simplest method would be to look at the headers in a recently received email that went through the FOPE service and look for the Received: header that shows the connection between the FOPE server and the FOPE customer organizations MTA.
    • Examples where TLS is occurring may look like the following depending on the receiving MTA as this is the one stamping this in the header:  
      •  Received: from ([FOPE IP ADDRESS])
        by fopecustomer.mta.org with ESMTP with TLS id #########
      • Received: from fope.servername.com (fope.servername.com [FOPE IP ADDRESS])
        by fopecustomer.mtaname.org (MTAtype) with ESMTPS id #####
        for somerecipient@fopecustomer.org; Fri, DD Mon YYYY HH:MM:SS +0500
      • Received: from fope.servername.com ([FOPE IP ADDRESS]) by fopecustomer.mtaname.org over TLS secured channel with Microsoft SMTPSVC(7.5.7600.16601); Day, D Mon YYYY HH:MM:SS -0700
  • Another method would be to gather a network trace on the FOPE customer organization MTA and look at an email receive stream and see if the TLS connection is initated and data is sent through the TLS tunnel before completing the connection. 

One option for FOPE customer organizations wishing to ensure that email delivery from FOPE to the FOPE customer is TLS is to investigate their receiving MTA product to see if it is possible to enforce TLS on the inbound connections in that product.  If so that may be a viable option for enforcing TLS on this specific connection.