A mail rule that never fires because something above it stops processing
The rule was correct, enabled, and matched. It never ran once, because a rule two places above it ended the queue.
Mail transport rules run in priority order, and any of them can be set to stop processing further rules once it matches. That flag is invisible in most summary views.
We added a rule to reject mail from a group of retired mailboxes with a helpful message. It was enabled, correctly scoped, and did nothing at all. The tenant was running a third party signature service, which had installed its own rule near the top with stop processing set. Anything below it never executed.
Check before you debug the rule
Get-TransportRule | Select Name, Priority, StopRuleProcessing | Format-Table -AutoSizePriority 0 runs first. Any rule below one with stop processing enabled will only run if the earlier rule did not match.
The fix
Set-TransportRule -Identity "Your rule" -Priority 0Putting a narrowly scoped rule at the top is usually safe. Ours matched only seven specific senders and rejected outright, so everything else fell straight through to the rules below exactly as before.
In any tenant with a signature service, mail gateway or security add-on, assume there is a stop-processing rule near the top and place anything new above it.
The general shape
This pattern is everywhere: firewall rules, routing tables, permission evaluation, middleware chains, inbox rules. Ordered lists where an early entry can terminate evaluation. When something in such a list appears not to run, check what precedes it before checking the thing itself.
The clue is always the same. The rule is not failing, it is not being reached.
Need help with any of this?
These notes are free and always will be. If you would rather someone just set it up, or you are stuck on something similar, get in touch at hello@opsira.io.