Email for notifications

Two transports, chosen with the toggle at the top of the panel.

Microsoft 365. Nobody signs in. Cloud Connector sends as a mailbox in your tenant using its own Azure managed identity, so there is no password, no refresh token, and nothing that expires. Set Send as to the mailbox alerts should come from - alerts@yourcompany.com rather than a named person - and From name to the display name recipients will see.

Sending will not work until an administrator has set it up outside Cloud Connector. None of it can be done from this page: the application cannot grant itself permission.

There are two ways to do it, and they are alternatives, not consecutive steps. Each ends with the identity able to send as one mailbox and no other.

	Path A - RBAC for Applications	Path B - application access policy
Granted in Entra	nothing	`Mail.Send`, every mailbox in the tenant
Scoped in Exchange	management scope, by address	mail-enabled security group
Admin roles	Exchange Administrator	Privileged Role Administrator, then Exchange Administrator
Status	Microsoft's replacement for access policies	older mechanism, still supported

Prefer Path A: one admin role instead of two, no group to create and keep correct, and the identity is never tenant-wide even briefly.

Do not combine them. Granting Mail.Send in Entra ID and adding an RBAC scope in Exchange is the one combination that fails silently. The two are independent authorities and their permissions are unioned, so an Exchange scope does not narrow an Entra grant - the grant survives it. Every command succeeds, every confirmation cmdlet prints what you expect, and the identity can still send as any mailbox in the tenant. Only an application access policy can constrain an Entra grant, which is what Path B is.

Step 0 - copy the identity's client ID. Open Setup -> Access in Cloud Connector and copy Managed identity (client) ID. That is the $AppId both paths refer to. It is an identifier, not a secret, and it is safe to paste into a mail to whoever holds the admin roles.

Path A also needs the identity's object ID, which is a different value. In the Azure portal it is on the identity itself: Microsoft Entra ID -> Enterprise applications, Application type filter set to Managed identities, named <app name>-backend-mi - so a deployment called contoso-cc has an identity called contoso-cc-backend-mi. Take Object ID from that page. Do not take IDs from App registrations; that blade shows different values for the same app, and Exchange will reject them.

To read it from PowerShell instead - this grants nothing, it only looks:

Connect-MgGraph -Scopes "Application.Read.All"
(Get-MgServicePrincipal -Filter "appId eq '$AppId'").Id

If that comes back empty the client ID is wrong - re-copy it from Setup -> Access rather than guessing at a display name.

Path A - RBAC for Applications

Requires the Exchange Administrator role. Nothing is granted in Entra ID on this path. If Mail.Send was granted there previously - by an earlier attempt, or by following an older version of these instructions - it must be removed, or the scope below has no effect at all.

$Mailbox  = "alerts@yourcompany.com"
$AppId    = "<Managed identity (client) ID from step 0>"
$ObjectId = "<the identity's object ID from step 0>"

# If Connect-ExchangeOnline is not recognised:
#   Install-Module ExchangeOnlineManagement -Scope CurrentUser -Force
Connect-ExchangeOnline

New-ServicePrincipal -AppId $AppId -ObjectId $ObjectId -DisplayName "Cloud Connector"

New-ManagementScope -Name "CloudConnector-NotificationMailbox" `
  -RecipientRestrictionFilter "WindowsEmailAddress -eq '$Mailbox'"

New-ManagementRoleAssignment -Name "CloudConnector-MailSend" `
  -App  $AppId `
  -Role "Application Mail.Send" `
  -CustomResourceScope "CloudConnector-NotificationMailbox"

New-ServicePrincipal fails if Exchange has already seen this identity. That is harmless - carry on with the scope and the role assignment.

WindowsEmailAddress matches the primary address only. PrimarySmtpAddress also matches proxy addresses, so a second mailbox carrying $Mailbox as an alias would fall inside the scope too.

Then verify, before trusting it:

# Which mailboxes does the scope actually resolve to? Expect exactly one.
$s = Get-ManagementScope "CloudConnector-NotificationMailbox"
Get-Recipient -RecipientPreviewFilter $s.RecipientFilter

# Does the identity have Mail.Send over that mailbox, and only over it?
Test-ServicePrincipalAuthorization -Identity $AppId -Resource $Mailbox | Format-Table
Test-ServicePrincipalAuthorization -Identity $AppId `
  -Resource someone.else@yourcompany.com | Format-Table

Application Mail.Send should be listed with InScope True for the sender and False for the other mailbox. Test-ServicePrincipalAuthorization is the check that matters: it deliberately ignores anything granted in Entra ID, and it bypasses Exchange's permission cache, so it answers about the scope alone and it answers immediately. Listing the role assignment and the scope with Get- only confirms the objects exist, not that they authorise anything.

The same assignment can be made in the Exchange admin centre under Roles -> Applications -> Add role assignment, if you would rather click than script.

Path B - application access policy

For tenants already standardised on access policies. Two admin roles, usually two different people, and the identity is tenant-wide between them.

Step 1 - grant Mail.Send in Entra ID. Requires the Privileged Role Administrator role. Graph application permissions cannot be assigned to a managed identity from the Azure portal - the App registrations blade does not list managed identities, and Enterprise applications shows their permissions without letting you add any. Use PowerShell with the Microsoft Graph module.

Install it first if Connect-MgGraph is not recognised. Only two sub-modules are needed - installing the full Microsoft.Graph meta-module pulls down about a gigabyte and is not necessary:

Install-Module Microsoft.Graph.Authentication, Microsoft.Graph.Applications `
  -Scope CurrentUser -Force

On Windows PowerShell 5.1, run [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 first if the gallery refuses the connection.

Then:

$AppId = "<Managed identity (client) ID from step 0>"

Connect-MgGraph -Scopes "AppRoleAssignment.ReadWrite.All","Application.Read.All"

$mi    = Get-MgServicePrincipal -Filter "appId eq '$AppId'"
$graph = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
$role  = $graph.AppRoles | Where-Object { $_.Value -eq 'Mail.Send' }

New-MgServicePrincipalAppRoleAssignment `
  -ServicePrincipalId $mi.Id `
  -PrincipalId        $mi.Id `
  -ResourceId         $graph.Id `
  -AppRoleId          $role.Id

At this point the identity can send as any mailbox in the tenant. Step 2 is what takes that away, and it is not optional.

To confirm the grant in the portal: reopen the identity under Enterprise applications and check Permissions.

Step 2 - restrict it to one mailbox. Requires the Exchange Administrator role. It needs a mail-enabled security group whose only member is the sender mailbox; nested members do not count.

New-ApplicationAccessPolicy `
  -AppId $AppId `
  -PolicyScopeGroupId cloud-connector-senders@yourcompany.com `
  -AccessRight RestrictAccess `
  -Description "Cloud Connector may send only as its notification mailbox"

Test-ApplicationAccessPolicy -Identity alerts@yourcompany.com -AppId $AppId
Test-ApplicationAccessPolicy -Identity someone.else@yourcompany.com -AppId $AppId

AccessCheckResult should read Granted for the sender and Denied for the other mailbox.

Both paths - wait before concluding it did not work

Exchange caches an application's permissions for 30 minutes to 2 hours - 30 minutes if the app is idle, up to 2 hours if it is actively calling - and Cloud Connector holds its own Graph token for up to an hour after that. A change, and especially a removal, can take that long to be felt by a real send. Test-ServicePrincipalAuthorization and Test-ApplicationAccessPolicy skip the wait; restarting the backend container app clears Cloud Connector's side of it.

Finally - send a test email

The Settings panel can only report its own half of the setup; it cannot see the Entra grant or the Exchange scope. "Sender configured" therefore means "this side is done", not "email works". A delivered test is the only proof.

To prove the restriction as well as the permission, temporarily change Send as to some other mailbox in the tenant, save, and test again. Exchange refuses it and the panel reports that this identity is not scoped to that mailbox - which is the boundary doing its job. Change it back afterwards.

That test is worth doing rather than assuming. A send that succeeds as another mailbox is the signature of an unscoped Entra grant left in place alongside a Path A scope.

Earlier versions connected a mailbox by signing a person in and storing the resulting refresh token. That credential was narrower — it could only ever act as the account that signed in — but it expired ninety days after the last email, on the one channel whose job is to report failures, so the failure was silence. The application permission does not expire; its breadth is bounded in Exchange instead, which an administrator can audit.

SMTP relay. Host, port, TLS mode, credentials, From address, From name. The saved password is never sent back to the browser — leave the field blank to keep it, or type a new one to replace it.

Send test email dispatches a probe to a recipient you specify. A success means the message was accepted for delivery, not that it arrived — check the inbox. Without a configured transport, email subscriptions silently no-op.

Path A - RBAC for Applications​

Path B - application access policy​

Both paths - wait before concluding it did not work​

Finally - send a test email​

Path A - RBAC for Applications

Path B - application access policy

Both paths - wait before concluding it did not work

Finally - send a test email