Exchange Online Application RBAC (Application Mail.Send) is not enforced for Azure Automation Managed Identity when using Microsoft Graph Mail.Send

Question

Exchange Online Application RBAC (Application Mail.Send) is not enforced for Azure Automation Managed Identity when using Microsoft Graph Mail.Send

Dey, Dipronil 0

Issue Summary

I have configured Exchange Online Application RBAC to restrict an Azure Automation System Assigned Managed Identity so that it can send emails only from a single mailbox.

Although the RBAC configuration is successfully created and Test-ServicePrincipalAuthorization confirms that another mailbox is outside the allowed scope, the managed identity can still successfully send email from that mailbox using Microsoft Graph.

I would like Microsoft to investigate why the Application RBAC restriction is not being enforced.

Environment

Azure Automation Account

System Assigned Managed Identity

Microsoft Graph PowerShell SDK

Exchange Online Application RBAC

Microsoft Graph Mail.Send (Application)

Managed Identity Details:

Display Name: SAML-Automation

App (Client) ID: [Moderator note: personal info removed]

Object ID: [Moderator note: personal info removed]

Purpose of the Automation

The Azure Automation runbook automates Microsoft Entra ID SAML Enterprise Application onboarding.

The runbook:

Creates the Entra ID Application

Creates the Enterprise Application

Configures SAML

Sends a notification email to the application owner using Microsoft Graph

The automation authenticates using:

Connect-MgGraph

The managed identity has only the following Microsoft Graph Application permissions:

Mail.Send

Application.ReadWrite.OwnedBy

Sites.Selected

Configuration Performed

1. Created a custom Exchange Management Scope

New-ManagementScope

-Name

-RecipientRestrictionFilter

2. Assigned Application Mail.Send to the Managed Identity

New-ManagementRoleAssignment

-Name

-App

-Role

-CustomResourceScope

3. Verified the assignment

Verified using:

Get-ManagementRoleAssignment

The assignment is:

Enabled = True

Role = Application Mail.Send

CustomResourceScope = BotMailboxScope

RoleAssigneeType = ServicePrincipal

4. Verified authorization

Allowed mailbox:

Test-ServicePrincipalAuthorization

-Identity

-Resource

Result:

InScope = True

Mailbox outside the scope:

Test-ServicePrincipalAuthorization

-Identity

-Resource

Result:

InScope = False

This confirms Exchange recognizes that TestUser01 is outside the allowed scope.

Testing Performed

The Automation Account authenticates using:

Connect-MgGraph

Verified using:

Get-MgContext

The authenticated identity is:

App Name: SAML-Automation

Client ID: [Moderator note: personal info removed]

Auth Type: ManagedIdentity

Email was sent using both methods:

Send-MgUserMail

and

Invoke-MgGraphRequest

Example:

Invoke-MgGraphRequest

-Method

-Uri

Both methods successfully send the email.

Expected Result

Since

Test-ServicePrincipalAuthorization

returns

InScope = False

for

[Moderator note: personal info removed].onmicrosoft.com

the Graph API should reject the request with a 403 Forbidden (or similar authorization error).

The managed identity should only be able to send mail as:

[Moderator note: personal info removed].onmicrosoft.com

Actual Result

The email is successfully sent from:

From:

even though Exchange reports that the mailbox is outside the allowed RBAC scope.

Additional Information

Verified:

Management Scope exists.

Application Mail.Send role assignment exists.

Managed Identity is the correct service principal.

Graph permissions are limited to:

Mail.Send

  Application.ReadWrite.OwnedBy

  
     Sites.Selected
```Organization configuration shows:


```sql
EnforceExoAppRbacPermissions = False

I am unsure whether this value is expected, whether it should be enabled, or whether it is related to this behavior.

Request

Please help verify:

Whether the Exchange Online Application RBAC configuration has been implemented correctly.

Whether EnforceExoAppRbacPermissions should be enabled and, if so, how it can be enabled.

Why Test-ServicePrincipalAuthorization correctly reports the mailbox as out of scope, while Microsoft Graph still allows Mail.Send from that mailbox.

Whether this is a known limitation, configuration issue, or product issue.

If additional configuration is required for Exchange Online Application RBAC to be enforced for Microsoft Graph Mail.Send when using an Azure Automation Managed Identity.

This version is structured the way Microsoft Support engineers typically prefer: Issue → Environment → Configuration → Validation → Expected vs Actual → Questions, making it easier for them to reproduce and investigate.

0 comments

2 answers

Your answer

Answer 1

Please note that Q&A forum is a public platform, and moderators will modify the question to hide personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

Hi @Dey, Dipronil

Based on the current Microsoft documentation, this behavior is most likely caused by the managed identity still having the tenant-wide Microsoft Graph Mail.Send application permission granted in Microsoft Entra ID.

Exchange Online Application RBAC and Microsoft Entra application permissions are separate authorization grants. The Exchange RBAC assignment can be scoped to a mailbox or management scope, but if the same service principal also has an unscoped Mail.Send application permission in Microsoft Entra ID, that permission can still allow the app to send as mailboxes outside the Exchange RBAC scope.

This explains why Test-ServicePrincipalAuthorization returns InScope`` ``=`` ``False for TestUser01, while Microsoft Graph Send-MgUserMail or Invoke-MgGraphRequest still succeeds. The test validates the Exchange RBAC assignment, but the Graph call can still be authorized through the unscoped Microsoft Entra Mail.Send permission.

To validate this, I would recommend checking whether the service principal still has Microsoft Graph Mail.Send application permission granted in Microsoft Entra ID. If the goal is to rely on Exchange Online Application RBAC for mailbox-scoped access, remove the tenant-wide Entra Mail.Send grant and keep the scoped Exchange Online Application`` ``Mail.Send role assignment.

If the behavior continues after removing the unscoped Entra Mail.Send permission and allowing configuration/token changes to take effect, then it would be reasonable to open a Microsoft Support case through M365 Admin Center with the following evidence:

Managed identity App ID and Object ID
Get-ManagementRoleAssignment output
Get-ManagementScope output
Test-ServicePrincipalAuthorization result for both the allowed mailbox and blocked mailbox
Current Graph API permissions granted to the service principal
The exact Graph request URI used for /users/{sender}/sendMail
The result showing that the blocked mailbox can still send successfully

Thank you for your patience.

If the answer is helpful, please click "Yes" and kindly upvote it. If you have extra questions about this answer, please click ""Comment"".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Michelle-N 20,645 Reputation points Microsoft External Staff Moderator

2026-07-21T13:04:49.9466667+00:00

Hi @Dey, Dipronil

Is there any update from you?

If yes, please feel free to let me know.

Answer 2

Shay Stevens 0

Hey @Michelle-N ,

When you say "remove the tenant-wide Entra Mail.Send grant", do you mean:

Removing the admin consent that was granted to the Entra app's Microsoft Graph Mail.Send permission, while leaving the permission configured on the app registration; or
Removing the Mail.Send permission entirely from the Entra app registration?

Also, is Exchange RBAC managed completely separate from Entra permissions, or are they linked in this scenario?

Michelle-N 20,645 Reputation points Microsoft External Staff Moderator

2026-07-22T11:59:24.7066667+00:00

Hi @Shay Stevens

Thanks for checking. I mean option 1: revoke the tenant-wide admin consent for the Microsoft Graph Mail.Send application permission in Microsoft Entra ID. The goal is to remove the unscoped Entra grant so the app is not authorized tenant-wide through Graph consent.

You do not necessarily have to delete the Mail.Send permission line from the app registration, but removing it can help avoid accidental re-consent later. The important part is that the service principal should not retain an organization-wide Microsoft Graph Mail.Send grant if you expect Exchange Online Application RBAC to enforce a scoped Application Mail.Send assignment.

Exchange RBAC and Entra permissions are separate authorization mechanisms. Exchange RBAC uses the Entra service principal as the identity reference, but the Exchange RBAC role assignment and scope are managed in Exchange Online. These permissions are additive, so if the app has both an unscoped Entra Mail.Send grant and a scoped Exchange RBAC Application Mail.Send assignment, the unscoped Entra grant may still allow broader access.