How to Import Rules Into New Outlook (Import Is Not Supported)

Can you import rules into new Outlook?#

No, and it is worth being blunt: there is no way to import rules into new Outlook. Classic Outlook for Windows can export your rules to a .rwz file, but the new client has no matching import, and Microsoft lists rules import and export as unsupported rather than planned.

That sounds worse than it usually is. If your mailbox is on Microsoft 365, Exchange or Outlook.com, a large share of your rules live on the mailbox itself rather than in the app — and those follow you into new Outlook without you doing anything. What disappears is the set of rules classic Outlook could only ever run on your own PC.

So the useful question is not how to import the .rwz. It is which of your rules were server-side, which were client-only, and how much rebuilding the second group really costs. The rest of this guide works that out before you switch.

Server-side rules versus client-only rules#

This is the distinction that decides everything, and most people have never been told it exists. A server-side rule is stored in your mailbox and run by the mail server, so it fires whether or not Outlook is open, on every device you use.

A client-only rule is stored in your Outlook profile on one computer and run by that copy of Outlook. It fires only while Outlook is running there, which is why classic marks it with the words client-only in the rules list.

A rule ends up client-only because it asks for something the server cannot do — play a sound, show a desktop alert, print, run a script, or file into a local data file. It is usually the action that demotes it, not the condition.

One case catches people out completely. If the account in classic Outlook is POP or IMAP — a personal Gmail address added over IMAP, for instance — there is no mailbox rules store behind it, so every Outlook rule you built for that account is client-only. Change clients and none of it comes with you.

How to tell which of your rules are server-side#

Do this in classic Outlook before you switch, or from any browser if you have already switched. It takes about fifteen minutes and it replaces guesswork with a list you can act on.

1. 1

   Open the full rules list in classic Outlook

   File, Manage Rules and Alerts, then the Email Rules tab. It shows every rule on this profile, enabled or not. Widen the dialog so the descriptions are readable — that is where the detail lives.

2. 2

   Note every rule marked client-only

   Classic appends client-only to rules that can only run on this PC. That label answers the question for most rules, and the ones it flags are exactly the ones you are about to lose.

3. 3

   Cross-check in Outlook on the web

   Open your mailbox in a browser, then Settings, Mail, Rules. This is the server-side list, held in the same store new Outlook reads. Anything you can see here has already made the move.

4. 4

   Compare the two lists

   Any rule in classic that is missing from the browser is client-only, whatever the labels suggest. That comparison is the audit. Everything else in this list is confirmation or preparation.

5. 5

   Work out why each missing rule is local

   Read its actions. Playing a sound, showing a New Item alert, printing, starting an application, running a script, or moving mail into a local .pst file all force a rule to run on the PC. So does sitting on a POP or IMAP account.

6. 6

   Write down what each losable rule does

   Name, conditions and actions, in plain language, in a document you keep outside Outlook. This inventory is what you rebuild from, and the .rwz cannot give it to you — it is a binary file you cannot read.

7. 7

   Export the .rwz as a backup

   File, Manage Rules and Alerts, Options, Export Rules. Store it next to the inventory. It will not import into new Outlook, but it restores a classic profile if you go back or move to another PC.

8. 8

   Confirm with PowerShell if you want certainty

   In Exchange Online PowerShell, Get-InboxRule against your mailbox returns the server-side rules and nothing else. A rule name missing from that output is client-only. Admins can run it across a team before a migration.

Two rules can look identical in the list and behave completely differently once you move. Usually a single action is the entire reason one of them never left your PC.

What survives which move#

Rules do not survive or die as a group. What carries over depends on which move you are making, so find your row before you assume the worst.

That last row is the harsh one, and it is common. It also explains why two people can switch on the same morning and have completely different days: the one on Microsoft 365 loses a handful of alert rules, the one running IMAP loses the lot.

Rebuilding the rules you lost#

Work from your inventory, highest value first. In new Outlook, rules live under Settings, Mail, Rules, and the same rules show up in Outlook on the web, because from here on they belong to the mailbox rather than to the app.

Rebuild by intent, not line by line. A rule that played a sound for mail from your biggest client is really a rule about priority — express that as a move, a category or a flag, and let notification settings carry the urgency.

Some rules have no honest replacement. Run a script, start an application and file into a local .pst went away with the desktop process that hosted them. If the task is repeatable, Power Automate or a Microsoft Graph script is the realistic path; if it needed judgement, it was never really a rule.

• Rebuild what protects your attention first: VIP routing, client folders, escalation flags.
• Then the bulk filing: newsletters, receipts, system notifications, automated reports.
• Then the long tail — and expect to skip much of it. A large share of most rule collections points at senders, projects or vendors that no longer exist.
• Test each rebuilt rule against real mail, and plan to file the existing backlog yourself. A new rule acts on messages as they arrive.

Where should your rules live from here?#

If you are rebuilding anyway, this is a fair moment to ask where the rules belong. We build AI Emaily, so read the first row as advocacy — but the caveat is real and it applies to us too: we cannot import a .rwz file either. Nobody can. Rules are a rebuild in every destination, ours included.

What AI Emaily adds is the layer classic rules never had. A rule can match on what the agent understood about a message — one it tagged as needing a reply today, or one attached to a particular client profile — rather than only on literal text in the subject line. It can then hand that message to the agent with the Route to agent action, so the rule does the matching and filing and the agent produces the draft.

Those drafts come from a Personal Context you write yourself and from client profiles you set, not from us reading through your old mail. In Copilot mode nothing sends without your approval, actions can be undone, and there is an audit trail of what ran and why. Rules sit in one place per account and cover Gmail, Outlook and IMAP together; connecting a Microsoft 365 mailbox is walked through at /docs/connect-outlook, and the rules and Context brain page is at /features/rules-brain.

Where we are not the answer: if your rules are already server-side and you are staying inside Microsoft 365 under policies your admin controls, new Outlook's own rules are the right home and a second client buys you nothing. And if a rule genuinely has to run a Windows script, classic Outlook is the only client on that table that can do it — ours included.

How to avoid losing rules next time#

• Keep a plain-language inventory of your rules in a document, not only in the client. Every export format is binary or vendor-specific; a written list of what and why moves to anything.
• Prefer server-side actions where you have a choice. A rule that moves and categorises follows the mailbox. A rule that plays a sound belongs to one computer.
• Push shared logic to your admin. If a whole team needs the same routing, a mail flow rule outlives every client change any of them make.
• Re-export the .rwz whenever you change rules meaningfully, and keep it with the inventory rather than in Downloads.
• Review quarterly and delete. A smaller set is easier to move, easier to debug, and less likely to run into the 256 KB quota.

The short version#

You cannot import rules into new Outlook. Classic exports a .rwz, new Outlook has no import for it, and the file is a classic-Outlook backup rather than a migration path.

Your server-side rules almost certainly made the trip already — confirm it in the browser under Settings, Mail, Rules. Your client-only rules did not and never will, because they only ever existed inside a desktop app. Rebuild those by intent, and write the inventory down this time, so the next move costs you an afternoon instead of a decade of filters.