Why Shared Mailboxes Keep Appearing in Outlook: Full Access, AutoMapping and Permission Drift

Three separate layers

When a shared mailbox shows up in Outlook, three different things are involved, and they are easy to blur together:

Exchange permission → AutoMapping / discovery → Outlook behavior.

1. Full Access can trigger AutoMapping

When a user is granted Full Access directly with AutoMapping enabled (the default ofAdd-MailboxPermission), Exchange records it so Autodiscover can add the mailbox to that user's Outlook. That is why a user can suddenly see a list of mailboxes: several direct Full Access grants, each AutoMapped.

2. AutoMapping is not synchronization

AutoMapping controls how Exchange makes the mailbox available to Outlook; it is separate from mailbox synchronization and notification behavior. In New Outlook, an auto-mapped shared mailbox may not automatically synchronize incoming mail or notifications. Microsoft's route for automatic synchronization and notifications is to add the shared mailbox as an account, which is a different configuration path and requires Full Access. SeeNew Outlook shared mailboxes explained.

3. Rebuilding the Outlook profile doesn't fix the permission

A common symptom in admin discussions: the mailbox appears in Classic Outlook, may not appear the same way in Outlook on the web, and a fresh profile brings it right back. That is expected. The profile is only where the mailbox is displayed; the reason it appears is a direct Full Access grant, so the fix belongs at the permission layer.

4. Hybrid environments add a wrinkle

Microsoft documents scenarios where unwanted AutoMapping persists after the permission is removed, involving the msExchDelegateListLink attribute in hybrid deployments. If a mailbox keeps appearing after the Full Access grant is gone, look at that attribute rather than the client. Check Microsoft's current documentation for your topology before changing it.

5. The real question: why does this user have Full Access?

Removing a mailbox from one profile treats the symptom. The long-term question is whether the grant is part of your intended access model, for example membership of a security group, or a direct grant somebody added and forgot. Start by listing direct Full Access on shared mailboxes:

Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited |
  Get-MailboxPermission |
  Where-Object { $_.AccessRights -contains 'FullAccess' -and -not $_.IsInherited -and $_.User -ne 'NT AUTHORITY\SELF' } |
  Select-Object Identity, User, AccessRights

Where Tenvero fits

Tenvero does not fix Outlook or AutoMapping itself. It works at the permission layer: it compares the intended group-based delegation with actual Exchange permissions and identifies unexpected direct access. If you need that checked and reconciled continuously instead of rediscovered by hand, that is what a desired-state model is for.