How to Remove Automapping for a Shared Mailbox in Outlook

A shared mailbox that won't leave the Outlook folder list, or one an ex-team member can still open weeks after you pulled their access, is almost always automapping, not a broken permission. Automapping is a side effect of Exchange Online's Autodiscover process: any account with Full Access to a mailbox gets that mailbox loaded into its Outlook profile automatically, whether or not anyone wants to see it there.

You can't switch automapping off for a permission that already exists — Exchange has no separate on/off setting for it anywhere in the admin center. To remove automapping for a shared mailbox, an admin has to remove the user's Full Access permission and grant it back with automapping explicitly disabled. Below is the exact PowerShell sequence Microsoft documents for this, what changes for the end user and what doesn't, and the one step people skip that makes the fix look like it didn't work.

Left alone, it's more than a cosmetic annoyance. An account with Full Access to a dozen mailboxes tries to open all of them the moment Outlook starts, which is a documented cause of slow startup and sluggish sync. A former employee who still automaps into a shared mailbox isn't a permissions bug on its own, but it's the kind of loose end that shows up badly in a security review, and it's easy to lose track of once a few people have rotated through the same shared inbox over a year or two.

The short answer#

There's no per-mailbox "automapping: off" toggle inside the Exchange admin center or Outlook itself. The value is only set at the moment a Full Access permission is created, through the AutoMapping parameter on Add-MailboxPermission in Exchange Online PowerShell.

So the fix is a two-step swap: remove the existing permission, then add it back with -AutoMapping $false. The user's actual access to the mailbox doesn't change for a second — they can still open it manually — but Outlook stops loading it into their profile on its own.

Nothing about the mailbox itself changes. Its size, its folders, the mail sitting in it, delegate rules, forwarding — none of that is touched by this fix. AutoMapping is purely a client-loading behavior, which is exactly why it's safe to run on a live, actively used shared mailbox without warning anyone the mailbox itself is about to change.

• Requires an Exchange admin role — end users can't make this change themselves.
• Doesn't revoke access. It only stops Outlook from opening the mailbox automatically.
• Applies per user, per mailbox — repeat it for every account that should stop auto-loading it.
• Works the same whether the mailbox is a dedicated shared mailbox or a regular user mailbox someone has Full Access to.

Before you start#

Confirm who currently has access and how before you touch anything. Run Get-MailboxPermission against the shared mailbox and check the User and IsInherited columns — a permission inherited from a security group behaves differently and usually can't be fixed one user at a time.

You'll need an Exchange admin role that includes mailbox-permission management — Global Administrator or Exchange Administrator in Microsoft 365, or the Recipient Management role group on-premises. If you only have Outlook access to the mailbox yourself and no admin rights, skip ahead to "How do I hide a shared mailbox in Outlook" in the FAQ — that's a client-side workaround with different trade-offs.

You'll also need the Exchange Online PowerShell connection itself, not just the role. Most tenants require the ExchangeOnlineManagement module and modern authentication — a plain username-and-password connection stopped working years ago for any tenant with security defaults or Conditional Access turned on, which by now is most of them.

• An account with Exchange admin permissions (not just Outlook access to the mailbox).
• The ExchangeOnlineManagement PowerShell module installed and a modern-auth sign-in.
• The exact identity of the mailbox and the user — alias, UPN, or email address, not a display name that might match more than one account.
• Fifteen minutes and a mailbox you're not planning to reboot mid-command.

Steps: remove and re-add the permission with automapping off#

This is the sequence Microsoft documents for Exchange Online. Swap in your mailbox's alias or email address and the affected user's account wherever the examples show a placeholder.

If the mailbox is a Microsoft 365 Group mailbox rather than a dedicated shared mailbox, both cmdlets need the -GroupMailbox switch added, or Exchange won't recognize it as a valid target. It's a one-word difference, and it's worth checking first if the commands below don't seem to find the mailbox at all.

1. 1

   Connect to Exchange Online PowerShell

   Open PowerShell and connect with an account that has Exchange admin permissions. If the module isn't installed yet, Microsoft's Connect to Exchange Online PowerShell guide covers the one-time setup.

2. 2

   Remove the existing Full Access permission

   Run Remove-MailboxPermission -Identity "SharedMailbox" -User "[email protected]" -AccessRights FullAccess -Confirm:$false. The -Confirm:$false skips the "are you sure" prompt Exchange shows by default before a Remove- command runs.

3. 3

   Re-add the permission with automapping disabled

   Run Add-MailboxPermission -Identity "SharedMailbox" -User "[email protected]" -AccessRights FullAccess -AutoMapping $false. This is the step that actually matters — you can only set AutoMapping at the moment a permission is granted, never on one that already exists.

4. 4

   Confirm the change took

   Add-MailboxPermission prints a confirmation table with the identity, user and access rights it just applied. Run Get-MailboxPermission -Identity "SharedMailbox" afterward if you want a clean before-and-after record for the ticket.

5. 5

   Repeat per mailbox, per user

   Automapping is set per permission, not globally. If one person has Full Access to three shared mailboxes and you only want two of them gone, run the remove-and-readd pair three separate times, disabling AutoMapping only where you actually want it off.

6. 6

   Tell the user what to expect

   The mailbox won't vanish the second the command finishes. Warn them it can take up to about an hour to drop out of their Outlook folder list, and that restarting Outlook usually speeds that up.

Does this work the same way across every Outlook platform?#

The underlying mechanism — Autodiscover automapping any mailbox tied to a Full Access permission — is one Exchange behavior, but what a user can do about it locally depends heavily on which Outlook they're running and whether the mailbox was automapped or manually added.

The pattern across every row is the same: a mailbox the user manually added, they can manually remove. A mailbox Autodiscover added on its own, only the server-side permission change can take away for good. Whichever client is open at the time, that distinction — not the platform — decides whether there's a button to click.

What to do when it doesn't work#

If you ran the commands and the mailbox is still sitting in the folder list a day later, the permission fix and the visible symptom are usually two separate problems stacked on top of each other.

Outlook doesn't re-check Autodiscover every time it opens — the mapping it already loaded is cached locally. Microsoft's own guidance says it can take up to about an hour to drop out after the server-side change, sometimes longer if the machine has been asleep or offline. Restarting Outlook, or signing out and back in on mobile, usually forces the recheck.

Exchange Online also has a narrower option worth knowing about: Remove-MailboxPermission -Identity "SharedMailbox" -ClearAutoMapping excludes a mailbox from automapping for every user with Full Access to it, in one command, without touching individual permissions. Microsoft's documentation for it adds a catch: if one specific user still doesn't clear, you're back to removing and re-adding that person's permission with -AutoMapping $false — so treat ClearAutoMapping as a shortcut for the common case, not a guarantee for a stubborn one.

A second common cause: the permission isn't actually the user's own — it's inherited from a security group with Full Access. Removing an individual permission does nothing in that case, because they never had one; group membership is what's granting access, and that gets fixed by removing them from the group, not by running these two cmdlets against their account.

A third cause worth ruling out: what looks like a stuck shared mailbox is sometimes Send As or Send on Behalf permission, not Full Access at all. Automapping only ever triggers off Full Access — Send As lets someone send mail as the mailbox without ever giving them a folder to see, so if the mailbox is genuinely gone from the folder list but the user can still send from it, that's two separate permissions doing exactly what they're supposed to, not a leftover automapping problem.

A faster way to keep shared-mailbox access honest#

Automapping is a one-time PowerShell fix, but the problem behind it isn't. Full Access grants tend to outlive the reason someone got them, and nobody notices until a mailbox that should've disappeared months ago shows up in the wrong person's folder list.

We build AI Emaily, and its shared-inbox handling works from the mailbox access your organization has already granted rather than adding another automatic-mapping layer on top of it — who has access, and what they've done with it, stays visible instead of quietly accumulating the way Full Access permissions tend to. It doesn't replace the PowerShell fix above; it's what keeps you from needing it as often.