Outlook rules not working? Check your version, account, and rule order

A rule that worked in classic Outlook may behave differently after switching to new Outlook. The account type, the actions in the rule, and its position in the list all matter. Start by identifying the app and checking one rule at a time, rather than deleting your existing setup.

This guide follows Microsoft’s current support documentation. It focuses on incoming-mail rules in Windows and the web interface. A workplace administrator may restrict available settings, and an error affecting an entire organization needs their help.

1. Identify the Outlook app and mailbox

Classic Outlook has a File tab with options such as Manage Rules & Alerts. New Outlook uses its Settings interface for mail rules. If you are unsure, compare your screen with Microsoft’s version-identification guide before following menu instructions.

Also note the mailbox involved: Outlook.com, a Microsoft 365 work or school account, or a third-party account. Microsoft currently says new Outlook does not support rules for Gmail, Yahoo, and iCloud accounts. For those mailboxes, use the provider’s own rule or filter settings. A missing Rules option can therefore reflect account support rather than a damaged installation.

2. Review the rule without changing its purpose

1. In new Outlook, open Settings, Mail, then Rules.
2. In classic Outlook, open File, then Manage Rules & Alerts, and select the appropriate mailbox if shown.
3. Confirm that the rule is enabled.
4. Open its conditions, exceptions, and destination folder.
5. Record the settings before editing anything.

A renamed or missing destination can leave a rule needing repair. A condition may also be narrower than expected: a sender address, a word in the subject, or an exception can exclude the message you are testing. Microsoft’s broken-rule guide explains how to modify invalid rule details.

3. Check whether the action needs classic Outlook

New Outlook, Outlook on the web, and Outlook.com support server-side rules. Some classic rules require the desktop app to be running because their actions depend on that computer. Playing a sound is one example described by Microsoft. Such a client-only rule cannot simply become a server-side rule after migration.

If the original action is unavailable, decide whether a simpler supported action would meet your need. Moving incoming mail to a mailbox folder may be enough where a desktop-specific action was previously used. Preserve the original rule’s description, and temporarily disable a superseded rule during a controlled test instead of deleting the whole rules collection.

4. Review earlier rules and stop-processing behavior

Suppose a broad rule handles every message sent to a project address. A later rule targets one particular sender. The earlier rule’s Stop processing more rules option may prevent the later rule from acting on a message that matches both.

Check the rules above the one that appears broken. Microsoft explains the interaction in its stop-processing guide. Changing order can affect other messages too, so write down the existing sequence and change only what you understand. Do not turn off every stopping condition as a general fix.

5. Test a new message before processing old mail

Ask for a harmless test message that exactly matches the condition, or send one from another account you control. Use a distinctive subject and verify which folder receives it. A new inbox rule normally applies to mail arriving after its creation; old messages remaining in place do not by themselves prove failure.

Microsoft documents manual running under Settings, Mail, Rules in new Outlook, and Run Rules Now in classic Outlook’s Rules & Alerts dialog. Availability can differ by account and release. Before using either option, inspect the actions: running a delete or forwarding rule over existing mail could have wider effects. Start with a narrowly scoped move-to-folder test.

6. Preserve evidence if the problem continues

In classic Outlook, consider exporting your existing rules before substantial restructuring. Microsoft provides an import and export procedure; keep that file private because it describes your mailbox workflow.

For further help, collect the app version, mailbox type, exact error, rule conditions, and the time of a failed test. Redact personal addresses and message contents before sharing screenshots. Those details distinguish an unsupported action, an ordering conflict, and a service problem without sacrificing the setup you already have.

Prepared with AI assistance from the linked documentation. This is a source-led explanation, not a claim of hands-on testing across every device. Read the editorial policy.