/* bc-smtp-content.jsx — body of the BC SMTP OAuth2 post. Exposes window.BCSmtpContent which renders inside .post-content. */ const Img = ({ src, caption }) => { const base = src.replace(/\.[^.]+$/, ""); return (
{caption}
{caption}
); }; const Code = ({ children, lang = "powershell" }) => { const [copied, setCopied] = React.useState(false); const onCopy = () => { navigator.clipboard.writeText(children).then(() => { setCopied(true); setTimeout(() => setCopied(false), 1600); }); }; return (
{lang} 
{children}
); }; const Callout = ({ kind = "note", title, children }) => (
{title}
{children}
); const Step = ({ n, total, section, title, children }) => (
Step {n} of {total} · {section}

{title}

{children}
); const SectionHead = ({ kicker, title, sub }) => (
// {kicker}

{title}

{sub ?

{sub}

: null}
); const Table = ({ rows }) => (
{rows[0].map((h, i) => )} {rows.slice(1).map((r, i) => ( {r.map((c, j) => )} ))}
{h}
{c}
); const SHOTS = "assets/posts/bc-smtp/"; const BCSmtpContent = () => ( <>

Sending email from Business Central used to mean basic SMTP with a username and password. Microsoft has been deprecating that for years. The replacement — SMTP AUTH with OAuth 2.0 — works, but only if you stitch together four moving pieces in the right order: an Azure App Registration, an Exchange Online service principal, mailbox-scoped permissions, and the BC email account itself.

I've set this up for clients more times than I'd like, and almost every failed attempt traces back to the same two or three places. This walkthrough is the order I now follow on every new tenant. Eighteen steps across four sections — sign in to Azure, configure Exchange via PowerShell, verify the token, finish in BC.

01Azure Portal5 steps · App registration & SMTP.SendAsApp
02Exchange Online6 steps · Service principal & mailbox scope
03Token Verification1 step · Confirm config before BC
04Business Central6 steps · Email account & test send
{/* SECTION 1 */}
  1. Open portal.azure.com.
  2. Sign in with a Global Administrator account.
  3. You'll land on the Azure Portal home page.
  1. Top search bar → type Microsoft Entra ID.
  2. Click Microsoft Entra ID from the search results.
  3. In the left sidebar, click App registrations.
  1. Click + New registration at the top.
  2. Name: something descriptive — e.g. BC SMTP OAuth Test.
  3. Supported account types: Accounts in this organizational directory only (Single tenant).
  4. Redirect URI: Web → https://businesscentral.dynamics.com/OAuthLanding.htm
  5. Click Register.
Once registered, the Overview page shows your Application (Client) ID and Directory (Tenant) ID. Copy both — you'll need them in Sections 2, 3, and 4.
  1. Left sidebar → API permissions.
  2. Click + Add a permission.
  3. Tab: APIs my organization uses.
  4. Search Office 365 Exchange Online → click it.
  5. Select Application permissions (NOT Delegated).
  6. Tick SMTP.SendAsApp.
  7. Click Add permissions.
Adding the permission isn't enough. Without admin consent it will silently fail later in Business Central. Grant it before continuing.
  1. Click Grant admin consent for <YourTenant>.
  2. Click Yes on the confirmation dialog.
  3. Confirm the Status column shows a green tick: Granted.
  1. Left sidebar → Certificates & secrets.
  2. Click + New client secret.
  3. Description: BC SMTP Key (or similar).
  4. Click Add.
Once you navigate away, the Value is never shown again. The Secret ID is not what you need — you want the Value column. You now have: Client ID, Tenant ID, Client Secret, and SMTP.SendAsApp granted with admin consent. Keep these values handy. {/* SECTION 2 */}

This is the step that catches everyone. The Object ID from Enterprise Applications is not the same as the Application (Client) ID from App Registrations. Exchange wants the Enterprise App Object ID — using the wrong one is the most common cause of "does not have Send As permissions" errors later.

  1. In Entra ID, go to Enterprise applications.
  2. Search for your app name (BC SMTP OAuth Test) and open it.
  3. From the Overview, copy the Object ID.

Open Windows PowerShell as Administrator and run:

{`Install-Module -Name ExchangeOnlineManagement -Force Import-Module ExchangeOnlineManagement Connect-ExchangeOnline -UserPrincipalName `}

Replace placeholders with your real IDs from Section 1 / Step 6:

{`New-ServicePrincipal `+ `-AppId `+ `-ObjectId `+ `-DisplayName "BC SMTP Service Principal"`} Older Exchange Online PowerShell modules don't accept -AppId. If you get a parameter-not-found error, use Get-ServicePrincipal | Where-Object { $_.AppId -eq "<id>" } to verify it was created via Entra sync instead.

This is the key restriction: the app gets access to one sender mailbox, nothing else. Don't use a wildcard.

{`Add-MailboxPermission `+ `-Identity "" `+ `-User `+ `-AccessRights FullAccess`} Use the Enterprise Application Object ID here — the one from Step 6, not Step 3.

SMTP AUTH is disabled by default at both the tenant and mailbox level. Enable it on the specific sender mailbox:

{`Set-CASMailbox `+ `-Identity "" `+ `-SmtpClientAuthenticationDisabled $false`}

Confirm the configuration before moving on:

{`# Confirm service principal exists Get-ServicePrincipal | Where-Object { $_.DisplayName -eq "BC SMTP Service Principal" } # Confirm mailbox permission Get-MailboxPermission -Identity "" | `+ `Where-Object { $_.User -like "**" } # Confirm SMTP Auth is on Get-CASMailbox -Identity "" | `+ `Format-List SmtpClientAuthenticationDisabled # Done Disconnect-ExchangeOnline -Confirm:$false`}

Expected: SmtpClientAuthenticationDisabled : False.

 {/* SECTION 3 */}

Run this before touching Business Central. If it fails here, BC will fail too — and BC's error messages are far less useful.

{`$tenantId = "" $clientId = "" $clientSecret = "" $body = @{ client_id = $clientId scope = "https://outlook.office365.com/.default" client_secret = $clientSecret grant_type = "client_credentials" } $response = Invoke-RestMethod `+ `-Method POST `+ `-Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" `+ `-Body $body $response.access_token`}

A long token string means everything is wired up. An HTTP 401 or "invalid_client" means the secret is wrong or admin consent wasn't granted in Step 4.

 {/* SECTION 4 */}
  1. Sign in to Business Central.
  2. Press Alt+Q (or click the search icon).
  3. Type Email Accounts and press Enter.
  4. Click the Email Accounts result.
  1. On the Email Accounts page, click + New in the ribbon.
  2. The Add Email Account wizard opens. Click Next.
  3. Select SMTP from the connectors.
  4. Click Next.

Click Apply Office 365 Server Settings to auto-fill, then verify:

smtp.office365.com], ["Port", 587], ["Authentication", OAuth 2.0], ["Email Address", " (the restricted sender from Step 9)"], ["Sender Name", "Your preferred display name"], ["Sender Type", "Specific User"], ]}/>

Click Set Custom Credentials and enter:

The Client ID must be from the same App Registration where you granted SMTP.SendAsApp. A different one will fail authentication — silently — at send time. Once saved, BC stores the Client ID, Client Secret, and Tenant ID in isolated storage — a private store managed exclusively by the Email — SMTP Connector app published by Microsoft. They can only be read by that app, never exposed in plain text, and not visible to other extensions or users.
  1. Click Authenticate (or Get Token). A sign-in popup may appear.
  2. Sign in with the Global Administrator account when prompted.
  3. Click Next in the wizard.
  4. Click Finish.
Don't try to edit the failed account. BC stores a corrupted token that can't be repaired. Delete the SMTP account, generate a fresh client secret in Entra (Step 5), and walk back through from Step 14. It sounds drastic; it's the only path that works.
  1. Select your new SMTP account on the Email Accounts page.
  2. Click Send Test Email from the ribbon.
  3. Enter your own address as the recipient and click Send.
  4. Check your inbox.
 {/* TROUBLESHOOTING */}
Unable to get SMTP Account password
BC stored a corrupted token from a previous failed setup.
Delete the BC SMTP account. Generate a new client secret in Entra. Re-add from scratch (Step 14).
Failed to acquire token · HTTP 401
SMTP.SendAsApp not consented, or wrong Client ID / Secret.
Grant admin consent in Entra. Run the token test (Step 12) before returning to BC.
SMTP Error 535
SMTP Auth disabled on mailbox or at tenant level.
Run Set-CASMailbox -SmtpClientAuthenticationDisabled $false (Step 10).
-AppId parameter not found
Older Exchange Online PowerShell module.
Use Get-ServicePrincipal | Where-Object { $_.AppId -eq "<id>" } instead.
Does not have Send As permissions
Wrong Object ID used, or Add-MailboxPermission not run.
Re-run Step 9 with the Enterprise App Object ID — not the Client ID.
{/* CHECKLIST */}
  1. Azure App Registration created — Client ID & Tenant ID noted.
  2. SMTP.SendAsApp — admin consent granted in Entra ID.
  3. Client Secret generated and saved securely.
  4. Exchange service principal created via PowerShell.
  5. Mailbox FullAccess granted to the app (Add-MailboxPermission).
  6. SMTP Auth enabled on the mailbox (SmtpClientAuthenticationDisabled : False).
  7. OAuth token test passed via PowerShell.
  8. BC SMTP Account configured with OAuth 2.0 custom credentials.
  9. Test email sent and received from Business Central.

That's the whole chain. The wins from this setup over basic auth are real — no shared mailbox passwords, scoped to one sender, revocable per-secret, and aligned with where Microsoft is forcing everyone in 2026 anyway.

— Sudip Shrestha · Dogma Group · Kathmandu

); window.BCSmtpContent = BCSmtpContent;