Get Mailbox Permissions: Exchange Online & On-Prem

boosting security with RBAC and a practical IT security risk assessment.

Why Clean Mailbox Permissions Matter

You pull mailbox permissions for a termination review, export the results, and the list looks busy enough to pass as complete. Then someone asks the only question that matters. Who has deliberate access to this mailbox right now? A raw dump usually does not answer that cleanly.

Microsoft documents the delegation model in Exchange Online, but audit work breaks down when admins treat command output as a finished report. Default and inherited entries such as NT AUTHORITY\SELF, Null SID, and inherited grants can crowd the results and make routine Exchange behavior look like a risky exception. Microsoft calls out that filtering in its recipient permission management guidance.

The practical difference is simple. Raw output shows everything the cmdlet returns. An audit report shows what another team can act on. That usually means separating direct assignments from inherited ones, stripping obvious defaults, and labeling the access in plain language so HR, compliance, or your security lead do not have to interpret Exchange internals.

I have seen cleanups like this prevent two common mistakes. First, teams escalate harmless entries because the report was never filtered. Second, they miss a real delegated grant because it was buried under noise. Both problems waste time, and both are avoidable.

Practical rule: If the output cannot answer "who deliberately has access right now," it is not an audit report yet.

Mailbox permission reviews also make more sense when you connect them to the rest of your access model. If you are tightening delegation controls, pair the mailbox audit with boosting security with RBAC and a practical IT security risk assessment process. That gives you context for whether an entry is expected, excessive, or stale.

Using PowerShell for Targeted Permission Checks

A targeted check usually starts the same way. Someone says a manager can open a shared mailbox, send mail from it, or read a former employee's inbox, and they need an answer now. The first pass is easy. The useful part is stripping the output down to entries a human can review without guessing what Exchange added by default.

When I need that answer quickly, I start with PowerShell. Get-MailboxPermission is the standard cmdlet for mailbox-level delegation in both on-premises Exchange and Exchange Online, and Microsoft points Exchange Online admins to Get-EXOMailboxPermission in its cmdlet documentation.

Check one mailbox

Start with the mailbox itself:

Get-MailboxPermission -Identity Room222

If you need the ownership view, use:

Get-MailboxPermission -Identity Room222 -Owner

That gives you the raw permission set. For a quick audit, focus on User, AccessRights, Deny, and IsInherited. User shows who the entry applies to. AccessRights shows the mailbox-level permission. IsInherited helps separate direct grants from inherited entries. Deny matters because a deny entry can explain why access does not match what the allow entries suggest.

For a cleaner result, filter before you start reading:

Get-MailboxPermission -Identity Room222 | Where-Object { $_.IsInherited -eq $false -and $_.User -ne "NT AUTHORITY\SELF" }

That one filter removes a lot of noise. In practice, NT AUTHORITY\SELF is usually expected system behavior, not delegated access someone granted on purpose.

Check one user

The -User parameter is the faster route during offboarding or access review work:

Get-MailboxPermission -User [email protected]

This answers a different question. Instead of "who can access this mailbox," it answers "where does this person have mailbox-level rights." That distinction matters during incident response and termination checks because it lets you trace a user's footprint without querying mailboxes one by one.

You will still need to clean the results. A raw dump is useful for troubleshooting. An actionable review usually means filtering inherited entries, ignoring obvious defaults, and then checking whether the remaining assignments are still justified. If you want a quick refresher on inspecting object properties before writing filters, this Get-Member PowerShell guide is a practical reference.

A quick walkthrough helps if you want to see the command flow in action:

For troubleshooting, raw output is acceptable. For review or signoff, filter it until the list shows only access that someone likely assigned intentionally.

Creating Bulk Reports for Tenant-Wide Audits

An audit request usually starts the same way. Someone wants “all mailbox permissions” by end of day, and the first export you pull is full of inherited entries, default principals, and permission types that do not belong in the same report. The hard part is not getting data out of Exchange. The hard part is turning that dump into something an auditor, manager, or security lead can review without misreading it.

Microsoft community guidance makes one point that saves a lot of rework. Full Access, Send As, and Send on Behalf are different permission paths, so a tenant-wide audit needs separate queries if you want the report to be complete, as discussed in this Exchange permissions discussion.

A cleaner reporting pattern

For Full Access reviews, start with user mailboxes only and strip out the noise before you export anything:

Get-Mailbox -ResultSize Unlimited -Filter ('RecipientTypeDetails -eq "UserMailbox"') | ForEach-Object { Get-MailboxPermission -Identity $_.Identity | Where-Object { $_.IsInherited -eq $false -and $_.User -ne "NT AUTHORITY\SELF" } }

That filter changes the report from a technical dump into an audit list someone can act on. NT AUTHORITY\SELF is expected in many cases. Inherited entries are usually defaults, not deliberate delegation. Leaving both in the output makes access look broader than it is and sends reviewers chasing harmless entries.

Export after the cleanup step, not before. If you need a quick pattern for formatting the final file, use this guide on exporting PowerShell results to CSV.

Permission types are separate report sets

Bad audits usually fail here. An admin runs one command, labels the file “mailbox permissions,” and assumes it covers everything.

Ask one question before you build the report. Does the request mean mailbox access, sending rights, or both?

That small clarification prevents the usual mistake. Full Access does not imply Send As. Send As does not show up in Get-MailboxPermission. Send on Behalf lives on the mailbox object, so it needs its own pass. If you mix all three without labeling them clearly, the final report will confuse whoever signs off on it.

Folder access needs its own audit path

Mailbox-level permissions are only part of the picture. Folder permissions often explain why a user can open a calendar or inbox folder even when they do not have Full Access on the mailbox.

The practical method is to enumerate folders with Get-MailboxFolderStatistics and then query permissions with Get-MailboxFolderPermission. Third-party admin guidance also calls out useful filters such as -FoldersUserCanAccess, -AccessRights Owner, -UserMailboxOnly, and -SharedMailboxOnly in this mailbox folder permission guide.

For tenant-wide audits, keep mailbox permissions and folder permissions in separate outputs. Combining them into one flat file looks tidy, but it usually creates more follow-up work because reviewers cannot tell whether access applies to the whole mailbox or just one folder.

Finding Permissions with GUI and Graph API

A help desk ticket lands saying, "Who can access the CEO mailbox right now?" For that kind of one-mailbox check, the Exchange Admin Center is faster than opening a shell. Open the mailbox, go to Mailbox delegation, and review Full Access, Send As, and Send on Behalf.

The GUI is good for verification. It is weak for auditing. You cannot cleanly compare many mailboxes, strip out default entries, or hand a reviewer a report that clearly shows what needs action.

Graph API can help if your team already builds Microsoft 365 automation around app authentication, scheduled jobs, or service-to-service workflows. It fits best when mailbox access checks are one part of a larger control set, such as identity reviews or protecting business email. For architecture planning around those broader automations, keep this reference on enterprise integration patterns for Microsoft 365 workflows handy.

The practical trade-off is simple. The GUI answers "what does this mailbox look like right now." PowerShell and Graph are what you use when the main job is producing a clean report instead of a raw dump.

That distinction matters. A raw export full of inherited entries, system principals, and unlabeled permission types creates more review work than it saves. A useful audit report groups rights clearly, removes noise such as NT AUTHORITY\SELF where appropriate, and leaves you with a list someone can approve, revoke, or investigate.

Avoiding Common Pitfalls and Fixing Mistakes

The biggest mistakes are usually operational, not technical. Admins mix up mailbox-level and folder-level permissions, forget that send-related rights live elsewhere, or bulk-assign Full Access without thinking about what Outlook will do next.

One control point deserves extra attention. When you grant broad mailbox access, -AutoMapping:$false keeps Outlook from automatically adding every permitted mailbox to the user profile. The same admin guidance also points out that if you need to reverse course, the safe rollback is Remove-MailboxPermission, not manual cleanup of mappings, as shown in this bulk permission administration walkthrough.

If users complain that Outlook suddenly filled up with extra mailboxes, check whether AutoMapping was left at its default behavior. If your audit looks complete but misses Calendar or Inbox delegate access, you probably checked mailbox permissions and forgot folder permissions. If a script throws odd access or scope errors, review your admin rights and the mailbox set you targeted before blaming the cmdlet. This troubleshooting note on a referral was returned from the server is also worth keeping in your back pocket for Exchange-related friction.

For teams tightening access hygiene, mailbox auditing should sit beside broader habits for protecting business email. Permissions are only one part of the blast radius.

Related articles

• IT security risk assessment
• Get-Member in PowerShell
• Export to CSV with PowerShell
• Enterprise integration patterns

---

If you're cleaning up admin workflows beyond Exchange, Server Scheduler helps teams automate repetitive infrastructure operations with a simple visual schedule instead of scripts and manual runbooks.