How to Set Up Rules for a Shared Mailbox in Outlook

If you built a rule for a shared mailbox in Outlook — file everything from support@ into a folder, flag anything mentioning "urgent" — and nothing is happening, the rule is probably running, just not where you think. It likely filed itself under your own personal mailbox instead of the shared one, because the shared mailbox only looked like a separate account in your folder list. Underneath, Outlook still treated the whole thing as an extension of you, and a rule built from inside that illusion belongs to you, not the team. The fix is quick once you know where to look.

The short answer#

A rule for a shared mailbox in Outlook only counts if you built it while genuinely working inside that mailbox's own identity, not just its folders. Two setups reliably do that: add the shared mailbox to Outlook as its own account instead of relying on auto-mapping, or sign in to Outlook on the web directly as the shared mailbox and build the rule from Settings there. Almost every other route — including rules built from an auto-mapped folder in classic Outlook, or from the "Open another mailbox" shortcut — quietly attaches the rule to your personal account, so it only fires while your own Outlook is open, if it fires at all. You can check which mailbox actually owns a rule in under a minute once you know where Outlook shows it.

• Add the shared mailbox as a separate account in Outlook — its rules then belong to that account, not to you.
• Sign in to Outlook on the web as the shared mailbox itself and build the rule from inside that session — the rule belongs to the mailbox from the start.

Before you start#

Two things decide which route is even open to you, and both are worth checking before you click through any menus. First, permissions: you need Full Access to the shared mailbox, granted by an Exchange admin — Send As and Send on Behalf are not enough. Those two only control what name appears on outgoing mail; neither one lets you open the mailbox's own Settings or manage its rules. Second, sign-in: Microsoft blocks direct sign-in to shared mailboxes by default, on the assumption that people will always reach them through their own account rather than a shared password. If you want the Outlook-on-the-web route, where you sign in as the mailbox itself, an admin has to explicitly enable sign-in and set a password for it — a step some IT teams are reluctant to take, since it turns the mailbox into something closer to a normal login.

If you are the admin, both checks take one look in the Exchange admin center or a single PowerShell line: Get-MailboxPermission on the shared mailbox shows who has Full Access, and Get-Mailbox with the shared-mailbox filter shows whether sign-in is currently blocked. Turning sign-in on is reversible and does not change the mailbox's licensing — it stays license-free as long as it stays under Microsoft's storage threshold for shared mailboxes. Confirm both before your team spends time building rules that will not stick.

• Confirm you have Full Access, not just Send As or Send on Behalf.
• Ask whether auto-mapping is on for the mailbox — it's on by default once Full Access is granted.
• Check whether direct sign-in to the mailbox is enabled, which the Outlook-on-the-web route needs.
• Note which Outlook you're in — classic desktop, new Outlook, or the web — since the exact menu path differs.
• If you're the admin, Get-MailboxPermission and the mailbox's sign-in setting answer both questions in PowerShell.

Steps: build a rule the shared mailbox actually owns#

There are two reliable paths, and you only need one of them — pick based on what your admin allows. Route A keeps everything inside your existing Outlook installation by adding the shared mailbox as a genuine second account rather than letting it auto-map. Route B works from any browser, needs no new software, but requires the mailbox's own sign-in to be turned on first. Both produce a rule that belongs to the mailbox rather than to you, which is the entire point.

1. 1

   Confirm Full Access

   Ask your admin to confirm you have Full Access permission to the shared mailbox, not Send As or Send on Behalf alone. Without Full Access, you can't add the mailbox as a separate account, sign in to it directly, or manage its rules — no matter which route you try next.

2. 2

   Route A — add it as a separate account

   In classic Outlook, go to File, Add Account, and add the shared mailbox's email address as a brand-new profile entry, rather than letting Outlook auto-map it under your primary account. In new Outlook, open Settings, Accounts, Add account, and add the shared mailbox the same way you'd add any other mailbox you have permission to.

3. 3

   Build the rule inside that account

   With the shared mailbox now listed as its own account, open its Rules specifically. In classic Outlook's Manage Rules & Alerts dialog, use the "Apply changes to this folder" dropdown at the top to pick the shared mailbox before you click New Rule. In new Outlook, use the account switcher at the top of the Settings pane to select the shared mailbox before you add a rule.

4. 4

   Route B — confirm the mailbox can sign in directly

   Ask your admin to enable direct sign-in for the shared mailbox and set an initial password, if that hasn't already been done. This is the step people most often skip, then wonder why signing in as the mailbox just bounces back to their own account.

5. 5

   Sign in to Outlook on the web as the mailbox

   Go to outlook.office.com in a private or separate browser window and sign in using the shared mailbox's own address and password — not your personal account with the mailbox opened alongside it. A private window avoids mixing up the session with your existing sign-in.

6. 6

   Create the rule from inside that session

   From that signed-in session, go to Settings, Mail, Rules, and add the rule there. Because the session belongs to the mailbox itself, the rule is created as a server-side rule owned by that mailbox, and it will keep running no matter who's signed into it later.

7. 7

   Verify ownership before you trust it

   Sign out, sign back in as yourself, open the shared mailbox the way your team normally does, and check its Rules list again — via "Apply changes to this folder" in classic Outlook, or the account switcher in new Outlook and the web. If the new rule shows up there and not in your personal rule list, it's attached correctly.

Platform differences: where a shared-mailbox rule actually lives#

Which route you can use, and whether a rule you build actually attaches to the shared mailbox, depends on which Outlook you're in. The table below is the fast way to check before you build anything.

What to do when a shared-mailbox rule doesn't work#

If a rule you built still isn't firing on the shared mailbox, the fastest diagnosis is to check which mailbox actually owns it. Open Rules while genuinely working inside the shared mailbox's own context — not just its folders — and see whether your rule is listed there. If it only shows up in your personal rule list, it was built against your own account the whole time, usually because the mailbox was auto-mapped or you used "Open another mailbox" rather than adding it as a true separate account or signing in directly.

A second common failure: the rule exists on the shared mailbox but only some team members see its effect. That points to a client-only rule created in classic Outlook, which runs only inside the desktop app that built it and never reaches Exchange's servers — so it works for whoever created it and does nothing for everyone else. Rebuild it using only server-evaluated actions (move to folder, categorize, flag, forward) rather than anything app-bound like a sound or a desktop alert, and it will run centrally for the whole team, on every device, whether or not that person's Outlook is even open.

If you're the admin being asked to troubleshoot this for someone else, two checks answer most tickets fast. Run Get-MailboxPermission against the shared mailbox to confirm the person actually has Full Access — a missing grant looks identical to a broken rule from the user's side. And if someone reports an access error or a sign-in loop when trying the web route, check whether sign-in was ever enabled for the mailbox, or whether a later policy change disabled it again; if it's off, no rule the user builds that way will ever attach to the mailbox, because they were never really signed in as it.

One more wrinkle worth knowing: a rule you finally get attached to the shared mailbox still only acts on mail arriving from that point forward, exactly like a personal-mailbox rule. If there's an existing backlog in the shared inbox, the new rule won't reach back over it — in classic Outlook, use Run Rules Now against the shared mailbox to sweep the backlog once; in new Outlook and the web, sort the backlog by hand and let the rule handle everything after.

• Rule shows only in your personal rules list → it's yours, not the mailbox's — rebuild it via Route A or Route B.
• Rule works for you but not a teammate → it's client-only, created in classic Outlook — rebuild it with server-side actions only.
• Rule vanished after an admin change → Full Access was revoked or sign-in was disabled again — confirm access before rebuilding.

A faster way to keep a shared inbox sorted#

The two routes above work, but they're manual, per-mailbox, and easy to undo by accident — someone re-enables auto-mapping, a teammate builds a rule from their own account without realizing it, and the shared inbox drifts back into chaos. If your team lives in a shared inbox continuously rather than occasionally, AI Emaily connects it once and applies its Rules + Context Brain to that mailbox specifically, so filing and triage rules aren't tied to whoever happens to be signed in at the time. Every automated action stays visible in an approve-before-send queue with undo and a full audit trail, so nothing sends without a human confirming it first. We build AI Emaily. See how shared inboxes work at aiemaily.com/features/rules-brain.