SMTP AUTH with OAuth 2.0 Client Credentials Flow returns 535 5.7.3 despite complete configuration per official docs

Question

Business Justification for OAuth 2.0 Client Credentials Flow

The Microsoft 365 connector with Delegated permissions cannot be used because the 11 users who execute email sending operations from Business Central do not have Exchange Online licenses (they hold Dynamics 365 Business Central Essentials and Team Members licenses without Exchange).

The shared mailbox used as sender (shared-mailbox@<tenant>.onmicrosoft.com) is unlicensed (Shared Mailbox does not require a license per Microsoft policy).

Therefore, Application permissions (Client Credentials flow) is the only architecturally valid option as it does not require the user executing the operation to have a mailbox or Exchange license. This architectural decision aligns with Microsoft's own recommendations for service-to-service email sending scenarios.

Configuration Applied (Per Official Documentation)

Reference Documentation Followed

The configuration is based strictly on the following official Microsoft Learn articles:

1. Authenticate an IMAP, POP or SMTP connection using OAuth — learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth
2. OAuth 2.0 client credentials flow on the Microsoft identity platform — learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-client-creds-grant-flow
3. Authenticated client SMTP submission — learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission

Step 1: App Registration in Microsoft Entra ID

• Created Single-Tenant App Registration
• Redirect URI configured: https://businesscentral.dynamics.com/OAuthLanding.htm (Web platform)
• Client Secret generated with 24-month validity

Step 2: API Permissions (Application type, with Admin Consent granted)

• Microsoft Graph: Mail.Send — Granted
• Office 365 Exchange Online: SMTP.SendAsApp — Granted

Both permissions were granted admin consent successfully (status visible in Entra portal).

Step 3: Mailbox Conversion to Shared Mailbox

The original licensed mailbox was converted to Shared Mailbox to remove the unnecessary Microsoft 365 Business Basic license, since the Shared Mailbox does not require licensing.

Result:

• Token obtained successfully
• Token length: 2098 characters
• Token type: Bearer
• Expires in: 3599 seconds
• Scope: https://outlook.office365.com/.default (correct per documentation)

SMTP Direct Authentication Test

Direct SMTP session against smtp.office365.com:587 with PowerShell:

S: 220 BN9PR03CA0753.outlook.office365.com Microsoft ESMTP MAIL Service ready
C: EHLO test.local
S: 250-BN9PR03CA0753.outlook.office365.com Hello [<client-ip>]
S: 250-SIZE 157286400
S: 250-PIPELINING
S: 250-DSN
S: 250-ENHANCEDSTATUSCODES
S: 250-STARTTLS
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-CHUNKING
S: 250 SMTPUTF8
C: STARTTLS
S: 220 2.0.0 SMTP server ready
[TLS established successfully]
C: EHLO test.local
S: 250-BN9PR03CA0753.outlook.office365.com Hello [<client-ip>]
S: 250-SIZE 157286400
S: 250-PIPELINING
S: 250-DSN
S: 250-ENHANCEDSTATUSCODES
S: 250-AUTH LOGIN XOAUTH2
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-CHUNKING
S: 250 SMTPUTF8
C: AUTH XOAUTH2 <base64-encoded-credentials>
S: 535 5.7.3 Authentication unsuccessful [<server-id>]

Business Central Test

The same configuration in Business Central yields a slightly different error message (because BC uses MailKit), but the underlying issue is identical:

Timing Analysis (Replication Ruled Out)

Event	Timestamp
Service Principal created in Exchange Online	T-72 hours
--------	--------
Service Principal created in Exchange Online	T-72 hours
Management Scope created	T-72 hours
Management Role Assignment (Mail.Send)	T-50 hours
Management Role Assignment (SMTP.SendAsApp)	T-44 hours
SmtpClientAuthenticationDisabled set to $false	T-46 hours
First SMTP test	T-44 hours: 535 5.7.3
Test at T-36 hours	535 5.7.3 (identical)
Test at T-24 hours	535 5.7.3 (identical)
Test at T-0 (current)	535 5.7.3 (identical)

Microsoft documentation indicates replication of RBAC for Applications changes can take 24-48 hours. Over 44 hours have elapsed since the last critical change, with identical error response on every test, ruling out replication as the cause.

Information Available for Diagnostic

The following information is available and can be shared upon request through secure channel:

• Tenant ID
• Application (Client) ID
• Service Principal Object ID
• Mailbox ExchangeGuid
• Sample request IDs from failed authentication attempts
• Full PowerShell transcript of all configuration commands executed
• Server-side identifiers from SMTP responses (e.g., BN9PR03CA0753.namprd03.prod.outlook.com)

Configuration Summary Table

Component	Status	Verification Method
App Registration (Single-Tenant)	Configured	Entra portal
--------	--------	--------
App Registration (Single-Tenant)	Configured	Entra portal
Redirect URI	Configured	Entra portal
Client Secret (valid, not expired)	Active	Entra portal
Mail.Send permission	Granted with admin consent	Entra portal
SMTP.SendAsApp permission	Granted with admin consent	Entra portal
Service Principal in Exchange	IsValid: True	Get-ServicePrincipal
Management Scope	Created with correct filter	Get-ManagementScope
Role Assignment (Mail.Send)	Direct, ServicePrincipal	Get-ManagementRoleAssignment
Role Assignment (SMTP.SendAsApp)	Direct, ServicePrincipal	Get-ManagementRoleAssignment
Test-ServicePrincipalAuthorization	InScope: True for target mailbox	PowerShell
Test-ServicePrincipalAuthorization	InScope: False for other mailboxes	PowerShell (isolation confirmed)
Mailbox SMTP AUTH	Enabled (False = enabled)	Get-CASMailbox
OAuth Token Acquisition	Successful (2098 char token)	Direct PowerShell test
SMTP TLS Connection	Successful	Direct PowerShell test
SMTP STARTTLS Negotiation	Successful	Direct PowerShell test
AUTH XOAUTH2 Submission	Fails with 535 5.7.3	Direct PowerShell test

Expected Resolution

Either:

1. Identification of a specific configuration item that was missed or is incorrectly documented
2. Confirmation that a service-side issue exists in Microsoft Exchange Online and resolution by Microsoft engineering
3. Documented workaround that does not require migrating away from SMTP+OAuth (since the architecture decision was made specifically to avoid licensing 11 additional users)

   exchange-online smtp-auth oauth2 client-credentials-flow application-permissions business-central dynamics-365 entra-id service-principal smtp-sendasapp mailkit xoauth2 535-5-7-3

Answer 1

Hello! I'm Mason, i will do my best to help you with this problem.

In my understanding, two Mutually Exclusive Authorization Paths Are Conflicting

Your configuration is mixing two distinct authorization models for SMTP.SendAsApp, and that conflict is most likely causing the persistent 535 5.7.3. Let me explain.

The Two Paths

Microsoft supports two separate and mutually exclusive authorization models for SMTP client credentials flow:

Path 1: Classic Mailbox Permission

• Requires SMTP.SendAsApp Entra API permission (with admin consent)
• Requires Exchange service principal (New-ServicePrincipal)
• Requires Add-MailboxPermission with FullAccess granted to the service principal

Path 2: App RBAC (New-ManagementRoleAssignment)

• Does not require mailbox permissions
• Does not require SMTP.SendAsApp as an Entra API permission
• Microsoft's own documentation explicitly warns: "Refrain from adding any permissions to your application, as this process does not require any claims. Including the SMTP.SendAsApp claim would trigger an unnecessary check for mailbox permissions."

Your configuration has the SMTP.SendAsApp Entra permission (with admin consent) and the New-ManagementRoleAssignment RBAC path active simultaneously. Exchange sees the SMTP.SendAsApp claim in the token and triggers the mailbox permission check — but your authorization is through RBAC, not through Add-MailboxPermission. The check fails silently and you receive 535 5.7.3.

Resolution: Choose One Path and Remove the Other

Option A — Pure RBAC Path (recommended for your scenario)

1. Remove the SMTP.SendAsApp application permission from your Entra app registration entirely. The token must not carry that claim.
2. Keep your New-ServicePrincipal, New-ManagementScope, and New-ManagementRoleAssignment as-is.
3. Re-acquire a fresh token and retry SMTP authentication.

Option B — Classic Mailbox Permission Path

1. Keep SMTP.SendAsApp in Entra with admin consent.
2. Remove the RBAC role assignments (Remove-ManagementRoleAssignment).
3. Run:

Add-MailboxPermission -Identity "******@tenant.onmicrosoft.com" `
    -User <EXO_ServicePrincipal_Identity> -AccessRights FullAccess

Add-RecipientPermission -Identity "******@tenant.onmicrosoft.com" `
    -Trustee <EXO_ServicePrincipal_Identity> -AccessRights SendAs

Additional Item: Verify SMTP AUTH Is Actually Enabled on the Shared Mailbox

The "Authenticated SMTP" toggle is absent from the shared mailbox UI in the Exchange Admin Center (unlike regular user mailboxes). Even though you ran Set-CASMailbox, confirm it actually applied:

Get-CASMailbox -Identity "******@tenant.onmicrosoft.com" `
    | Select SmtpClientAuthenticationDisabled

The value must be False. If it returns True or $null, SMTP AUTH is still disabled for that mailbox regardless of the org-level setting.

Additional Item: Verify the Correct ObjectId Was Used for New-ServicePrincipal

A common silent failure is using the wrong ObjectId. The ObjectId passed to New-ServicePrincipal must come from:

Entra ID > Enterprise applications > Your app > Properties > Object ID

Not from the App Registration blade. These are different GUIDs. Verify with:

Get-ServicePrincipal | Where-Object { $_.AppId -eq "<your-client-id>" } `
    | Select AppId, ObjectId, DisplayName

Cross-reference the returned ObjectId against what you originally passed to New-ServicePrincipal -ObjectId.

Additional Item: XOAUTH2 String Construction

Rule out encoding issues by confirming the SASL XOAUTH2 string is constructed exactly as: base64("user=" + smtpAddress + "^Aauth=Bearer " + accessToken + "^A^A")

Where ^A is the SOH control character (U+0001), not a literal caret-A text sequence. MailKit's SaslMechanismOAuth2 handles this correctly. If you are constructing the raw AUTH string manually in PowerShell for diagnostic purposes, a malformed encoding will produce 535 5.7.3 even with a valid token and correct permissions.

I hope this helps!

Answer 2

Hi Mason,

Thank you for your detailed and accurate diagnosis. You were absolutely correct.

The root cause was exactly as you described: two mutually exclusive authorization paths were active simultaneously. The SMTP.SendAsApp API permission in Entra ID was causing Exchange Online to trigger a mailbox permission check (Path 1 / Classic Mailbox), while our actual authorization was configured through RBAC (New-ManagementRoleAssignment) as Path 2.

The key insight from your response that resolved the issue:

"Refrain from adding any permissions to your application, as this process does not require any claims. Including the SMTP.SendAsApp claim would trigger an unnecessary check for mailbox permissions."

Resolution steps that worked:

1. Removed SMTP.SendAsApp from the Configured permissions in the App Registration
2. Revoked the admin consent for SMTP.SendAsApp from Enterprise Applications (the permission was still appearing in "Other permissions granted" and the claim was still present in the token even after removing it from Configured permissions)
3. Verified via PowerShell token decode that the roles claim no longer contained SMTP.SendAsApp
4. Retested SMTP AUTH — authentication succeeded immediately

Important note for others who encounter this issue:

Removing the permission from App Registration's Configured permissions is not sufficient on its own. You must also revoke the admin consent from Enterprise Applications → Permissions → Revoke. Otherwise the claim will still appear in the token (verifiable by decoding the JWT payload and checking the roles array).

Final working configuration (Pure RBAC Path):

• New-ServicePrincipal with correct Enterprise Application Object ID
• New-ManagementScope with RecipientRestrictionFilter scoped to the specific mailbox ExchangeGuid
• New-ManagementRoleAssignment with -Role "Application Mail.Send" and -CustomResourceScope
• Set-CASMailbox -SmtpClientAuthenticationDisabled $false on the target mailbox
• No SMTP.SendAsApp permission in Entra ID (not in Configured permissions, not in Other permissions granted)
• Token roles claim must be empty or contain only Mail.Send (Graph) — no SMTP.SendAsApp

Marking this as the accepted answer. Thank you for saving us significant diagnostic time.Hi Mason,

Thank you for your detailed and accurate diagnosis. You were absolutely correct.

The root cause was exactly as you described: two mutually exclusive authorization paths were active simultaneously. The SMTP.SendAsApp API permission in Entra ID was causing Exchange Online to trigger a mailbox permission check (Path 1 / Classic Mailbox), while our actual authorization was configured through RBAC (New-ManagementRoleAssignment) as Path 2.

The key insight from your response that resolved the issue:

"Refrain from adding any permissions to your application, as this process does not require any claims. Including the SMTP.SendAsApp claim would trigger an unnecessary check for mailbox permissions."

Resolution steps that worked:

1. Removed SMTP.SendAsApp from the Configured permissions in the App Registration
2. Revoked the admin consent for SMTP.SendAsApp from Enterprise Applications (the permission was still appearing in "Other permissions granted" and the claim was still present in the token even after removing it from Configured permissions)
3. Verified via PowerShell token decode that the roles claim no longer contained SMTP.SendAsApp
4. Retested SMTP AUTH — authentication succeeded immediately

Important note for others who encounter this issue:

Removing the permission from App Registration's Configured permissions is not sufficient on its own. You must also revoke the admin consent from Enterprise Applications → Permissions → Revoke. Otherwise the claim will still appear in the token (verifiable by decoding the JWT payload and checking the roles array).

Final working configuration (Pure RBAC Path):

• New-ServicePrincipal with correct Enterprise Application Object ID
• New-ManagementScope with RecipientRestrictionFilter scoped to the specific mailbox ExchangeGuid
• New-ManagementRoleAssignment with -Role "Application Mail.Send" and -CustomResourceScope
• Set-CASMailbox -SmtpClientAuthenticationDisabled $false on the target mailbox
• No SMTP.SendAsApp permission in Entra ID (not in Configured permissions, not in Other permissions granted)
• Token roles claim must be empty or contain only Mail.Send (Graph) — no SMTP.SendAsApp

Marking this as the accepted answer. Thank you for saving us significant diagnostic time.