Ensuring Email Delivery Security with Exchange 2013

To force Exchange 2013 to guarantee the secure delivery of a message can be done a few different ways. In this version of the product and in previous versions it was possible to create a send connector for a given domain and enable Mutual TLS on the connector. Then all messages to the domain(s) that this connector serviced would need to travel over a TLS connection where the certificate at both ends was completely valid (i.e. valid regards the date, had the correct subject or SAN for the domain, was issued by a trusted certificate authority etc.). In previous versions (2007 to 2010 again) it was possible to enable Domain Secure and add another level of checks to the Mutual TLS session. Domain Secure does not work in Exchange 2013.

And great though these methods of transport security are, they are limited in that they are difficult to set up (require good knowledge of certificates) and needs to be properly configured at both ends of the connection. They are also limited in that they will only secure email to the selected domains. If you need to send a “top secret” email to someone, you don’t really want to have to configure a connector at both ends and force all email for that domain down the same path.

So, in Exchange 2013 you can create a transport rule to force the connection to use TLS, and if TLS fails then have the message queue on the sender until it retries and eventually expires. If TLS is never available, the message never goes out of Exchange – or so it would be if all you read was the description in the documentation!

The RouteMessageOutboundRequireTLS transport rule action (or the Secure the message with > TLS encryption option in the ECP transport rules wizard) allows you to craft a rule for any condition (for example the subject or body contains any of these words: top secret) which will require the email to use an encrypted session for the delivery outside of Exchange Server. Note that for this to work the TLS session does not need to be protected by a given certificate or valid etc., it just needs the receiving SMTP Server to offer STARTTLS and for the encryption to work.

And it needs a source server for sending the message in every Active Directory site within the organization. Currently (as of CU2 for Exchange 2013) if you send a message from a site that does not contain a send connector that can handle the message to the internet then Exchange will pass it to a site that can, but the source transport server will now not enforce the TLS requirement and will send the message unprotected if STARTTLS is not offered.

So if you want to guarantee the use of TLS for certain types of message use the RouteMessageOutboundRequireTLS transport rule condition and ensure that you do not need to do cross site delivery of messages to reach a send connector source server to delivery the message to the internet.



, , , , , , ,




4 responses to “Ensuring Email Delivery Security with Exchange 2013”

  1. Ivan avatar

    Hi Brian,

    You have stated that Domain Security doesnt exist anymore on Exchange 2013. I was able to set it up between two organizations. However, I’m not getting green ticky in Outlook, but when I examine headers it clearly states that authdomain is ie. contoso.com. In addition, there is notification in form of message classification stating “Partner E-Mail’.

    Maybe it is not native ‘Domain Security’ with green ticky but it works.

    Do you happen to know if the functionality will be returned in some near future?

    Last but not least – you are doing great blog, keep up great work.


    1. Brian Reid avatar

      Domain Security requires no devices in the middle, that is nothing between the sending hub transport server and the receiving hub transport server. In Exchange 2013 receiving emails from external is not done by Hub Transport anymore, it is done by Frontend Transport which proxies the connection to the Mailbox Server (which is the replacement in this case for the Hub Transport server). Therefore there is now a device in the middle and so domain secure end to end is not happening.

  2. Ivan avatar

    Hi Brian,

    thanks for your reply and explanation.

    I’m aware that no devices must exist in the “middle”. However, when I’m setting transport security on Exchange 2013, I’m creating “HubTransport” instead of “FrontEndTransport” receive connector. In addition, send connector created for domain secure e-mail does not have “FrontEndTransportEnabled” set to true so all mails are flowing directly from Hub service (virtually same as Hub Transport) to remote end.

    Here is header sample where I was able set up Domain Secure on two Exchange 2013 organization:

    Return-Path: Administrator1@contoso.com
    X-MS-Exchange-Organization-AuthSource: EX01.cpandl.com
    X-MS-Exchange-Organization-AuthAs: Partner
    X-MS-Exchange-Organization-AuthMechanism: 02
    X-MS-Exchange-Organization-AuthDomain: contoso.com

    The only thing that I’m not getting is green ticky in Outlook, but info bar is showing message classification “Partner Mail”.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.