Exchange Online: Restrict Application Access to a Single Mailbox

Technical review: 26 October 2026. Product names, licensing references and procedures reflect this review; check the linked documentation for your release.

A service that only needs one mailbox should not quietly receive tenant-wide mail access. Exchange Online RBAC for Applications supports resource-scoped application permissions. Designing that scope requires attention to every grant the application holds, because adding a restricted assignment does not automatically cancel an existing broad permission.

Define the operations and the mailbox set

Write down whether the application needs to send, read, modify mail or access calendars. These are different capabilities. Use a dedicated application identity where the integration boundary warrants it, and identify its Entra application client ID and service principal object ID correctly.

Define the target mailbox set using the supported management-scope or administrative-unit approach. A scope can identify one mailbox, but its filter must be validated against actual recipients. Similar display names or a changing department attribute are not a reliable one-mailbox boundary without review.

Use the current application RBAC model

Microsoft documents RBAC for Applications as the replacement for Application Access Policies. Follow the current Exchange Online procedure to create the service-principal pointer, choose an application role and bind it to the intended resource scope. Use the Entra Enterprise Application’s service principal object ID where that step requires it, not the app registration object ID.

This article deliberately focuses on the design and verification rather than a universal tenant-changing command. The exact role and scope depend on the requested operation and the organization’s Exchange administration model. Save the previous assignment inventory before making an approved change.

Find overlapping grants

Exchange application RBAC permissions and applicable Entra application permissions can be additive. A narrow Exchange role assignment does not neutralize an unscoped Entra mail or calendar grant. Inventory both systems and understand the effective permission path before declaring the application restricted.

Remove or migrate overlapping broad grants only through the approved change process, after confirming that no other workflow depends on them. Review each capability separately: successfully restricting mail access does not prove a calendar permission is scoped, or vice versa.

Test a positive and a negative case

Use Exchange’s supported authorization test for the application and a target mailbox. For example, after replacing the placeholders with approved non-secret identifiers:

Test-ServicePrincipalAuthorization -Identity '<service-principal-identity>' -Resource 'mailbox@example.com'

Run the check for both an intended mailbox and one outside the scope. Then test the real API operation with the application’s token, because the authorization test does not by itself evaluate every independent Entra grant. Allow for documented caching and propagation rather than repeatedly changing scope filters.

• Confirm the intended read/send/calendar action succeeds only where approved.
• Confirm an out-of-scope mailbox is denied using the same application identity.
• Keep tokens, message bodies and recipient details out of shared evidence.
• Record scope membership, role assignments, removed overlap and rollback decisions.

The acceptance result should state the operation and boundary that were actually tested. “The app can send mail” is a functionality check; “the app cannot send as another mailbox” is the security check that completes it.

References

• Microsoft: Exchange Online RBAC for Applications
• Microsoft: Test-ServicePrincipalAuthorization
• Microsoft: Exchange management scopes