Requiring TLS encryption for email transmission for the Australian Government

This article provides guidance for Australian Government organizations on the use of Transport Layer Security (TLS) to help protect security classified information. Its purpose is to help government organizations to understand their encryption requirements and how Microsoft 365 can be configured to meet them. Guidance in this article has been written to best align with requirements outlined in the Protective Security Policy Framework (PSPF) and the Information Security Manual (ISM).

Transport Layer Security (TLS) is a type of encryption that, within this context, is used to protect email during transmission. TLS is applied at the mail server and applies to all email sent from the server, rather than at the user or client level. For more information on TLS in Microsoft 365, see how Exchange Online uses TLS to secure email connections..

TLS is opportunistic, which means that Exchange Online always tries to encrypt connections with the most secure version of TLS first, then works its way down the list of TLS ciphers until it finds one that both sender and recipient agree on. Opportunistic TLS ensures that messages are encrypted to highest level possible for the email transmission.

By default, Exchange Online has TLS opportunistic enabled, which meets the following Information Security Manual (ISM) requirement:

Requirement	Detail
ISM-0572 (March 2025)	Opportunistic TLS encryption is enabled on email servers that make incoming or outgoing email connections over public network infrastructure.

Opportunistic TLS configuration is also discussed in ASD's Blueprint for Secure Cloud.

Risk of unencrypted email

A disadvantage of the opportunistic nature of TLS is that it isn't mandatory. If a receiving email server doesn't have TLS enabled, then email can be sent without TLS encryption, resulting in higher likelihood of the plain-text content being intercepted and interpreted. This isn't a product flaw, but rather a symptom of the evolution of email security. Mandating TLS encryption for all email transmission is likely to result in lost or blocked email for the small percentage of email services that aren't yet TLS capable.

In order to help assess the risk of optional TLS encryption, email administrators should regularly review the Exchange online outbound message report, which will provide a summary of the percentage of emails being sent with and without TLS encryption. For more information, see messages reports in Exchange Online..

Keeping email encryption optional for sensitive or security classified information increases the risk of information loss. We should consider this risk along with transmission requirements from section 9.3 of the Protective Security Policy Framework (PSPF):

Classification	Requirements
PROTECTED	Use PROTECTED (or higher) network, otherwise encryption required.
OFFICIAL: Sensitive	Use OFFICIAL: Sensitive (or higher) network. Encrypt if transferred over public network infrastructure or through unsecured spaces.
OFFICIAL	Encryption recommended, particularly for information communicated over public network infrastructure.

Government organizations should consider methods for mitigating risks associated with opportunistic TLS. Strategies can include:

• The use of a forced TLS approach for all outgoing mail. This ensures TLS encryption regardless of applied sensitivity label or item content, but at potential cost of nondelivery for some items. For more information on this approach, see How to set up forced TLS for Exchange Online in Office 365.
• The use of a set of partner connectors that require TLS for communication between a predefined list of organizations. This method secures communications between fixed organizations but won't provide mandatory TLS encryption when information is sent to recipients outside of the list of organizations. For more information on this approach, see Set up connectors for secure mail flow with a partner organization in Exchange Online.
• The use of an Exchange Online transport configurations requiring TLS for security classified email. This approach can complement a set of partner connectors to ensure that all security classified items are transmitted in alignment with PSPF encryption requirements.

For many Government organizations, particularly the service based agencies, the bulk of their information falls into the OFFICIAL category and utilizing a forced TLS approach for this volume of email might have significant impacts on business with individuals and organizations who don't have TLS. A risk based approach, tempered to the business need is recommended, and for many organizations this is likely to impede use of the forced TLS approach. A more palatable approach is likely to include use of both partner connectors and transport-based configurations.

ASD's blueprint for secure cloud includes information on transport rule configuration to require TLS for OFFICIAL: Sensitive or PROTECTED email. This configuration is explored in some further details in the following section.

Mandating TLS for security classified email

An Exchange online mail flow rule can be created to require TLS encryption for emails with certain sensitivity labels applied. To achieve this, we'll first need to identify items with the relevant labels applied.

When sensitivity labels are applied to an email, there's a set of metadata that is placed in the email's headers. The header containing label information is named msip_labels and includes a label Globally Unique Identifiers (GUIDs), which corresponds with the label applied to the item.

In order to obtain all label GUIDs for an environment, security, and compliance PowerShell can be used. To view an environment's labels and associated GUIDs, use:

Get-label | select displayname,guid

GUIDs of interest are those for any OFFICIAL: Sensitive and PROTECTED labels, including sublabels.

Note

Label GUIDs are specific to a single Microsoft 365 tenant only. Two tenants with the same label naming won't share the same GUID.

Once obtained, label names and GUIDs should be recorded so you can use them for Exchange mail flow rule configuration.

For generic guidance on the creation of mail flow rules, see Manage mail flow rules in Exchange Online.

Administrators need to use the Exchange Online Admin Center to create mail flow rules that look for the msip_labels header. A single mail flow rule can be used to check for multiple label GUIDs. Ensure you include Enabled=True after the label GUID when creating the rule. The following example checks for the six variations of PROTECTED labels (including Information Management Markers and Caveats) within an environment.

Mail flow rule action should be set to modify the message security, Require TLS encryption.

The following example checks for label GUIDs of six variations of a PROTECTED label and requires TLS encryption for transmission of any email with the labels applied.

Example mail flow rule for requiring TLS

This mail flow rule is intended to prevent security classified or sensitive email from being transmitted over the internet without TLS encryption.

Rule Name	Apply this rule if	Do the following
Require TLS for PROTECTED email	Apply this rule if the recipient is internal/external: - Outside the organization AND The message headers… Include any of these words: Header: msip_labels Words: - PROTECTED GUID - PROTECTED Personal Privacy GUID - PROTECTED Legal Privilege GUID - PROTECTED Legislative Secrecy GUID - PROTECTED CABINET GUID - PROTECTED NATIONAL CABINET GUID	- Modify the message security - Require TLS encryption

Note

Before implementing such rules, also consider your strategy for monitoring rule impact and actioning items that are delayed or blocked due to the receiving organization not supporting TLS.