Shared Mailbox Not Showing in Outlook: Why It Happens and How to Fix It (2026 Updated Guide)

Quick answer

If a shared mailbox isn’t appearing in classic Outlook, the cause is usually one of three things: AutoMapping is off, Full Access permission was granted via a security group instead of directly to the user, or it just hasn’t propagated yet (Autodiscover can take 30 minutes). Check whether the mailbox shows up in Outlook on the web first — if it does there but not in classic Outlook, that diagnostic alone tells you exactly which fix you need.

Before you start

  • Confirm the user actually has access. The fastest way: have them sign in to outlook.office.com and look for the shared mailbox in the folder pane there. If it’s missing from the web too, the permission isn’t assigned yet — fix that first before troubleshooting Outlook.
  • Identify which Outlook the user is in. Classic Outlook for Windows, new Outlook for Windows, and Outlook on the web all behave differently with shared mailboxes. The fix depends on which one is failing.
  • Time matters. Newly-assigned permissions take up to 30 minutes — sometimes a few hours — to propagate via Autodiscover. If the permission was granted in the last hour and the user is in classic Outlook, just wait and restart Outlook before going further.
  • You may need admin access to fix this properly. The most reliable fix involves a PowerShell command that requires Exchange Online admin or Global Admin rights. If you don’t have that, identify the cause first, then escalate to whoever does.

What this means

When a Microsoft 365 admin grants Full Access permission to a shared mailbox, two things have to happen for the mailbox to appear automatically in classic Outlook:

  1. The permission has to be assigned with AutoMapping enabled (the default in the admin center, but optional in PowerShell).
  2. The Autodiscover service has to propagate that permission to the user’s Outlook profile, which can take up to 30 minutes.

Classic Outlook reads its list of “extra” mailboxes to display from Autodiscover. AutoMapping is the flag that tells Autodiscover to include this mailbox in that list. If the flag isn’t set — or if the permission was granted to a security group the user belongs to rather than directly to the user — AutoMapping silently fails. The mailbox is accessible (the user has permission) but it doesn’t appear automatically.

This is why the same shared mailbox can be visible in Outlook on the web and new Outlook for Windows but missing from classic Outlook on the same device with the same account. The web client and new Outlook query the user’s permissions directly. Classic Outlook depends on AutoMapping. Different mechanisms; different failure modes.

Where this error appears

SurfaceMailbox visible?What it tells you
Classic OutlookMissingCould be any cause — work the full sequence
New Outlook for WindowsMissingPermission probably isn’t assigned at all
Outlook on the web (outlook.office.com)MissingPermission isn’t assigned, or hasn’t propagated
Classic Outlook missing, web works—AutoMapping issue or Autodiscover delay
Classic + new Outlook missing, web works—Cached profile issue on the device
Missing on every surface—Permission isn’t actually assigned

The web vs classic Outlook split is the most useful diagnostic. Use it.

Common causes

  • AutoMapping wasn’t set to true. When permissions are added via PowerShell, the -AutoMapping parameter has to be explicitly set to $true. The Microsoft 365 admin center sets it automatically, but many admins script their permissions via PowerShell and forget the switch.
  • Full Access was granted to a security group, not the user directly. Group-based permissions don’t propagate AutoMapping reliably to classic Outlook. The user has access (they can add the mailbox manually) but it doesn’t auto-appear.
  • Autodiscover hasn’t propagated yet. Up to 30 minutes for new permissions, occasionally longer. A simple wait-and-restart resolves this case.
  • Cached Outlook profile is stale. The profile is holding an old version of Autodiscover’s response. A profile rebuild fixes this.
  • The mailbox is hidden from the address list. A shared mailbox set to “hidden from address lists” in Exchange properties may not appear via AutoMapping even with permission set.
  • Classic Outlook is in cached mode and the OST is stuck. Rare but real — the OST can fail to download the shared mailbox folders even after AutoMapping succeeded.
  • Wrong Outlook profile is loading. The user may have multiple profiles configured and the wrong one is starting Outlook by default.

Fixes to try first

1. Verify the user can see the mailbox in Outlook on the web

Have the user navigate to outlook.office.com and sign in. In the folder pane, scroll down. The shared mailbox should be listed. If it’s not, also try right-clicking the user’s own folders and choosing Add shared folder or mailbox, then typing the shared mailbox address.

If it doesn’t appear on the web either, the permission isn’t assigned (or the user is signing in with the wrong account). Stop here and verify the permission in the admin center.

2. Wait, then restart Outlook

If the permission was granted in the last hour, AutoMapping may still be propagating. Wait at least 30 minutes from the time of permission assignment. Then close classic Outlook completely (verify in Task Manager — OUTLOOK.EXE shouldn’t be running) and reopen it.

About a quarter of “shared mailbox not showing” tickets we see are exactly this: a recently-granted permission that just needed time. It’s worth the patience.

3. Re-grant Full Access with AutoMapping explicitly enabled

This is the fix that resolves the largest share of stubborn cases. It requires admin access via PowerShell.

Connect to Exchange Online PowerShell. Then remove the existing permission and re-add it with -AutoMapping $true:

# Remove existing Full Access permission
Remove-MailboxPermission -Identity "shared@contoso.com" -User "alice@contoso.com" -AccessRights FullAccess

# Re-add with AutoMapping enabled
Add-MailboxPermission -Identity "shared@contoso.com" -User "alice@contoso.com" -AccessRights FullAccess -AutoMapping $true

Replace the email addresses with the actual values. Wait 15–30 minutes after running. Have the user close and reopen Outlook.

If the permission was originally granted to a security group, this step also fixes it — by switching to a direct user assignment which AutoMapping handles correctly.

4. Add the shared mailbox manually as a fallback

If AutoMapping continues to fail and you need access right now, add the mailbox manually in classic Outlook:

  1. File → Account Settings → Account Settings.
  2. Select your primary email account, click Change.
  3. Click More Settings → Advanced tab.
  4. Click Add, type the shared mailbox email address, and click OK.
  5. OK → Next → Finish → Close.

The mailbox should appear in the folder pane after a few seconds.

This works without AutoMapping but it’s a manual step — you’ll need to do it on every device the user has. Use it as a workaround while you fix the AutoMapping properly.

5. Toggle Cached Exchange Mode

Open Account Settings → Account Settings, double-click your primary account, click More Settings → Advanced tab. If Use Cached Exchange Mode is on, also confirm Download shared folders is checked. Save. Restart Outlook.

If the option was off, turning it on will trigger a fresh sync of shared folders, which often pulls in mailboxes that AutoMapping should have shown but didn’t.

Advanced fixes

If the basic fixes haven’t worked, you’re probably looking at a profile-level issue.

Rebuild the Outlook profile

A clean profile is the surgical fix for stubborn cases.

Open Control Panel → Mail → Show Profiles. Click Add, name the new profile, set up the user’s primary account fresh, set Outlook to Always use this profile, and start Outlook with the new profile.

If the new profile shows the shared mailbox correctly, the old profile was the problem. Once confirmed working, delete the old profile.

Force a fresh Autodiscover

A more targeted version of the profile rebuild. Close Outlook completely. Open a Command Prompt and run:

ipconfig /flushdns

Then test Autodiscover by holding Ctrl and right-clicking the Outlook icon in the system tray (Outlook must be running for this), and selecting Test E-mail AutoConfiguration. Uncheck “Use Guessmart” and “Secure Guessmart Authentication,” then click Test. The output shows what Autodiscover is returning — including the mailbox list. If the shared mailbox doesn’t appear in the AutoDiscover XML response, you’ve isolated the cause to the AutoMapping/permission state on the server side.

Check whether the mailbox is hidden from address lists

In Exchange admin center, find the shared mailbox properties. Under General, check whether Hide from global address list is enabled. Some AutoMapping configurations don’t apply correctly to hidden mailboxes. If hidden, temporarily un-hide, restart Outlook, then re-hide if needed. The AutoMapping link survives the un-hide/re-hide cycle.

Check the shared mailbox isn’t deleted or in soft-delete

A long-shot but worth checking if the mailbox previously appeared and recently disappeared. In the Microsoft 365 admin center, Teams & groups → Shared mailboxes — confirm the mailbox is listed and active. If it’s been deleted (intentionally or accidentally), it’s recoverable for 30 days from the admin center.

If you’re the admin fixing this for a small business

The pattern we see most often in small-business tenants is: you grant a shared mailbox to a security group (“Sales”) that the user belongs to, expecting AutoMapping to work the same as a direct grant. It doesn’t reliably work via groups in classic Outlook. The mailbox is accessible (because the group grants permission) but it doesn’t auto-appear (because AutoMapping is unreliable through group inheritance).

The fix: grant Full Access directly to each user who needs the mailbox to appear automatically, instead of via a group. It’s a small operational cost — a handful of users, each with a one-line PowerShell command — but it eliminates the entire class of “the new hire can see Sales in OWA but not in Outlook” tickets.

For broader admin patterns around shared mailboxes, including the related case of SharePoint access denied when the user has permission, and the full new user provisioning checklist, see those guides.

When to stop

Stop and escalate if:

  • The mailbox is missing across web, new Outlook, and classic Outlook on every device. The permission isn’t assigned. There’s nothing the user or device-side troubleshooting can fix — it’s an admin task.
  • You’ve re-granted Full Access with AutoMapping explicitly enabled, waited 30+ minutes, rebuilt the user’s profile, and the mailbox still doesn’t appear in classic Outlook. At that point, you may have a hybrid environment (one mailbox on-premises, one in the cloud) where AutoMapping isn’t fully supported. Escalate to whoever owns the Exchange topology.
  • The user has hundreds of mailboxes mapped via AutoMapping. Classic Outlook has practical limits — performance degrades sharply past 50–100 auto-mapped mailboxes. Consider switching some users to manual mailbox addition or to the new Outlook for Windows, which handles many mailboxes more efficiently.

Official references

FAQ

Why does the shared mailbox show up in Outlook on the web but not in classic Outlook?

Outlook on the web reads permissions directly from Exchange Online. Classic Outlook depends on AutoMapping via Autodiscover, which is a separate path. If the permission is granted but AutoMapping isn’t propagating (commonly because Full Access was assigned via a security group, or because PowerShell didn’t include -AutoMapping $true), the mailbox is accessible but doesn’t appear automatically in classic Outlook. Re-granting the permission directly to the user with AutoMapping explicitly enabled fixes it.

How long should I wait after the admin grants me access before the mailbox appears?

Up to 30 minutes for AutoMapping to propagate, occasionally longer. If it’s been more than two hours and you can see the mailbox in Outlook on the web but not in classic Outlook, the propagation has succeeded but classic Outlook isn’t picking it up — that’s typically a profile cache issue. Closing Outlook, restarting it, or rebuilding the profile fixes it.

Can I add the shared mailbox manually if AutoMapping isn’t working?

Yes — it’s a fine workaround. Account Settings → Change → More Settings → Advanced → Add, type the mailbox address, and it appears in your folder pane. The downside is you have to do it on every device, and if you ever rebuild your profile you’ll have to add it again. AutoMapping does this automatically across devices and rebuilds, which is why it’s worth fixing properly when you can.

My admin says they’ve added the permission three times. Why won’t it work?

The most likely reason is -AutoMapping $true isn’t being included in the PowerShell command. The Microsoft 365 admin center adds it automatically; PowerShell does not. Have the admin run the exact Remove-MailboxPermission then Add-MailboxPermission ... -AutoMapping $true sequence shown above. If it still doesn’t work, the permission may be inherited via a security group, which doesn’t reliably trigger AutoMapping in classic Outlook.

I can see the shared mailbox but I can’t send from it. What’s wrong?

That’s a different permission. Full Access lets you read and manage the mailbox. To send mail as the shared mailbox, you also need Send As or Send on Behalf permission, which is granted separately in the admin center. Both can be enabled for the same user; they just need to be assigned independently.

Will switching to new Outlook for Windows fix this?

Often, yes. New Outlook handles shared mailbox enumeration through a different mechanism that doesn’t rely on AutoMapping. If your mailbox appears in Outlook on the web, it’ll typically appear in new Outlook too — even when classic Outlook is stuck. That’s not a complete answer (some organizations aren’t ready to migrate to new Outlook), but it’s a useful escape hatch when the classic Outlook AutoMapping is being stubborn.

↑ Back to top