Introduction

A Microsoft 365 migration can move the shared mailbox successfully while users suddenly lose access to it. The mailbox may exist and even appear in Outlook, but Full Access, Send As, or Send on Behalf permissions were not carried over cleanly to the destination tenant.

Treat this as a mailbox-permission problem instead of a mailbox-visibility problem. Start by confirming which users or groups should have access on the destination side, then compare that list with the actual permission assignments now in place.

Symptoms

  • Users can no longer open a shared mailbox after migration
  • The shared mailbox appears in Outlook, but access is denied or incomplete
  • Users can read the mailbox but cannot send from it
  • Send As or Send on Behalf stopped working after cutover
  • Only some delegated users lost access while others still work
  • The issue started after Microsoft 365 tenant migration or mailbox move

Common Causes

  • Full Access permissions were not recreated on the destination tenant
  • Send As or Send on Behalf assignments were not migrated
  • Permissions were applied to the wrong user objects after migration
  • Group-based access changed because group membership did not carry over cleanly
  • Outlook still shows stale mailbox state from before the permission change
  • The shared mailbox exists, but the destination tenant permissions were never validated post-move

Step-by-Step Fix

  1. Confirm which users and groups were supposed to have Full Access, Send As, and Send on Behalf permissions before migration, because you need a known-good permission map before comparing the destination state.
  2. Check the current permission assignments on the shared mailbox in Microsoft 365, because the mailbox can migrate successfully while delegate access is left behind.
  3. Compare direct user permissions and group-based permissions separately, because a mailbox that looks correctly assigned may still fail when the underlying group membership changed during migration.
  4. Verify that the affected users exist as the intended destination identities and are not stale source references, because migrated permissions can end up attached to the wrong objects.
  5. Reapply any missing Full Access, Send As, or Send on Behalf assignments on the destination mailbox, because permission recreation is often the real fix after tenant or mailbox migration.
  6. Test mailbox open, read, and send behavior with one affected user after each correction, because access and send permissions can fail independently even on the same shared mailbox.
  7. Refresh Outlook or Outlook on the web after the permission fix and compare results, because client-side cache can make restored access look broken longer than it really is.
  8. Compare one working delegate and one broken delegate on the same shared mailbox if available, because differences in user object mapping or permission scope usually reveal the missed assignment.
  9. Document the final shared mailbox permission set after recovery, because delegate access is often missed during Microsoft 365 migration validation.