Limit which mailboxes an app can send as
How to use RBAC for Applications in Exchange Online so an app that holds the Mail.Send application permission can send only as the mailboxes you choose, with the PowerShell steps in order and how to test them.
Some apps connect to Microsoft 365 with an application permission rather than a person's sign-in. Microsoft describes the Mail.Send application role as: "Allows the app to send mail as any user without a signed-in user." If you approve that for the whole organisation, the app can send as every mailbox you have. RBAC for Applications in Exchange Online lets you give the same permission for chosen mailboxes only.
This applies only to an app that uses an application permission. An app where each person signs in and connects their own mailbox uses a delegated permission and can only send as that person. The guide for each app says which kind it documents. Approve an app's access in Microsoft 365
Footer365 is not involved. It signs the mail that leaves the chosen mailboxes in the same way as any other mail from them.
What you need
- To be in the Organization Management role group in Exchange Online, or to have been given the delegating role assignments for the application roles. In Microsoft Entra ID you need the Exchange Administrator role.
- The app's identifiers from Enterprise applications, not from App registrations. Microsoft says: "Don't use the IDs from the App Registrations page, as it shows different values." You need the Application ID and the Object ID that Enterprise applications shows.
- The Exchange Online PowerShell module, connected with
Connect-ExchangeOnline.
The steps
Create a scope, if you want one. A management scope is a set of mailboxes picked by a filter on their properties. Microsoft's example selects mailboxes by a custom attribute:
New-ManagementScope -Name "CRM mailboxes" -RecipientRestrictionFilter "CustomAttribute1 -eq 'crm'"Microsoft lists the properties a filter can use on its recipient filter properties page. You can use an administrative unit instead, with the role assignment's own parameter for it.
Point Exchange at the app, using the two identifiers:
New-ServicePrincipal -AppId <Application ID> -ObjectId <Object ID> -DisplayName "Name of the app"Give the app the role for that scope:
New-ManagementRoleAssignment -App <Object ID> -Role "Application Mail.Send" -CustomResourceScope "CRM mailboxes"Remove the organisation-wide permission in Microsoft Entra ID. This step matters. Microsoft says: "The permissions assigned using Application RBAC act in addition to grants you make in Microsoft Entra ID." If the app still holds
Mail.Sendfor the whole organisation there, the two add together and nothing is limited. Remove it from the app's Permissions page. Approve an app's access in Microsoft 365Test it, with one mailbox in the scope and one outside it:
Test-ServicePrincipalAuthorization -Identity <Object ID> -Resource <mailbox address>InScopeisTruefor a mailbox the app may send as andFalsefor one it may not. Microsoft says this test leaves out permissions granted separately in Microsoft Entra ID.
Microsoft says changes are subject to a cache that varies between 30 minutes and 2 hours, depending on how recently the app was used, so a change may take that long to show in the app. The test command bypasses the cache.
Limits Microsoft documents
- Microsoft says "Exclusive management scopes don't restrict app access."
- RBAC for Applications supports Microsoft Graph and Exchange Web Services. Microsoft's table lists
Application SMTP.SendAsAppas the role for apps that use SMTP client submission. - It replaces Application Access Policies. Microsoft's page describes how to move from one to the other without interrupting the app.
Sources
- Microsoft: Role Based Access Control for Applications in Exchange Online, page dated 25 November 2025 and updated 21 August 2026, read on 23 October 2026.
Still stuck?
Tell us what you were trying to do and what you saw. Include the sender, a recipient and roughly when a message was sent, and we can trace it.