9.7 Transport Rules for Security

Transport Rules for Security

By the end of this subsection, you will know the most effective transport rules for email security, understand how the Module 14 transport rules blocked Waves 4-5, and be able to create rules for your environment.

Transport rules (also called Exchange mail flow rules or Exchange Online protection rules in some documentation) process every email that flows through Exchange Online. They evaluate conditions and take actions before the email reaches the user’s mailbox — making them a powerful pre-delivery security control.

The four essential security transport rules

The Module 14 transport rules — how they blocked Waves 4-5

In Module 14, three transport rules were deployed during the incident:

Rule 1: URL pattern block. Condition: message body or URL matches /auth/[a-f0-9]{32}/login. Action: reject with NDR explaining the block. This caught the phishing kit’s URL structure regardless of which domain it was deployed on. Waves 4 and 5 used new domains but the same URL pattern — blocked before delivery.

Rule 2: External sender banner. Condition: sender is external. Action: prepend HTML banner. Users reported this helped identify Wave 5’s “project update” lure as external when the subject line implied internal communication.

Rule 3: Lookalike domain block. Condition: sender domain contains “northgate” AND sender is external. Action: reject. Caught all future domains matching the attacker’s naming pattern.

Creating the URL pattern block rule

1. Navigate to Exchange admin center -> Mail flow -> Rules -> Add a rule
2. Condition: “The subject or body includes” -> enter the URL pattern
3. For regex patterns: use “The subject or body matches text patterns” -> enter the regex
4. Action: Reject the message with the explanation -> “This email was blocked by a security transport rule. Contact IT if you believe this is an error.”
5. Exceptions: None (or add specific senders if needed)
6. Priority: Set high (lower number = higher priority)

Required role and blast radius

Required role: Exchange Administrator.

Security-critical transport rules

Transport rules (mail flow rules) operate at the transport layer — after authentication but before delivery. They can modify, redirect, block, or tag email based on conditions you define.

Rule 1: External email warning banner.

Adds a visual warning to all email from outside the organisation: “[EXTERNAL] This email originated from outside Northgate Engineering. Do not click links or open attachments unless you recognise the sender.”

# PowerShell:
# New-TransportRule -Name "External Email Banner"
#   -FromScope NotInOrganization
#   -ApplyHtmlDisclaimerLocation Prepend
#   -ApplyHtmlDisclaimerText '<div style="background:#FFF3CD;border:1px solid #856404;padding:10px;margin-bottom:10px;font-family:sans-serif;font-size:13px;color:#856404;"><strong>[EXTERNAL]</strong> This email originated from outside Northgate Engineering. Do not click links or open attachments unless you recognise the sender.</div>'
#   -ApplyHtmlDisclaimerFallbackAction Wrap

Blast radius: All external email gets the banner. Internal email is unaffected. Users may initially flag all external email as suspicious (banner fatigue). After 2-3 weeks, users calibrate: the banner is an environmental cue, not an alarm.

Cost: £0. Included in all Exchange Online plans.

GRC: ISO 27001 A.6.3 (Information security awareness). The banner demonstrates user awareness measures to auditors.

Rule 2: Block external auto-forwarding.

Prevents users (or attackers who have compromised an account) from creating inbox rules that forward email to external addresses:

# New-TransportRule -Name "Block External Forwarding"
#   -FromScope InOrganization
#   -SentToScope NotInOrganization
#   -MessageTypeMatches AutoForward
#   -RejectMessageReasonText "External email forwarding is not permitted."

Blast radius: All external auto-forwarding blocked tenant-wide. This includes: malicious forwarding by attackers (the primary target), legitimate forwarding by users who forward work email to personal accounts (a common but insecure practice), and automated forwarding by business processes (some CRM integrations use forwarding).

Before enabling: audit existing forwarding rules: Get-Mailbox -ResultSize Unlimited | Where-Object { $_.ForwardingSmtpAddress -ne $null } | Select UserPrincipalName, ForwardingSmtpAddress. Notify affected users. Provide alternative solutions (Outlook mobile for personal access, rather than forwarding).

This is the single most impactful BEC prevention control after verbal verification. The Module 13 attacker created an inbox rule forwarding email to an external address — this transport rule blocks that action entirely.

Rule 3: Block high-risk attachment types.

Prevent delivery of attachment types commonly used for malware delivery:

# New-TransportRule -Name "Block Dangerous Attachments"
#   -AttachmentExtensionMatchesWords "exe","bat","cmd","ps1","vbs",
#     "js","wsf","scr","hta","dll","iso","img","vhd","vhdx"
#   -RejectMessageEnhancedStatusCode "5.7.1"
#   -RejectMessageReasonText "Blocked: attachment type not permitted."

Blast radius: Legitimate executables and scripts cannot be emailed. This affects: software vendors sending installers (redirect to secure file transfer), IT teams sharing scripts (use SharePoint), and users sharing disk images (use SharePoint or OneDrive).

Note on .iso and .img files: These bypass Mark of the Web (MOTW) in some Windows configurations — a file inside an ISO does not inherit the MOTW flag, allowing macros to execute without the “Enable Content” prompt. Block these at the transport layer.

1
2
3
4
5
6
7
8

// Monitor transport rule hits — which rules are firing?
EmailEvents
| where TimeGenerated > ago(30d)
| where DeliveryAction == "Blocked"
| extend RuleName = tostring(parse_json(tostring(AdditionalFields)).TransportRule)
| where isnotempty(RuleName)
| summarize Hits = count() by RuleName, bin(TimeGenerated, 7d)
| order by Hits desc

Review weekly. High hit counts on the external forwarding rule may indicate: users attempting to set up forwarding (training opportunity), or compromised accounts attempting to exfiltrate (investigate immediately).

Operational management of transport rules

Transport rules accumulate over time. Without governance, you end up with 30 rules — some conflicting, some obsolete, some created during incidents and never removed.

Monthly review checklist:

1. List all active transport rules: Get-TransportRule | Select Name, State, Priority | Sort Priority.
2. For each rule: is it still needed? Is the condition still relevant? Is the action still appropriate?
3. Check for conflicts: two rules that match the same email with contradictory actions (one blocks, one allows). The rule with the highest priority wins — verify this is the correct outcome.
4. Check for obsolete rules: rules created during incidents (blocking a specific sender domain) that should have an expiry date.

Rule naming convention: [Category]-[Action]-[Description]-[Date]. Example: SEC-Block-External-Forwarding-2026-03, INC-Block-PhishDomain-2026-02-27. Incident-specific rules include the incident date — making them easy to identify for cleanup. Permanent security rules use SEC- prefix.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Monitor which transport rules are firing and how often
EmailEvents
| where TimeGenerated > ago(30d)
| where tostring(AdditionalFields) has "TransportRule"
| extend RuleMatch = tostring(parse_json(tostring(AdditionalFields)).TransportRule)
| where isnotempty(RuleMatch)
| summarize
    HitCount = count(),
    UniqueRecipients = dcount(RecipientEmailAddress)
    by RuleMatch
| order by HitCount desc

Rules with zero hits in 30 days are candidates for removal (they may be targeting a threat that no longer exists). Rules with thousands of hits are working — verify they are not generating false positives by sampling the blocked emails in quarantine.

Transport rule deployment for incident response

During an active phishing campaign, transport rules are the fastest blocking mechanism — faster than updating anti-phishing policies or Safe Links block lists.

Incident blocking rule (deploy in < 5 minutes):

# New-TransportRule -Name "INC-Block-PhishDomain-2026-03-22"
#   -SenderDomainIs "evil-phishing-domain.com"
#   -RejectMessageReasonText "Blocked: known phishing domain."
#   -StopRuleProcessing $true

After the incident: Do not leave incident rules active indefinitely. Set a calendar reminder to review and remove 30 days after the incident. The domain may be abandoned by the attacker or repurposed — an indefinite block serves no purpose and clutters the rule list.

Advanced transport rule patterns

Beyond the three core security rules, consider these additional rules based on your threat model:

Rule 4: Block QR code phishing. QR codes in email bodies are an emerging attack vector (subsection 9.1). While you cannot perfectly detect QR codes in email, you can flag emails that contain images but no clickable URLs — a pattern consistent with QR code phishing (the attacker replaces the clickable URL with a QR code image to bypass Safe Links).

# New-TransportRule -Name "SEC-Flag-ImageOnlyEmails"
#   -FromScope NotInOrganization
#   -HasNoClassification $true
#   -AttachmentIsUnsupported $true
#   -SetHeaderName "X-QR-Risk"
#   -SetHeaderValue "ImageOnly-ExternalEmail"
#   -SetSCL 5

This does not block the email — it raises the spam confidence level, which increases the probability of it being junked or quarantined. Fine-tune: if legitimate image-only emails are affected (marketing newsletters with image-heavy layouts), add sender exceptions.

Rule 5: Encrypt sensitive outbound email. Automatically apply M365 Message Encryption to outbound email containing sensitive keywords:

# New-TransportRule -Name "SEC-Encrypt-Sensitive"
#   -SubjectOrBodyContainsWords "confidential","NI number","national insurance",
#     "bank details","salary","medical","passport number"
#   -ApplyOME $true
#   -ApplyOMETemplate "Encrypt"

Blast radius: Recipients outside M365 receive an encrypted email notification and must authenticate to read the content. Some recipients find this friction annoying. Balance: apply only to genuinely sensitive keywords, not generic terms like “important.”

Rule 6: Delay delivery for high-risk actions. When a new hire (first 30 days) sends email to external recipients with attachments: delay delivery by 1 hour. This gives time for: the sender to reconsider (if they accidentally attached a sensitive file), DLP to process the email, and Safe Attachments to complete full analysis.

These advanced rules demonstrate that transport rules are not just basic blocking — they are a flexible policy engine for implementing nuanced security controls that protect against both external threats and internal data handling errors.

Transport rules vs Defender policies — when to use which

Both transport rules and Defender policies can block email. Understanding when to use each prevents duplication and ensures the right tool is applied:

Use Defender policies for: Threat detection based on content analysis (phishing, malware, impersonation). These policies use ML models, sandboxing, and reputation data that transport rules cannot access.

Use transport rules for: Organisational policy enforcement (external banners, forwarding restrictions, attachment type blocking, encryption). These are business rules that do not require threat intelligence — they apply unconditionally based on structural criteria (sender scope, attachment extension, keyword presence).

Use transport rules for incident response: Blocking specific sender domains or IP addresses during an active campaign. Transport rules can be created and applied in under 5 minutes — faster than creating or modifying a Defender policy.

The overlap: Both can block email from a specific sender domain. Best practice: use Defender’s Tenant Allow/Block List for threat-based blocking (phishing domains, malware senders). Use transport rules for policy-based blocking (banned attachment types, forwarding restrictions). Do not duplicate the same block in both — it adds complexity without security benefit.

Monitoring transport rule conflicts

When you have 10+ transport rules, conflicts become likely. Two rules may match the same email with contradictory actions. Exchange processes rules in priority order and stops at the first match (if StopRuleProcessing is set).

1
2
3
4
5
6
7
8

// Identify emails matching multiple transport rules (potential conflicts)
EmailEvents
| where TimeGenerated > ago(7d)
| extend RuleMatches = extract_all(@'"TransportRule":"([^"]+)"',
    tostring(AdditionalFields))
| where array_length(RuleMatches) > 1
| project TimeGenerated, SenderFromAddress, Subject, RuleMatches
| take 100

If emails match multiple rules: review the rule priority order. The highest-priority rule’s action takes effect. Ensure this is the correct outcome. If a blocking rule should take priority over a tagging rule: set the blocking rule’s priority higher.

Attachment type blocking rule

Block executable attachment types that have no legitimate business purpose in email:

Blocked file types: .exe, .scr, .bat, .cmd, .ps1, .vbs, .js, .wsf, .hta, .com, .pif, .reg

Configuration: Exchange admin center -> Mail flow -> Rules -> “Block dangerous attachment types” -> Condition: Any attachment file extension includes [list above] -> Action: Reject message with explanation.

Monitoring transport rule effectiveness

1
2
3
4
5
6
7
8
9

// Check which transport rules are firing and how often
EmailEvents
| where TimeGenerated > ago(30d)
| where DeliveryAction == "Blocked"
| where DetectionMethods has "Transport rule"
| summarize BlockCount = count(), UniqueRecipients = dcount(RecipientEmailAddress)
    by Subject = tostring(split(Subject, " ")[0]), SenderMailFromDomain
| sort by BlockCount desc
| take 10