Immediate answer
Authenticate the application, then authorize only the sender it needs.
Exchange Application RBAC can grant an application the Application SMTP.SendAsApp role through a management role assignment paired with a resource scope. The scope defines which Exchange recipients the application is authorized to use.
This model is independent of broad application permissions granted through Microsoft Entra. Microsoft documents App RBAC as the replacement for Application Access Policies and warns that Entra application grants and Exchange RBAC grants are additive. A broad Entra grant can therefore defeat the intended narrow Exchange scope.
Authorization model
Token, protocol, and sender answer different questions.
| Boundary | Question answered | Typical evidence |
|---|---|---|
| Entra application identity | Which software is requesting the token? | Tenant, client ID, service principal, and certificate-backed client assertion |
| Exchange application role | What Exchange operation may the application perform? | Application SMTP.SendAsApp role assignment |
| Resource scope | Which sender mailbox is inside that authority? | Management scope and effective authorization test |
XOAUTH2 transports the resulting OAuth bearer token inside the SMTP authentication exchange. It does not create mailbox permission by itself, and a certificate uploaded to the app registration does not authorize any sender by itself.
Do not mix models
Microsoft documents two app-only authorization patterns.
Application permission plus mailbox permission
The application receives the Exchange Online SMTP.SendAsApp application permission with admin consent, is registered as an Exchange service principal, and receives the required sender mailbox permission.
Exchange Application RBAC
The app is linked into Exchange, receives the Application SMTP.SendAsApp management role, and is constrained by a resource scope. Microsoft's SMTP App RBAC onboarding guidance says not to add the Entra SMTP permission for this model.
Do not assume a narrow RBAC assignment overrides a broad Entra application permission. Review and remove unnecessary grants through controlled change management after confirming the intended model and all consumers.
Identifier discipline
The application ID and service-principal object ID are not interchangeable.
The Entra app registration has an application—or client—ID. The tenant's enterprise application instance has its own service-principal object ID. Exchange's New-ServicePrincipal linkage requires the correct pair. Selecting the object ID from the app-registration object instead of the enterprise application is a common cause of a configuration that looks plausible but cannot authorize SMTP.
- 01
Fix the tenant
Confirm the single tenant in which the app, enterprise application, Exchange organization, and sender mailbox exist.
- 02
Record both identifiers
Keep the application ID and enterprise service-principal object ID labeled separately.
- 03
Create or verify the Exchange reference
Link the Entra application to the Exchange service-principal representation before assigning the role.
Least privilege
Make the intended sender visible in the resource scope.
A custom Exchange management scope can use recipient attributes or group membership to define the mailboxes an application may use. Pair that scope with exactly the application role needed for SMTP submission, then test both an intended mailbox and a mailbox that must remain outside the scope.
Use Exchange's service-principal authorization test to inspect the effective in-scope role for a specific mailbox. Test negative cases as deliberately as the successful sender. Propagation can take time, so distinguish a newly created assignment from an incorrectly broad or permanently failed configuration.
Failure isolation
A 535 response does not identify the broken boundary by itself.
| Stage | Check | Typical mistake |
|---|---|---|
| Token acquisition | Tenant, token endpoint, certificate, private-key access, and https://outlook.office365.com/.default resource | Wrong audience, expired certificate, or inaccessible private key |
| Exchange principal | Application ID and enterprise service-principal object ID | Using the app-registration object ID |
| Role assignment | Correct application role and management scope | Missing role, wrong app, or scope that excludes the sender |
| SMTP submission | SMTP AUTH policy, sender identity, XOAUTH2 formatting, and TLS | Protocol disabled or token submitted for a different identity |
Preserve the complete Exchange response and verify each layer independently. Do not respond to an authorization failure by granting tenant-wide mail permissions merely to make the test pass.
Current implementation
RelayBridge uses the scoped App RBAC model.
RelayBridge v1.0.0-rc.1 uses a customer-owned single-tenant Entra application, a local non-exportable certificate, an Exchange service-principal reference, a sender group, a management scope, and one scoped Application SMTP.SendAsApp assignment. It does not request mailbox-reading access for delivery.
The released setup workflow verifies that the selected sender is in scope and that conflicting broad grants are absent. Use the administrator setup procedure for product configuration; this guide explains the underlying Microsoft authorization model and must not replace the supported wizard.
Clarifications
Frequently asked questions.
Does the certificate grant Send As permission?
No. It authenticates the application. Exchange authorization and the scoped sender resource are separate boundaries.
Should an App RBAC application also have SMTP.SendAsApp in Entra?
Microsoft's SMTP App RBAC onboarding guidance says not to add that application permission for the RBAC model. Review the complete environment before removing an existing grant because other integrations may depend on it.
Does App RBAC prevent every form of message spoofing?
No. It constrains the application's Exchange resource authority. Local client authorization, SMTP envelope policy, header handling, device restrictions, and downstream mail controls remain separate.
Authoritative sources