Mail flow rules in Exchange Online: the hidden champions of compliance

The challenge: compliance requirements that live in transit

Some compliance requirements are about data at rest: how long a document is kept, who can open it, where it is stored. Many others are about data in motion, and email is still the busiest channel for data leaving an organisation. Legal departments want every external message to carry the company's registered details. Risk managers want mail to a specific bank to travel only over verified TLS. Auditors want to see that two departments with a conflict of interest cannot email each other. Information security wants confidential content to stay inside, and suspicious attachments to stay outside.

Exchange Online mail flow rules, also called transport rules, are the tool that enforces these requirements at the moment a message passes through the service. They act on every message, regardless of the client used to send it, before it reaches the recipient. Users cannot switch them off, forget them or work around them by sending from their phone.

And yet, in most tenants I review, mail flow rules are either barely used or used chaotically. Typical findings:

• Dozens of rules created over many years by different admins, no naming convention, no comments, nobody who can explain half of them.
• Rules that bypass spam filtering (SCL -1) for "trusted" partners, effectively creating an allow-list nobody reviews.
• Disclaimers appended three times to long reply chains, or breaking signed messages.
• Rules that still reference the "message contains sensitive information" condition, which Microsoft removed from mail flow rules in late 2023 in favour of Microsoft Purview DLP, and which therefore no longer do what their name says.
• No backup of the rule set, so a careless change in the admin center cannot be rolled back.

This article treats mail flow rules as what they are: a precise, real-time policy engine. It shows advanced, production-tested patterns for disclaimers, data leakage controls, encryption, routing and ethical walls, and it is explicit about where Purview DLP is the better tool.

A realistic case: a fiduciary firm with six requirements

Woodgrove Treuhand AG is a Swiss fiduciary and audit firm with around 300 employees, offering accounting, tax advisory and statutory audit services. Its Microsoft 365 E3 tenant has grown organically, with 37 mail flow rules created over eight years. During a compliance review triggered by a new professional standards audit, six requirements were formulated for email:

In addition, the review of the existing 37 rules found two SCL -1 bypass rules for former suppliers, four rules with the retired sensitive information condition, three overlapping disclaimer rules, and one rule that BCC'd all messages of the managing partner to an assistant, created years ago and forgotten.

Every one of the six requirements can be implemented with mail flow rules, some of them better than with any other tool. R2 is the interesting one, because it sits right on the boundary between transport rules and Purview DLP. Let us look at the engine first, then build the rules.

Mail flow rules in depth

How the rules engine works

A mail flow rule consists of conditions (when does the rule apply), exceptions (when does it not), actions (what happens) and properties (priority, mode, activation window, how to match the sender). Rules are evaluated by the transport service for messages in transit: inbound from the internet, outbound to the internet and internal messages between mailboxes. They do not act on messages already stored in mailboxes.

Important properties that most admins never touch:

And the limits that you will eventually hit in larger tenants:

PowerShell: current usage against the limits

Connect-ExchangeOnline
Get-EtrLimits

Get-EtrLimits returns the number of rules, the regex character usage and the IDs of the largest rules, which is the fastest way to find the rule that blocks you from adding the next one.

Where mail flow rules end and Purview DLP begins

Until 2023, mail flow rules could detect sensitive information types (credit card numbers, IBANs, national ID numbers) with the condition "The message contains sensitive information". Microsoft removed that condition and the related policy-tip predicates from mail flow rules in November 2023. Detection of sensitive information types in email now belongs to Microsoft Purview DLP, which covers Exchange, SharePoint, OneDrive, Teams and endpoints with one policy, supports confidence levels, exact data match and trainable classifiers, and shows policy tips in Outlook.

That does not make transport rules irrelevant for data protection. It clarifies the division of labour:

PowerShell: find rules with retired DLP conditions

Get-TransportRule | Where-Object {
    $_.MessageContainsDataClassifications -or
    $_.ExceptIfMessageContainsDataClassifications -or
    $_.HasSenderOverride -or $_.ExceptIfHasSenderOverride
} | Format-Table Name, State, Mode, Priority

Rule hygiene: naming, audit mode, backup

Before building new rules, Woodgrove agreed on three conventions that make the rule set maintainable:

1. Naming: <Area> | <Purpose> | <Scope>, for example DLP | Block Strictly Confidential | External. Areas are DISCLAIMER, DLP, ROUTING, ENCRYPT, WALL, SECURITY. Sorted by name, the list reads like documentation.
2. Comments: owner, requirement ID, date and ticket number in every rule.
3. Lifecycle: every new rule starts in Audit mode for at least a week; changes are made in PowerShell from a versioned script, and the full rule collection is exported before every change.

PowerShell: back up and restore the complete rule collection

# Export (the cmdlet returns an object with the XML as byte array)
$export = Export-TransportRuleCollection
$path = "C:\Backup\TransportRules-$(Get-Date -Format yyyyMMdd-HHmm).xml"
[System.IO.File]::WriteAllBytes($path, $export.FileData)

# Restore (replaces the existing rule collection)
# Import-TransportRuleCollection -FileData ([System.IO.File]::ReadAllBytes($path))

Disclaimers done properly (R1)

A server-side disclaimer is applied to every matching message regardless of client, which makes it the reliable choice for legal text. The common mistakes are applying it to internal mail, stacking it on every reply in a thread, and breaking digitally signed or encrypted messages. The rule below addresses all three.

PowerShell: legal disclaimer for external messages

$html = @"
<div style="font-family:Aptos,Calibri,Arial,sans-serif;font-size:9pt;color:#555555;border-top:1px solid #cccccc;margin-top:12px;padding-top:6px">
<p style="margin:0"><b>%%DisplayName%%</b>, %%Title%%, %%Department%%<br>
Phone %%PhoneNumber%% | %%Email%%</p>
<p style="margin:6px 0 0 0">Woodgrove Treuhand AG | Bahnhofstrasse 1 | 8001 Zurich | Switzerland<br>
Commercial register: CHE-123.456.789</p>
<p style="margin:6px 0 0 0;font-size:8pt">This message may contain confidential information.
If you are not the intended recipient, please notify the sender and delete it.</p>
</div>
"@

New-TransportRule -Name "DISCLAIMER | Legal footer | External" `
    -FromScope InOrganization `
    -SentToScope NotInOrganization `
    -ApplyHtmlDisclaimerLocation Append `
    -ApplyHtmlDisclaimerText $html `
    -ApplyHtmlDisclaimerFallbackAction Wrap `
    -ExceptIfSubjectOrBodyContainsWords "Commercial register: CHE-123.456.789" `
    -ExceptIfHeaderContainsMessageHeader "X-WGT-NoDisclaimer" `
    -ExceptIfHeaderContainsWords "true" `
    -Mode Audit `
    -Priority 50 `
    -Comments "R1 | Owner: Legal | Ticket CHG-2214"

How the pieces work together:

• Tokens such as %%DisplayName%%, %%Title%%, %%Department%%, %%PhoneNumber%% and %%Email%% are filled from the sender's directory attributes. Empty attributes produce empty strings, so the directory data quality decides how the footer looks.
• No stacking: once the footer has been added, its commercial register line is part of the message body. When a recipient replies and the thread comes back and goes out again, the exception finds that line in the quoted text and prevents a second footer. Use a phrase from the visible footer that does not occur in normal correspondence; hidden markers such as HTML comments are not reliable, because the rule evaluates the text content of the body. The trade-off: a new message that quotes an earlier external thread does not receive a second footer either, which is usually acceptable because the footer is already in the quoted text.
• Opt-out for systems: applications that must send unmodified messages (for example to an e-invoicing gateway) set the header X-WGT-NoDisclaimer: true.
• Fallback: if the disclaimer cannot be inserted, for example because the message is S/MIME signed or encrypted, Wrap puts the original message as an attachment into a new message carrying the disclaimer. Ignore sends the message unchanged; Reject returns it to the sender. For a legal footer, Ignore is often the pragmatic choice, because wrapped messages confuse recipients and break signature verification. Decide consciously.

Data leakage controls with transport rules (R2, R3)

Blocking labelled messages from leaving the organisation

When a user applies a sensitivity label to an email in Outlook, the label's metadata is written into the message header msip_labels, which contains an entry such as MSIP_Label_<label GUID>_Enabled=true. A mail flow rule can test that header. First, get the GUID of the label from Security & Compliance PowerShell:

PowerShell (Security & Compliance): label GUIDs

Connect-IPPSSession
Get-Label | Format-Table DisplayName, Name, Guid -AutoSize

PowerShell: reject "Strictly Confidential" messages to external recipients

$labelGuid = "<guid-of-Strictly-Confidential>"

New-TransportRule -Name "DLP | Block Strictly Confidential | External" `
    -FromScope InOrganization `
    -SentToScope NotInOrganization `
    -HeaderContainsMessageHeader "msip_labels" `
    -HeaderContainsWords "MSIP_Label_$($labelGuid)_Enabled=true" `
    -RejectMessageReasonText "This message is classified Strictly Confidential and cannot be sent outside Woodgrove. Contact compliance@woodgrove.example if you need an exception." `
    -RejectMessageEnhancedStatusCode "5.7.1" `
    -SetAuditSeverity High `
    -StopRuleProcessing $true `
    -Priority 1 `
    -Mode Audit `
    -Comments "R2 | Owner: Compliance | Ticket CHG-2215"

Three things to be aware of:

• The rule sees the label of the message. Labels on attached Office files are stored in the files themselves, and modern Office versions store that metadata in a format transport rules cannot reliably read. For labelled attachments, use a Purview DLP policy with the sensitivity label condition.
• Combine the rule with StopRuleProcessing and a high priority, so that no later rule (a disclaimer, a routing rule) acts on a message that is going to be rejected anyway.
• If the label itself applies encryption with permissions restricted to internal users, external recipients cannot open the content anyway. The rule then adds a clear rejection at send time, which is better for the user than an unreadable message at the recipient's end.

Password-protected and unscannable attachments

Encrypted archives and password-protected documents cannot be scanned by anti-malware or DLP. Outbound, they are a classic way to move data out unnoticed; inbound, they are a classic malware delivery method. Woodgrove's requirement R3 translates into two rules:

PowerShell: outbound approval and inbound quarantine

# Outbound: manager approval for password-protected attachments to external recipients
New-TransportRule -Name "DLP | Password-protected attachment | External approval" `
    -FromScope InOrganization `
    -SentToScope NotInOrganization `
    -AttachmentIsPasswordProtected $true `
    -ModerateMessageByManager $true `
    -SetAuditSeverity Medium `
    -Priority 5 `
    -Mode Audit `
    -Comments "R3 | Owner: InfoSec"

# Inbound: quarantine password-protected, unsupported or unprocessable attachments
New-TransportRule -Name "SECURITY | Unscannable attachments | Inbound quarantine" `
    -FromScope NotInOrganization `
    -SentToScope InOrganization `
    -AttachmentIsPasswordProtected $true `
    -Quarantine $true `
    -Priority 6 `
    -Mode Audit `
    -Comments "R3 | Owner: InfoSec"

New-TransportRule -Name "SECURITY | Unprocessable attachments | Inbound quarantine" `
    -FromScope NotInOrganization `
    -AttachmentProcessingLimitExceeded $true `
    -Quarantine $true `
    -Priority 7 `
    -Mode Audit

Conditions in the same rule are combined with AND; separate rules are needed when you want OR between different attachment conditions, which is why the inbound side uses two rules.

Custom identifiers and freemail recipients

Woodgrove's client numbers follow a fixed pattern (WGT- followed by six digits). Sending client references to private freemail addresses is a frequent precursor of data leaving with a departing employee. A simple regex rule routes such messages to compliance for approval:

PowerShell: client references to freemail domains need approval

$freemail = "gmail.com","googlemail.com","outlook.com","hotmail.com","live.com","icloud.com","gmx.ch","gmx.net","bluewin.ch","yahoo.com"
$pattern  = "\bWGT-\d{6}\b"

New-TransportRule -Name "DLP | Client references to freemail | Approval" `
    -FromScope InOrganization `
    -RecipientDomainIs $freemail `
    -SubjectOrBodyMatchesPatterns $pattern `
    -ModerateMessageByUser "approvals@woodgrove.example" `
    -SetAuditSeverity Medium `
    -Priority 8 `
    -Mode Audit

New-TransportRule -Name "DLP | Client references in attachments to freemail | Approval" `
    -FromScope InOrganization `
    -RecipientDomainIs $freemail `
    -AttachmentMatchesPatterns $pattern `
    -ModerateMessageByUser "approvals@woodgrove.example" `
    -Priority 9 `
    -Mode Audit

Regex patterns count toward the 20 KB limit across all rules, so keep them short and reuse them. If the identifier needs validation (check digits, keyword proximity), build a custom sensitive information type in Purview instead.

Automatic encryption (R4, second part)

Microsoft Purview Message Encryption is included in Microsoft 365 E3. A mail flow rule can apply it automatically, either based on content and recipients or based on a keyword users type into the subject:

PowerShell: encrypt messages marked [secure] to external recipients

# Prerequisite check: Azure RMS licensing is active
Get-IRMConfiguration | Format-List AzureRMSLicensingEnabled
Test-IRMConfiguration -Sender "it.admin@woodgrove.example" -Recipient "test@external.example"

New-TransportRule -Name "ENCRYPT | Subject keyword secure | External" `
    -FromScope InOrganization `
    -SentToScope NotInOrganization `
    -SubjectContainsWords "[secure]" `
    -ApplyRightsProtectionTemplate "Encrypt" `
    -Priority 10 `
    -Mode Audit `
    -Comments "R4 | Owner: InfoSec"

The "Encrypt" option encrypts the message and attachments without restricting forwarding; "Do Not Forward" additionally prevents forwarding, printing and copying. Recipients outside Microsoft 365 read the message through the encrypted message portal after authenticating with a one-time passcode or their own account. Disclaimers are applied before encryption if the disclaimer rule has a lower priority number, so the order of rules matters here too.

Enforced routing and TLS (R4, R6)

Mandatory TLS with certificate validation for specific domains

For "mail to the banks only over verified TLS", a partner outbound connector is the right tool. It applies to all messages for the listed domains; no rule is needed. If TLS with a valid certificate cannot be established, the message is not sent in clear text, it is retried and eventually returned with a non-delivery report.

PowerShell: forced TLS to partner domains

New-OutboundConnector -Name "TLS | Banks | Certificate validation" `
    -ConnectorType Partner `
    -RecipientDomains "bank-one.example","bank-two.example" `
    -UseMXRecord $true `
    -TlsSettings CertificateValidation `
    -Comment "R4 | Contractual TLS requirement"

# Optional: validate that the connector works
Validate-OutboundConnector -Identity "TLS | Banks | Certificate validation" -Recipients "postmaster@bank-one.example"

TlsSettings accepts EncryptionOnly, CertificateValidation (trusted certificate) and DomainValidation (trusted certificate whose name matches TlsDomain). Use DomainValidation when the partner tells you the exact certificate name of their mail gateway.

Conditional routing through an encryption gateway

Requirement R6 is conditional: only messages to certain public-sector clients go through the partner's encryption gateway. That is what transport-rule-scoped connectors are for. The connector is only used when a mail flow rule selects it.

PowerShell: transport-rule-scoped connector and routing rule

New-OutboundConnector -Name "ROUTE | Encryption gateway | Public sector" `
    -ConnectorType Partner `
    -IsTransportRuleScoped $true `
    -UseMXRecord $false `
    -SmartHosts "securegw.partner.example" `
    -TlsSettings DomainValidation -TlsDomain "securegw.partner.example" `
    -Comment "R6 | Used only via mail flow rule"

$publicSector = "canton-a.example","city-b.example","authority-c.example"

New-TransportRule -Name "ROUTING | Public sector via encryption gateway" `
    -FromScope InOrganization `
    -RecipientDomainIs $publicSector `
    -RouteMessageOutboundConnector "ROUTE | Encryption gateway | Public sector" `
    -SetHeaderName "X-WGT-Route" -SetHeaderValue "SecureGateway" `
    -Priority 20 `
    -Mode Audit `
    -Comments "R6 | Owner: IT Infrastructure"

The header is optional but useful: the gateway can use it for its own policy decisions, and message traces show at a glance which path a message took.

Ethical walls (R5)

Auditor independence rules require that the audit team of a client does not coordinate with the advisory team of the same client. For email, a single rule is enough. It blocks messages in both directions between members of two groups.

PowerShell: ethical wall between audit and advisory

# Both groups must be mail-enabled (distribution groups or mail-enabled security groups)
New-TransportRule -Name "WALL | Audit vs Advisory | Block" `
    -BetweenMemberOf1 "SG-Audit-Staff@woodgrove.example" `
    -BetweenMemberOf2 "SG-Advisory-Staff@woodgrove.example" `
    -ExceptIfFrom "managing.partner@woodgrove.example","compliance@woodgrove.example" `
    -RejectMessageReasonText "Email between Audit and Advisory is not permitted (independence policy). Contact Compliance." `
    -RejectMessageEnhancedStatusCode "5.7.1" `
    -StopRuleProcessing $true `
    -Priority 0 `
    -Mode Audit `
    -Comments "R5 | Owner: Compliance | Independence policy v3"

The ethical wall covers email only. If the same separation is required in Teams chats, channels and SharePoint sites, Microsoft Purview Information Barriers is the matching control for those workloads.

Testing and troubleshooting

Every rule in this article was created in Audit mode. In audit mode the actions are not executed, but the rule match is recorded and visible in message trace details. After a week, review the matches, then switch to Enforce.

PowerShell: which rules matched a message?

$trace = Get-MessageTraceV2 -SenderAddress "anna.meier@woodgrove.example" `
    -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date)

foreach ($m in ($trace | Select-Object -First 20)) {
    Get-MessageTraceDetailV2 -MessageTraceId $m.MessageTraceId -RecipientAddress $m.RecipientAddress |
        Where-Object { $_.Event -eq "Transport rule" } |
        Select-Object @{n="Subject";e={$m.Subject}}, Date, Event, Detail
}

# After review: switch a rule to enforce
Set-TransportRule -Identity "DLP | Block Strictly Confidential | External" -Mode Enforce

Typical problems and their causes:

Inventory and clean-up of existing rules

Before Woodgrove built anything new, the existing 37 rules were exported and classified. The following script produces a review list and flags the patterns that most often indicate a problem:

PowerShell: rule inventory with risk flags

$rules = Get-TransportRule
$report = foreach ($r in $rules) {
    $flags = @()
    if ($r.SetSCL -eq -1)                                 { $flags += "Bypasses spam filtering" }
    if ($r.BlindCopyTo -or $r.CopyTo -or $r.AddToRecipients) { $flags += "Copies mail to additional recipients" }
    if ($r.RedirectMessageTo)                             { $flags += "Redirects mail" }
    if ($r.MessageContainsDataClassifications)            { $flags += "Uses retired DLP condition" }
    if ($r.State -eq "Disabled")                          { $flags += "Disabled" }
    if (-not $r.Comments)                                 { $flags += "No documentation" }
    [PSCustomObject]@{
        Priority = $r.Priority
        Name     = $r.Name
        State    = $r.State
        Mode     = $r.Mode
        Changed  = $r.WhenChanged
        Flags    = $flags -join "; "
    }
}
$report | Sort-Object Priority | Export-Csv .\TransportRule-Review.csv -NoTypeInformation -Encoding UTF8
$report | Where-Object Flags | Format-Table Priority, Name, Flags -AutoSize

The result at Woodgrove: of 37 rules, 21 were deleted (obsolete, duplicate or retired conditions), 4 were consolidated into the new disclaimer and routing rules, the BCC rule for the managing partner was removed after confirming it was no longer wanted, and the two SCL -1 rules were replaced by properly scoped entries in the Tenant Allow/Block List. Together with the new rules for R1 to R6, the tenant ended with 14 documented rules in a clear naming scheme.

Why mail flow rules deserve more attention

They enforce policy where users cannot interfere. Training tells people not to send confidential data to private addresses. A transport rule makes the decision for them, consistently, for every message, from every client. For requirements with legal weight, such as professional secrecy, auditor independence or contractual TLS obligations, that consistency is the difference between a policy and a control.

They are already licensed. Mail flow rules are part of every Exchange Online plan. Many of the controls in this article would otherwise be bought as a separate gateway or add-on. Knowing what the platform can do is the cheapest form of security investment.

They are also a risk if nobody looks after them. A rule that BCCs every message of an executive to another mailbox, or one that bypasses spam filtering for a domain, is a perfect persistence mechanism for an attacker with admin access, and an easy audit finding. Regular inventory, naming conventions, comments and backups turn a hidden attack surface into a documented control set.

They complement Purview, they do not replace it. Since sensitive information detection moved to Purview DLP, the most robust design uses both: Purview for content classification across workloads, mail flow rules for message modification, routing, moderation, attachment handling and ethical walls. Organisations that understand that boundary get the best of both.

Regulators ask about email. The Swiss revFADP and the GDPR expect appropriate technical measures for personal data in transit; professional standards for fiduciaries, auditors, lawyers and banks add confidentiality and independence requirements on top. Each of the rules above can be shown to an auditor, together with its comment, owner and message trace evidence. That is compliance you can demonstrate.

Checklist

• Existing rules inventoried; obsolete, undocumented and risky rules removed.
• No rules using the retired sensitive information conditions; content detection moved to Purview DLP.
• Naming convention and comments (owner, requirement, ticket) for every rule.
• Rule collection exported before every change; restore procedure documented.
• New rules always start in Audit mode; matches reviewed in message trace before enforcing.
• Disclaimer applies only to external mail, does not stack, and has a deliberate fallback action.
• Label-based blocking for message labels; Purview DLP for labelled attachments.
• Password-protected and unscannable attachments moderated outbound and quarantined inbound.
• Partner connectors enforce TLS where contracts require it.
• Conditional routing through rule-scoped connectors.
• Ethical walls for email; Information Barriers for Teams and SharePoint where required.
• Rule limits monitored with Get-EtrLimits.