Calling 365 inbox using MS Graph API returns a bare 401 with an empty response body

Thanks Michelle,

1. Test the Application Access Policy immediately I have tested the Access Policy, the AccessCheckResult is Granted
2. Confirm you used the correct ID I have double checked the ID is correct
3. Temporary isolation test I deleted the policy, waited over an hour but still receive a 401 response.
4. While waiting, I ran the sanity checks.

4.1. Group Type: Confirm the group is genuinely a mail-enabled security group

Get-DistributionGroup -Identity "GraphMailIngestionScope" | Select-Object DisplayName, GroupType, RecipientTypeDetails

Returned: GraphMailIngestionScope Universal, SecurityEnabled MailUniversalSecurityGroup

4.2. Group Membership: Verify that ******@company.com is explicitly added as a member of this Mail-enabled Security Group

Get-DistributionGroupMember -Identity "GraphMailIngestionScope" | Select-Object Name, PrimarySmtpAddress, RecipientTypeDetails

Primary SMTP address matched exactly

4.3. Admin Consent: Double-check that Admin Consent for Mail.Read was properly granted specifically for your Managed Identity's Application ID

PS /home/simon> Get-MgServicePrincipal -Filter "appId eq '2dda7...'" | Select-Object Id, DisplayName, AppId

Returned PrincipalId: c6a99... DisplayName: FunctionAppName AppId: 2dda7...

PS /home/simon> Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId "c6a99..." | Select-Object AppRoleId, ResourceDisplayName, PrincipalId

Returned AppRoleId: 810c8... DisplayName: Microsoft Graph PrincipalId: c6a99...

I double checked that the AppRoleID was the Mail.Read

PS /home/simon> $graphSp = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'" -Property "id,appId,appRoles"

PS /home/simon> $graphSp.AppRoles | Where-Object { $_.Id -eq "810c8..." } | Select-Object Value, DisplayName

Returned: Mail.Read Read mail in all mailboxes

Hi @Simon

After researching, please refer below information:

1. List every Application Access Policy (highest priority)

Get-ApplicationAccessPolicy | Format-List *

Share the full output. There may be another policy still targeting this AppId.

2. Test a completely different mailbox

Try the same call against another shared or user mailbox that was never part of any Application Access Policy.

If that also returns bare 401 > the problem is broader (permission grant/identity).

If it succeeds > residual policy/cache affecting only the original mailbox/group.

3. Force a clean permission re-grant

# Remove the existing assignment $sp = Get-MgServicePrincipal -Filter "appId eq '<MI-Client-ID>'" $graphSp = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'" $role = $graphSp.AppRoles | Where-Object { $_.Value -eq "Mail.Read" }
Remove-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -AppRoleAssignmentId <assignment-id>
# Wait 15–30 minutes, then re-assign New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id `   -PrincipalId $sp.Id `   -ResourceId $graphSp.Id `   -AppRoleId $role.Id

Then acquire a brand-new token and re-test.

4. Check for RBAC for Applications (newer model)

Get-ManagementRoleAssignment | Where-Object { $_.Role -like "*Application Mail*" }
Test-ServicePrincipalAuthorization -Identity <MI-Client-ID> -Resource <shared-mailbox>

5. Isolation test with a normal App Registration

Create a temporary App Registration, grant Mail.Read application permission + admin consent, do not create any Application Access Policy, and test the exact same endpoint with a client-credentials token. This quickly tells you whether the issue is specific to the Managed Identity.

Hi @Michelle-N ,

I checked the Access Policy list but it only returns an error, which I assume means there's no policies present.

Get-ApplicationAccessPolicy: ||The operation couldn't be performed because object 'OU=mycompanyname.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=AUSP282A008,DC=PROD,DC=OUTLOOK,DC=COM\*' couldn't be found on 'SY7P282A08DC001.AUSP282A008.PROD.OUTLOOK.COM'.

I checked against another email account, but still received a 401 response.
I removed the assignment, waited and then re-applied, but no change.
But something odd came up for your 4th point. I can see the AppRoleAssignment

Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId "c6a99..." | Select-Object AppRoleId, ResourceDisplayName, PrincipalId
AppRoleId  ResourceDisplayName PrincipalId
---------  ------------------- -----------
810c8...   Microsoft Graph     c6a99...

But if I check the service principal authorization:

Test-ServicePrincipalAuthorization -Identity "c6a99..." -Resource "******@mycompanyname.com"
Test-ServicePrincipalAuthorization: ||The operation couldn't be performed because object 'c6a99...' couldn't be found on 'MEWP282A08DC001.AUSP282A008.PROD.OUTLOOK.COM'.

Hi @Simon Based on your latest results, there are two important points to separate:Your Microsoft Graph app role assignment appears to exist in Microsoft Entra ID, because Get-MgServicePrincipalAppRoleAssignment shows the Mail.Read application role assigned to the managed identity service principal. However, Test-ServicePrincipalAuthorization is not testing the same thing as the Microsoft Entra app role assignment. Per Exchange Online documentation, this cmdlet is used to test access granted by RBAC** for **Applications in Exchange Online, and the RBAC for Applications documentation notes that these grants are independent of unscoped grants in Microsoft Entra ID. The same documentation also says that the testing method excludes permissions granted separately in Microsoft Entra ID. So the error from:

Test-ServicePrincipalAuthorization -Identity "c6a99..." -Resource "******@mycompanyname.com"

does not necessarily mean the Microsoft Graph Mail.Read app role assignment is missing. It may simply mean Exchange Online cannot find a corresponding Exchange RBAC service principal object/assignment for that identity.

For RBAC for Applications, Exchange Online expects a service principal pointer to the existing Microsoft Entra service principal, created with both the Entra application/client ID and the Entra service principal object ID, for example:

New-ServicePrincipal `
 -AppId "<managed-identity-client-id>" `
 -ObjectId "<managed-identity-service-principal-object-id>" `
 -DisplayName "FunctionAppName"

The Exchange RBAC documentation specifically describes this as creating a pointer to an existing Microsoft Entra service principal, and then assigning an Exchange application role, such as Application`` ``Mail.Read, through New-ManagementRoleAssignment.

If you are not intentionally using the newer RBAC for Applications model, then I would not treat the Test-ServicePrincipalAuthorization failure as the primary indicator. In that case, the more relevant check is still Test-ApplicationAccessPolicy, because Application Access Policies and RBAC for Applications are two different scoping mechanisms.

Also, the Get-ApplicationAccessPolicy output you shared may not definitively confirm that no policies exist. If there are truly no application access policies, I would expect the command to return no policy objects rather than an object lookup error. Please try running it exactly without any wildcard or additional identity value:

Get-ApplicationAccessPolicy

or:

Get-ApplicationAccessPolicy | Format-List AppId,PolicyScopeGroupId,AccessRight,Description

At this stage, I would suggest checking the following:

# 1. Confirm whether Exchange can see an RBAC service principal pointer
Get-ServicePrincipal | Where-Object {
 $_.AppId -eq "<managed-identity-client-id>" -or
 $_.ObjectId -eq "<managed-identity-service-principal-object-id>"
} | Format-List DisplayName,AppId,ObjectId,ServiceId

If nothing is returned, then Test-ServicePrincipalAuthorization would be expected to fail, because Exchange RBAC for Applications has no Exchange-side service principal object to evaluate.

# 2. Confirm whether any Exchange application RBAC assignments exist
Get-ManagementRoleAssignment | Where-Object {
 $_.Role -like "Application Mail*"
} | Format-List Name,Role,RoleAssigneeName,CustomResourceScope,RecipientAdministrativeUnitScope

If you want to use RBAC for Applications instead of Application Access Policies, you would need to create the Exchange service principal pointer, define the mailbox scope, and create the Application`` ``Mail.Read role assignment before Test-ServicePrincipalAuthorization can return meaningful results.

If you are using Application Access Policies only, please also re-run:

Test-ApplicationAccessPolicy `
 -Identity "******@mycompanyname.com" `
 -AppId "<managed-identity-client-id>"

Please make sure the AppId here is the managed identity client/application ID, not the service principal object ID.

Hi @Simon

Is there any update from you?

If yes, please feel free to let me know.