Shared Mailbox Not Showing in Outlook: 7 Reasons

A shared mailbox not showing in Outlook is one of the most common tickets in any team that runs a shared support, sales, or ops inbox — and it's almost always one of the same seven causes, whether you're troubleshooting your own access or a teammate's. You were added to a shared mailbox, or your admin says the permission is already granted, but Outlook's folder pane still shows nothing.

That gap between "you have access" and "you can see it" is worth checking in order rather than guessing, because the fix for each cause is different — some are yours to fix in Outlook, some are your admin's, and one of them isn't fixable at all, only faster to add manually.

Before you touch a single Outlook setting, confirm the permission actually exists and is the right kind. Sign in to Outlook on the web — or new Outlook, which runs the same web engine — and look under Shared with me, or add the mailbox yourself via Add shared folder or mailbox. The web client reads permissions live from Exchange Online, with no local cache to mislead you.

If the mailbox shows up there and not on your desktop, the problem is local, not a permission problem. If it doesn't show up there either, the problem is on the admin side, and no amount of restarting Outlook will fix it. The seven causes below are ordered from most common to least — work down the list before you rebuild a whole profile, which fixes maybe one of the seven and costs an afternoon.

One more distinction worth making before the list: a mailbox that's silently absent and a mailbox that throws an explicit access-denied error are different symptoms with mostly different causes, even though both get described the same way in a support ticket. The list below covers the silent case, which is the far more common of the two; the access-denied case gets its own note after step 7.

Before you start#

A few minutes of prep saves several rounds of back-and-forth, especially if someone else — an admin or IT — granted the access in the first place and you're troubleshooting secondhand information.

Have these five things confirmed before you open a single Outlook menu. Each one rules out at least one of the seven causes below, and together they usually tell you which cause you're actually looking at before you touch anything.

• The exact email address of the shared mailbox — a typo in a manual add fails silently on some builds
• Whether you were granted Full Access, Send As, or both; they behave differently in the folder pane
• Whether automapping was left on or explicitly disabled when access was granted
• Your Outlook client and version — classic Outlook for Windows, new Outlook, Outlook for Mac, Outlook on the web, or mobile — because the fix differs by client
• How long ago the permission was granted, so you know whether you're still inside the normal wait window or genuinely stuck

The 7 reasons, checked in order#

1. 1

   Permission hasn't replicated yet

   Full Access is an Exchange Online permission, not a local Outlook setting, and it takes time to spread through Microsoft's infrastructure. Microsoft's own support guidance for classic Outlook is to allow up to a few hours after access is granted before the mailbox appears automatically. Field experience from IT admins skews faster than that in most tenants — often within an hour — but a few hours is the number to plan around rather than the number to panic before. If you already checked the web app in the step above and saw the mailbox there, this isn't your cause — move to reason 2.

2. 2

   Automapping is turned off

   When an admin grants Full Access, automapping is on by default, and it's what makes a shared mailbox appear in your folder pane without you doing anything. Admins turn it off deliberately in larger tenants, because automapping adds the mailbox to every delegate's profile whether they open it daily or once a year, and that slows Outlook's startup and bloats the local cache for everyone with access. If automapping is off, the permission exists but the mailbox will never self-add — you have to add it manually, and no amount of waiting fixes that. This is easy to confirm: ask your admin whether the Add-MailboxPermission command that granted you access included -AutoMapping $false.

3. 3

   You have Send As, not Full Access

   Send As and Send on Behalf let you send mail as the shared mailbox; neither one gives you a folder pane view of its inbox. This is the single most common false alarm — someone tells you "you have access" and means you can send from the address, not read what's in it. It shows up cleanly, too: you'll see the shared mailbox as a From option when composing, which is exactly the evidence that misleads people into thinking the rest should work. Confirm with your admin which permission was actually granted; the fix is a permission change, not anything you can do in Outlook.

4. 4

   Outlook's local profile is stale

   Cached Exchange Mode stores a local copy of your mailbox data (the .ost file) and refreshes it via Autodiscover on a schedule, not instantly. A permission granted an hour ago can be sitting correctly on the server while your desktop client hasn't re-polled Autodiscover yet. A full restart of Outlook — quitting it entirely from the taskbar or Dock, not just closing the window — forces a fresh Autodiscover call and usually clears this. On Windows, holding Ctrl while right-clicking the Outlook tray icon and choosing Test E-mail AutoConfiguration will confirm whether Autodiscover itself is returning the shared mailbox.

5. 5

   The mailbox itself has a licensing or state problem

   A shared mailbox gets 50 GB of storage without needing its own license. Push it past that, up to the 100 GB hard ceiling, and Microsoft can put the mailbox into a restricted state until someone assigns it an Exchange Online Plan 2 (or equivalent) license — and a restricted mailbox can stop appearing for delegates entirely. The same applies if the mailbox was accidentally converted to a regular user mailbox, disabled, or soft-deleted and restored without its permissions being reapplied. Ask your admin to check the mailbox's status in the Exchange admin center, not only the permission list.

6. 6

   Hybrid or cross-premises routing

   In a hybrid deployment, the shared mailbox and your own mailbox can live in different places — one on-premises, one in Exchange Online. Autodiscover can't resolve a cross-premises mailbox without hybrid modern authentication configured correctly, and when that piece is missing, the mailbox simply never appears no matter how long you wait. This one is easy to misdiagnose as a permission problem, because the permission genuinely was granted correctly — the failure is entirely in how the two environments discover each other. This is an admin-side fix, usually a gap in the on-premises Autodiscover or OAuth configuration.

7. 7

   You're on a client that doesn't automap

   Automapping is built on Autodiscover and is a classic-Outlook-for-Windows behavior. New Outlook, Outlook on the web, Outlook for Mac, and the mobile apps each handle a shared mailbox differently, and some of them never auto-add it — you add it manually every time, on every device. If your organization has recently moved you to new Outlook, or you switched from a desktop app to the web, the automapping you were used to simply doesn't carry over — it's a different client with a different mechanism, not a broken one. Check the platform table below before you assume something is broken.

How this differs by Outlook client#

Automapping itself is a classic-Outlook-for-Windows behavior layered on top of Autodiscover. Every other client handles a shared mailbox differently, and mistaking one client's behavior for another's is reason 7 above in practice more often than any real misconfiguration.

This matters more than it used to, because plenty of people are switching clients right now without choosing to. If your organization has moved you to new Outlook, or you've started checking mail from the web more than the desktop app, the automapping behavior you remember from classic Outlook doesn't apply anymore — the table below is the actual difference, not a bug.

One more mix-up worth ruling out before you file a ticket: a shared mailbox and an Outlook Group are two different Microsoft 365 objects that can both show up as a shared identity, and admins occasionally set up the wrong one for the job. A Group is conversation-based and every member gets their own copy of each message; a shared mailbox is one inbox everyone reads from the same copy. If what's missing was actually meant to be a Group, none of the seven causes above apply — ask your admin which object you were actually added to.

What to do when it doesn't work#

If you've checked the web app, confirmed the permission type, and restarted Outlook and the mailbox still isn't there, the remaining causes are all things you can't fix from your own machine.

Ask your admin to run Get-MailboxPermission -Identity <mailbox> | Format-List to confirm the permission actually landed on your account and not on a security group that hasn't finished syncing. In a hybrid environment, ask them to check the Autodiscover and OAuth configuration between on-premises Exchange and Exchange Online — that's the layer that silently blocks reason 6.

It's also worth asking them to check the mailbox's own status in the Exchange admin center — whether it's over its 50 GB unlicensed threshold, disabled, or was recently restored from a soft delete without its permissions reapplied. None of that is visible from your side of the permission, and it produces the exact same symptom as a permission that was never granted.

If you're the admin rather than the person waiting on access, run Get-MailboxPermission -Identity <mailbox> -Owner and confirm the requesting user's UPN matches exactly what you assigned — a permission granted to an old alias or a pre-migration UPN silently fails to apply to the account the person actually signs in with. This is more common than it should be after any tenant rename, domain change, or user-principal-name cleanup, and it produces the same symptom as every other cause on this page: nothing, with no error.

Only after all of those come back clean is a fresh Outlook profile worth building.

A faster way#

Every fix above is a one-time repair for one shared mailbox on one machine. If you're the person who ends up in three or four shared mailboxes — support, sales, a founder's inbox — the same permission and profile friction repeats with every new hire and every new machine.

AI Emaily connects Gmail, Outlook, and IMAP shared mailboxes into one inbox without a client-side profile to keep in sync, so there's no automapping, no Autodiscover cache, and no classic-versus-new-Outlook path to troubleshoot — the connection is server-side. Every AI-drafted reply sent from a shared mailbox is approve-before-send, with undo and an audit trail, so a team can share one inbox without losing track of who did what. We build AI Emaily.