Microsoft Purview Sensitivity Labels vs. Exchange Online Mail Flow Rules: When Should You Encrypt Email?

A Complete Technical Guide to Email Encryption, Microsoft Purview Message Encryption, DLP, and Exchange Online Transport Rules

Introduction

One of the most common questions I encounter when designing and implementing Microsoft Purview Information Protection solutions is:

“If I have already configured sensitivity labels, why would I need Exchange Online mail flow rules to encrypt emails?”

This question highlights an important distinction in Microsoft 365 security architecture.

Microsoft Purview sensitivity labels and Exchange Online mail flow rules can both apply encryption to email messages, but they serve different purposes.

Sensitivity labels classify information and can apply persistent protection based on its sensitivity. Exchange Online mail flow rules provide centralized, condition-based enforcement as messages pass through the transport pipeline.

Microsoft Purview Data Loss Prevention (DLP) adds another layer by detecting sensitive information and controlling how it can be shared.

Understanding how these technologies work together is essential for designing a consistent, scalable, and secure Microsoft 365 information protection architecture.

In this article, I will explain how these technologies work, when to use each one, how they interact, and how to implement and validate them using practical Microsoft 365 examples.

1. Understanding the Three Layers of Email Protection

Microsoft 365 provides several complementary mechanisms for protecting sensitive email communications.

1.1 Microsoft Purview Sensitivity Labels

Sensitivity labels classify information and can apply protection settings, including encryption and usage restrictions.

Consider the following classification model for an organization using the Microsoft 365 domain muggh.com.

A sensitivity label’s name does not determine whether encryption is applied.

Creating a label named Confidential does not automatically encrypt the content.

Encryption must be explicitly configured in the label’s protection settings.

For example, a user can apply the Confidential label to an email without encrypting it if that label is configured for classification only.

1.2 Microsoft Purview Data Loss Prevention

DLP policies inspect supported content and activities to identify potential data exposure.

Depending on the workload, conditions, licensing, and configuration, DLP can:

• Detect sensitive information types.
• Generate security alerts.
• Display policy tips to users.
• Block or restrict sharing.
• Allow justified overrides where configured.
• Produce audit events for investigation.

Example: An employee sends an email from user1@muggh.com containing sensitive financial information to an external recipient.

A Microsoft Purview DLP policy detects the sensitive content and blocks the message based on the organization’s security policy.

1.3 Exchange Online Mail Flow Rules

Exchange Online mail flow rules, also called transport rules, evaluate email messages as they pass through Exchange Online.

They can apply encryption based on supported conditions such as:

• Sender location.
• Recipient domain.
• Message properties.
• Sensitive information detected in the message.

Unlike manually applied sensitivity labels, mail flow rules do not require users to select encryption themselves.

Architectural principle: Sensitivity labels classify and protect information, DLP controls sensitive data exposure, and mail flow rules enforce transport-level requirements.

2. How Sensitivity Label Encryption Works

Consider an organization using muggh.com with a sensitivity label named Highly Confidential.

The security administrator configures the label to apply encryption with administrator-defined permissions.

When an employee applies this label to an email using a supported Outlook client:

1. The email receives the sensitivity label.
2. The configured encryption settings are applied.
3. Authorized recipients can decrypt the message.
4. Usage rights determine what recipients can do with the protected content.

Depending on the configuration, the organization can restrict forwarding, copying, printing, or other supported actions.

Microsoft Purview uses Azure Rights Management technology to enforce this protection.

2.1 Administrator-defined permissions

The administrator determines which users or groups can access protected content and what usage rights they receive.

For example:

• Users within muggh.com can open the protected email.
• Unauthorized external recipients cannot decrypt it.
• Forwarding and printing can be restricted through the configured usage rights.

This approach is appropriate for highly restricted information where access must be controlled centrally.

2.2 User-defined permissions

Microsoft Purview also supports user-defined permissions for supported email protection scenarios.

Users can apply protection options such as:

• Encrypt-Only.
• Do Not Forward.

These options have different effects.

These restrictions are enforced through rights management, subject to client capabilities. They cannot prevent every possible form of content reproduction.

2.3 When should encryption be configured directly in the label?

Use sensitivity label encryption when protection should consistently follow the classification of the information.

Examples include:

• Confidential board communications.
• Restricted financial reports.
• Sensitive legal documents.
• Highly confidential project information.
• Intellectual property requiring persistent protection.

Architecture recommendation: When a particular classification always requires encryption, configuring encryption directly in the sensitivity label is generally preferable to creating a separate transport rule for the same requirement.

3. How Exchange Online Mail Flow Encryption Works

Now consider a different requirement.

An organization wants every outbound email sent to a particular external business partner to be encrypted, regardless of whether the sender remembers to select an encryption option.

This is a strong use case for an Exchange Online mail flow rule.

3.1 Business scenario

Organization: MUGGH
Microsoft 365 domain: muggh.com
Sender: user1@muggh.com
External partner: partner@example.com

Requirement: Encrypt outbound emails sent to the approved external partner.

The administrator creates a transport rule with the following configuration:

When an email matches the rule, Exchange Online applies the configured encryption protection.

The employee does not need to manually select Encrypt in Outlook.

3.2 How the process works

Step 1: The employee sends an email from user1@muggh.com.

Step 2: Exchange Online processes the message.

Step 3: The mail flow rule evaluates the configured conditions.

Step 4: If the message matches, Exchange Online applies encryption.

Step 5: The external recipient accesses the encrypted message using a supported authentication and decryption experience.

3.3 Important limitation

Exchange Online transport encryption rules are designed to apply protection to outgoing messages.

They should not be treated as a mechanism for retroactively encrypting arbitrary inbound messages from external senders.

For hybrid Exchange environments, message routing and where transport rules execute must also be considered.

4. Sensitivity Labels vs. Mail Flow Rules: Key Differences

Sensitivity labels provide a broader information protection model.

Mail flow rules are specifically designed to process email messages during transport.

The two approaches are complementary rather than interchangeable.

5. Five Real-World Email Protection Use Cases

Use Case 1: Confidential Email with Mandatory Encryption

Business requirement: All emails classified as Highly Confidential must be encrypted.

Recommended solution: Sensitivity label with encryption enabled.

For example, an employee sends a confidential management report from user1@muggh.com.

The employee selects the Highly Confidential label.

The label applies the configured encryption and usage restrictions.

A separate mail flow rule is not necessary merely to reproduce the same protection.

Use Case 2: Encrypt All Emails Sent to an External Partner

Business requirement: Every email sent to a designated external partner must be encrypted.

Recommended solution: Exchange Online mail flow rule.

The requirement depends on the recipient rather than the information classification.

A transport rule can enforce the condition centrally.

Use Case 3: Employees Forget to Apply Sensitivity Labels

Business requirement: Sensitive information must be identified and protected even when users forget to classify it.

Recommended solution: Microsoft Purview auto-labeling and/or DLP.

A service-side auto-labeling policy can inspect supported email content and apply a sensitivity label when its conditions match.

If the applied label includes encryption, the message can be protected automatically.

For example, an auto-labeling policy could detect specific financial information and apply an encrypted Confidential label.

Important: Service-side auto-labeling policies should be validated in simulation before enforcement. Client-side and service-side auto-labeling have different capabilities and processing behavior.

Use Case 4: Prevent Sensitive Information from Leaving the Organization

Business requirement: Employees must not send certain internal-only information to unauthorized external recipients.

Recommended solution: Microsoft Purview DLP.

Encryption alone is not always the correct control.

An encrypted email can still be delivered to an unauthorized recipient if the protection permissions allow that recipient to decrypt it.

For prohibited disclosures, blocking the email may be more appropriate than encrypting it.

Use Case 5: Confidential Attachments in External Email

Business requirement: An employee sends an email containing a Confidential-labeled Excel workbook to an external recipient.

The architect must distinguish between:

• The label applied to the email.
• The label applied to the attachment.
• Encryption applied to the email.
• Encryption applied directly to the document.

These are related but not identical protection states.

A document protected by its own sensitivity label can retain protection independently of the email.

The final behavior must be tested with representative file formats, recipient applications, and external sharing scenarios.

6. What Happens When Both Technologies Apply Encryption?

This is where architecture becomes particularly important.

Suppose an Exchange Online transport rule applies Encrypt-Only, while a Microsoft Purview service-side auto-labeling policy also matches the message.

Microsoft documents the following interaction:

These documented interactions apply to the relevant service-side auto-labeling scenario.

They should not be generalized to every possible sequence involving manually applied labels, client-side labeling, and transport rules.

Architecture considerations

Avoid configuring overlapping encryption mechanisms without understanding their interaction.

Otherwise, organizations may encounter:

• Unexpected recipient access restrictions.
• Conflicting usage rights.
• Inconsistent user experiences.
• Troubleshooting complexity.
• Additional operational overhead.

A well-designed architecture defines which control is authoritative for each protection requirement.

7. Email Attachment Encryption: What Actually Happens?

One of the most important technical distinctions is that encryption inheritance and sensitivity label inheritance are not the same thing.

Consider an employee sending an email labeled Confidential with an attached Excel workbook.

If the label applies encryption to the email, supported unencrypted Office attachments can inherit the message’s encryption protection.

However, the attachment does not automatically receive the email’s sensitivity label.

Practical example

Sender: user1@muggh.com
Email sensitivity label: Confidential
Attachment: Financial_Report.xlsx

Assume the Confidential label has encryption enabled.

When the protected email is sent:

1. The email receives the configured encryption protection.
2. The supported Office attachment can inherit the email’s encryption settings.
3. The attachment does not automatically inherit the email’s sensitivity label.
4. An attachment that is already encrypted retains its existing encryption.

Why architects should care

During implementation, test what happens when the recipient:

• Opens the attachment.
• Downloads it.
• Saves it locally.
• Forwards it, where permitted.
• Attempts to share it with another user.

The results can depend on the file type, encryption configuration, client support, and recipient permissions.

Key takeaway: An email’s sensitivity label and an attachment’s protection state must be assessed separately.

8. Encryption Timing: Classic Outlook vs. New Outlook

Not all Outlook clients apply sensitivity label encryption at the same stage.

Microsoft documents different processing behavior across supported clients.

Why does this matter?

Suppose user1@muggh.com applies an encrypted sensitivity label while composing an email.

In classic Outlook for Windows, the protection can be applied immediately.

In other supported Outlook clients, Exchange Online may apply the protection after the user sends the message.

This distinction can affect troubleshooting, the user experience, and how protected messages appear during composition or in Sent Items.

Operational recommendation: Validate encryption behavior across the Outlook clients used by your organization instead of assuming identical processing across all platforms.

9. What Happens When Encryption Is Added to an Existing Sensitivity Label?

Consider an organization that initially deploys a Confidential label without encryption.

Six months later, the security team decides to enable encryption on the existing label.

Does this automatically encrypt every previously labeled document and email?

Not necessarily.

Microsoft documents different behavior depending on the workload and the existing content.

For example:

• Newly labeled content receives the updated encryption configuration.
• Some previously labeled documents and emails retain their original encryption state until the label is removed and reapplied.
• Supported SharePoint and OneDrive files can have additional encryption behavior when accessed, depending on enabled functionality and prerequisites.

Enterprise migration scenario

An organization has 50,000 documents labeled Confidential.

The administrator updates the Confidential label to enable encryption.

It would be incorrect to assume that all 50,000 documents immediately become encrypted.

The security team must evaluate the affected workloads and determine how existing content will receive the updated protection.

Recommended approach

Before enabling encryption on a widely used production label:

1. Inventory the label’s existing usage.
2. Identify affected workloads and file types.
3. Review internal and external access requirements.
4. Assess historical content behavior.
5. Test the change with representative files.
6. Validate recipient access and operational impact.
7. Plan a controlled rollout.

Architectural recommendation: Treat significant encryption changes to existing labels as information protection migrations, not merely administrative configuration updates.

10. Step-by-Step: Configure an Exchange Online Encryption Rule

Let’s implement a simple scenario.

Requirement: Encrypt outbound emails addressed to an approved external business partner.

Step 1: Verify prerequisites

Confirm that the tenant has the appropriate licensing and configuration for Microsoft Purview Message Encryption and Azure Rights Management.

Connect to Exchange Online PowerShell:

Install-Module ExchangeOnlineManagement -Scope CurrentUser
Connect-ExchangeOnline -UserPrincipalName abou@muggh.com

Review the IRM configuration:

Get-IRMConfiguration |
    Format-List AzureRMSLicensingEnabled,
                InternalLicensingEnabled,
                ExternalLicensingEnabled

These settings provide configuration information, but they do not independently prove that end-to-end encryption is functioning correctly.

Where appropriate, perform a functional validation using an authorized test sender and Test-IRMConfiguration.

Step 2: Open Exchange Admin Center

Navigate to:

Select:

Mail flow → Rules → Add a rule → Create a new rule

Step 3: Define the conditions

Rule name: Encrypt - External Partner

Configure:

• Sender is located inside the organization.
• Recipient matches the approved external partner.

Step 4: Configure encryption

Under Do the following, select:

Modify the message security → Apply Office 365 Message Encryption and rights protection

Choose the appropriate protection template, such as Encrypt.

The administrative interface may retain historical Office 365 Message Encryption terminology even though Microsoft Purview Message Encryption is the current service.

Step 5: Validate before production

Use approved test accounts and verify:

• Successful encryption.
• External recipient authentication and decryption.
• Forwarding behavior.
• Attachment protection.
• Exceptions.
• Interaction with existing DLP and transport policies.

Review the rule’s priority, mode, and potential conflicts before enabling production enforcement.

11. PowerShell: Audit Existing Encryption Rules

Before creating new transport rules, inspect the existing configuration.

Connect-ExchangeOnline -UserPrincipalName abou@muggh.com
Get-TransportRule |
    Select-Object Name, State, Mode,
                  Priority,
                  ApplyRightsProtectionTemplate,
                  ApplyOME |
    Format-Table -AutoSize

To focus on rules with configured encryption-related actions:

Get-TransportRule |
    Where-Object {
        $_.ApplyRightsProtectionTemplate -or
        $_.ApplyOME
    } |
    Format-List Name, State, Mode,
                Priority,
                ApplyRightsProtectionTemplate,
                ApplyOME

These commands are read-only.

To inspect a specific rule:

Get-TransportRule -Identity "Encrypt - External Partner" |
    Format-List *

A complete encryption assessment should also review:

• Existing sensitivity labels.
• Label publishing policies.
• Label encryption permissions.
• Service-side auto-labeling policies.
• Microsoft Purview DLP policies.
• Existing transport rules.
• External recipient requirements.

Important: The absence of encryption-related transport rules does not mean the organization has no email encryption controls. Encryption may already be enforced by sensitivity labels or other supported mechanisms.

12. Recommended Enterprise Email Protection Architecture

For an enterprise Microsoft Purview deployment, I recommend organizing the design into four complementary layers.

Layer 1 — Classification

Define sensitivity labels based on business requirements.

Examples:

• Public.
• Internal.
• Confidential.
• Highly Confidential.

Keep the classification taxonomy understandable and aligned with actual information handling requirements.

Layer 2 — Information Protection

Configure encryption directly in sensitivity labels when persistent, classification-based protection is required.

Define appropriate permissions and validate access for internal and external recipients.

Layer 3 — Data Loss Prevention

Use Microsoft Purview DLP to detect and prevent unauthorized exposure of sensitive information across supported workloads.

Choose alerting, user guidance, blocking, or other supported actions according to business risk.

Layer 4 — Email Transport Enforcement

Use Exchange Online mail flow rules for specific transport-level requirements not adequately covered by the sensitivity label architecture.

Examples include encryption for designated external partner domains or other supported message conditions.

Example target architecture

The objective is not to maximize the number of controls, but to ensure that each control has a clearly defined purpose.

13. Common Architecture and Deployment Mistakes

Mistake 1: Assuming a sensitivity label automatically encrypts content

A label named Confidential does not automatically encrypt content.

Encryption must be configured explicitly.

Mistake 2: Encrypting everything

Encryption should be driven by business requirements.

Unnecessary restrictions can disrupt collaboration and create operational complexity.

Mistake 3: Using encryption instead of DLP

Encryption protects access to content.

It does not necessarily prevent sensitive information from reaching an unauthorized recipient who has been granted decryption rights.

Mistake 4: Creating duplicate encryption rules

Overlapping sensitivity labels, DLP policies, and transport rules can complicate enforcement and troubleshooting.

Mistake 5: Ignoring external recipient testing

External users may experience different authentication and access flows depending on the protection configuration and their email client.

Mistake 6: Assuming email and attachment encryption are identical

Attachment protection depends on the file format, existing encryption, and applicable protection settings.

Mistake 7: Modifying encryption settings without evaluating historical content

Enabling encryption on an existing label does not necessarily encrypt every previously labeled item.

Mistake 8: Ignoring Outlook client differences

Encryption processing can vary between classic Outlook and other supported Outlook clients.

Testing must reflect the organization’s actual endpoint environment.

14. Enterprise Deployment Checklist

Before deploying email encryption controls into production:

• Confirm business requirements and classification taxonomy.
• Review existing sensitivity labels and encryption settings.
• Verify Microsoft Purview Message Encryption prerequisites and licensing.
• Inventory existing mail flow rules and DLP policies.
• Define the authoritative encryption control for each scenario.
• Validate supported Outlook clients.
• Test internal and external recipients.
• Validate attachment protection and inheritance behavior.
• Assess the impact on previously labeled content.
• Review exceptions and operational ownership.
• Pilot with representative users.
• Document rollback procedures.
• Obtain business and security acceptance before production rollout.

Conclusion

Microsoft Purview sensitivity labels and Exchange Online mail flow rules are complementary security controls, but they should not be deployed interchangeably.

Use sensitivity label encryption when protection should follow the classification of the information.

Use Exchange Online mail flow encryption when protection must be enforced based on supported email transport conditions.

Use Microsoft Purview DLP when the requirement is to detect, restrict, or prevent unauthorized data exposure.

Architects must also understand encryption inheritance, Outlook client behavior, existing labeled content, and the interaction between auto-labeling and transport rules.

The strongest information protection architecture is not the one with the greatest number of overlapping security policies.

It is the one where every control has a clearly defined purpose, predictable enforcement behavior, and measurable business value.

For Microsoft 365 security architects, the goal is to build a coherent information protection strategy that balances confidentiality, usability, governance, and operational simplicity.

Official Microsoft Documentation

1. Apply encryption using sensitivity labels
2. Define mail flow rules to encrypt email messages
3. Automatically apply a sensitivity label to Microsoft 365 data
4. Manage sensitivity labels in Office apps
5. Microsoft Purview documentation