Deleted Users Can Leave Send As Permissions Behind in Exchange Online — How to Audit Shared Mailboxes

Why deletion doesn't clean up delegation

A shared mailbox permission — Full Access, Send As, or Send on Behalf — is a reference to a security principal, not a live link to an account. When Active Directory or Entra ID deletes the user behind that reference, Exchange Online doesn't go back and remove the permission entry. It's a separate object in a separate system, and nothing automatically connects the two deletion paths.

Full Access, Send As and Send on Behalf are three separate grants, assigned and read independently:

• Full Access — lets a delegate open and act inside the mailbox as if it were their own, including reading and sending mail when AutoMapping or a manually added folder makes it visible.
• Send As — lets a delegate send mail that appears to come directly from the shared mailbox address, with no "on behalf of" header.
• Send on Behalf — lets a delegate send mail that shows both their name and the mailbox address, so recipients can see who actually sent it.

A delegate can hold any combination of the three, and each is a separate entry that can independently outlive the account it was granted to.

What an orphaned entry looks like

Administrators consistently report the same symptom after an account is deleted: the delegation entry doesn't disappear from Exchange Online, and it doesn't fail cleanly either. Instead of a display name or an email address, the trustee shows up as a raw security identifier:

Offboarded user
S-1-5-21-... → Send As → [email protected]
Orphaned delegate detected

This is a commonly observed Exchange Online behavior, not something Microsoft's official documentation states as a guaranteed contract — treat it as "expect to see this," not as a documented promise about exactly which permission types can or can't end up this way. Don't assume Full Access is somehow immune while only Send As orphans; either type can leave a stale entry once the underlying account is gone.

No automatic cleanup mechanism removes these entries. They stay until an administrator finds and removes them explicitly.

Reading current delegation with PowerShell

The current, supported cmdlets for reading each permission type are Get-EXOMailboxPermission (Full Access), Get-EXORecipientPermission (Send As), and the mailbox's own GrantSendOnBehalfTo property, read viaGet-Mailbox or Get-EXOMailbox, for Send on Behalf. Each trustee returned can then be resolved against Get-EXORecipient — a trustee that fails to resolve is the signal to investigate.

For a single mailbox, the free Permission Audit Generator builds this exact read-only script for you — enter one mailbox address and get a script that checks all three permission types and flags unresolved trustees, without sending anything to Tenvero.

Verify before removing anything

An unresolved SID is a strong signal, not proof by itself. Before removing it, confirm it actually belongs to a deleted account rather than, for example, a cross-tenant or recently-migrated identity that hasn't finished resolving. Cross-check the SID against a recently-deleted-users export, then remove the specific entry:

Remove-RecipientPermission -Identity [email protected] `
  -Trustee S-1-5-21-... -AccessRights SendAs -Confirm:$false

Remove the specific trustee and permission type — never bulk-clear a mailbox's delegation because one entry looks stale. The other delegates on that mailbox are unrelated.

Recurring audit vs. one-time cleanup

Cleaning up the orphaned entries you find today doesn't stop new ones from appearing. Every offboarding that doesn't check shared mailbox delegation as part of the process creates the same problem again later. A permission audit that only runs once — during a compliance review, or after this article prompts a one-time cleanup — finds whatever accumulated since the last time, then goes stale again immediately.

Cleaning this once is PowerShell. Keeping actual delegation aligned with intended access is reconciliation.