transport rule not working: reported phish not redirected to quarantine

TL;DR

A transport rule that silently does nothing usually has a condition that never matches the reported-phish format, is set to test mode, or is stopped by an earlier rule with stop-processing set. Reported phish often arrive as an attachment of the original message or via a reporting add-in with a specific subject or header. Trace one reported item through the rule engine and compare its properties with the rule conditions literally.

transport rule not working: reported phish not redirected to quarantine

Use this when

• Users report phish but the messages are not moved or redirected as designed.
• Rule audit shows the rule enabled but message trace shows no rule action.

Not for this skill when

• The rule fires and quarantines legitimate mail too. That is an over-broad condition problem.
• Reporting itself is broken and no report reaches the mailbox at all. Fix the reporting add-in first.

Steps

1. Take one reported phish from the reports mailbox and record its subject, headers and whether the original is an attachment. Verify: the real report format is documented.
2. Compare each rule condition and exception against that format, including header names and match type. Verify: every mismatch between condition and reality is listed.
3. Check the rule mode is Enforce, not Test, and check rules above it for stop-processing actions. Verify: mode and ordering cannot silently prevent firing.
4. Check the action target: quarantine or redirect address must exist and the rule action must not require an approval that nobody staffs. Verify: the destination is valid and monitored.
5. Send a controlled test report and trace it end to end. Verify: the rule action appears in the trace and the item lands in quarantine.

Variant phrasings

exchange transport rule not applying reported phish

The not-applying variant.

mail flow rule test mode enforce reported phishing

The mode-check variant.

Compatibility: Exchange Online mail flow rules and the Microsoft Report Phish add-in flow.

Why it happens

Transport rules match on exact message properties, and reporting workflows change those properties: the suspect message becomes an attachment and the outer message is generated by the add-in. Rules written against the original message properties therefore never match.

Edge cases / pitfalls

• Use the header the reporting tool stamps, rather than subject text users can change, as the primary condition.
• Audit rules quarterly; test-mode experiments are routinely forgotten in production.
• Keep rule priority intentional and document any stop-processing rule, since it ends evaluation for everything below it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_g3P3E84lnOMyverJvmr5zg