Your mailer plugin is asking for delegated Mail.Send, which lets the site send as one signed-in account. A tenant-wide ban on Mail.Send is usually written with the application version in mind, which in Microsoft’s words lets an app “send mail as any user without a signed-in user”: one credential that can send as the CEO, payroll, or anyone else in the tenant. If that is IT’s objection, naming the permission the plugin actually requests usually settles it. If IT bans delegated Mail.Send too, offer a dedicated sending account locked to the app, using the request below. If the answer is still no, the site’s mail leaves the tenant.
Two permissions with the same name
Microsoft Graph, the API these plugins send through, has both kinds. IT will see them in Entra under Microsoft’s display names: “Send mail as a user” for delegated, “Send mail as any user” for application.
Application Mail.Send |
Delegated Mail.Send (+ Mail.Send.Shared) |
|
|---|---|---|
| Acts as | The app itself, no user signed in | The account that signed in during setup |
| Which mailboxes | Any mailbox in the tenant | That account’s mailbox, plus any mailbox it holds Send As or Send on Behalf on |
| Consent | Admin consent required | Admin consent not required; users can consent for themselves unless the tenant has turned that off |
| Narrowed by | RBAC for Applications in Exchange Online | The signed-in account’s own mailbox rights |
Sources: Microsoft’s 
Graph permissions reference and sending from another user. The consent row is why the request reached IT. Entra lets users consent to delegated permissions by default, but a tenant that has switched user consent off, or limited it to permissions IT has classified as low impact, stops the plugin’s sign-in and asks for an admin. That is why our Microsoft 365 setup guide includes the “Grant admin consent” step.
What each plugin requests, read from the plugin code downloaded from WordPress.org on 19 October 2026 and, for WP Mail SMTP Pro, its published docs:
- FluentSMTP 2.4.1 requests
mail.send,mail.send.shared(for From addresses on other mailboxes) andoffline_accessthrough a user sign-in, and makes one Graph call,POST /me/sendMail. A code comment says the list is kept send-only so that a leaked refresh token “should be able to do no more than that.” - Post SMTP 4.0.2 puts the Microsoft 365 connection in its paid Pro extension; the free plugin doesn’t include it. For its One-Click setup (Pro Business plan), which signs in through Post SMTP’s own app rather than one in your tenant, the free code records the scopes
openid profile offline_access Mail.Send Mail.Send.Shared. The scopes for the own-app setup live in the Pro code, which isn’t public. - WP Mail SMTP Pro‘s source isn’t public. Its docs describe a Microsoft account sign-in, which is how delegated permissions are granted, and a
mail.readwritescope removable with thewp_mail_smtp_pro_providers_outlook_auth_get_scopesfilter (attachments then cap at 3 MB). Almost certainly delegated, then, but the full list isn’t published.
IT’s consent screen for FluentSMTP will therefore show two send permissions, not one, and Post SMTP’s One-Click connection asks for the same pair. Say so before they see it.
Delegated access still carries a risk, and IT will ask about it: the plugin stores a refresh token in the WordPress database, so anyone who compromises the site can send as that account. Revoking the account’s sign-in sessions invalidates every refresh token issued to apps for that user, per Microsoft.
How to keep the grant to one mailbox
A dedicated sending account. Create wordpress@ or noreply@ as a licensed mailbox nobody reads, with no Send As or Send on Behalf grants, and connect the plugin as that account. Mail.Send.Shared then has nothing extra to reach, and a compromise exposes one address and no person’s inbox.
Shared mailboxes don’t fit here. Microsoft says a shared mailbox “isn’t intended for direct sign-in” and its sign-in should stay blocked.
Sending as a shared mailbox works differently: a licensed account with Send As on it signs in, and Mail.Send.Shared carries the send. That account can then send as every mailbox it has Send As on, which widens the grant. For aliases, see the Microsoft 365 alias answer.
Lock the app to that account. Without user assignment, any user in the tenant could sign in to the same app registration as themselves. IT can register the app as single-tenant, require user assignment on the enterprise application, and assign only the sending account. Apps requiring assignment need admin consent, Microsoft notes, so IT keeps the approval.
An owner for the secret. A client secret on your own app registration lasts 24 months at most, and the site stops sending when it expires (Microsoft 365 entity page). WP Mail SMTP’s One-Click Setup skips app registration: per its docs, you sign in and accept WP Mail SMTP’s access request, so IT approves a third-party app instead of owning one, and the connection stops if the WP Mail SMTP licence lapses. Post SMTP’s One-Click (Business plan) also skips app registration and signs in through Post SMTP’s own app; its docs don’t say what happens if the licence lapses.
The request to send IT
- App: single-tenant app registration in our tenant, owned by IT.
- Permissions: Microsoft Graph delegated
Mail.Send(“Send mail as a user”),Mail.Send.Sharedif the plugin requests it, andoffline_access. No application permissions.- Account:
[email protected], licensed, no Send As or Send on Behalf grants, not read by anyone.- Access: user assignment required; assigned to that account only.
- Secret: 24 months at most; rotation owner [name]; expiry date in [calendar].
- Revocation: if the site is compromised, IT revokes the account’s sign-in sessions (
Revoke-MgUserSignInSession) and disables the account.
When the answer is still no
The SMTP relay connector. IT creates an inbound connector that trusts the WordPress server by TLS certificate or static IP; the site sends on port 25 with no app, no consent and no licensed mailbox. The blocker is Microsoft’s line “You can’t use SMTP relay to send email from a third-party hosted service”, with Azure as the example, which in practice rules out managed WordPress hosting. It fits a server IT controls, on an IP no other organisation shares. The relay and Direct Send guide covers the connector side.
Take the tenant out of it. Send A transactional email is the automated message a WordPress site sends in response to a single user action – a password reset, an order confirmation, a form receipt – addressed to the user who triggered it. Read full reference → through a dedicated provider. For most WordPress sites this is the better arrangement anyway: an Exchange Online mailbox caps at 10,000 recipients a day and 30 messages a minute. The site also gets no delivery log or bounce webhook of its own; per-message tracking is IT’s message trace, and bounces land in a mailbox nobody reads. The tenant never sees the site, but DNS still involves IT. With a From address on a subdomain such as @mail.example.com, the provider’s DKIM and return-path records sit on that subdomain; with @example.com, the DKIM record goes on the domain IT cares about. Record names vary by provider; our catalogue of sending services compares them.
If the request is for application Mail.Send
None of these plugins need it; a custom integration might. Exchange Online’s RBAC for Applications scopes it to named mailboxes, and Microsoft says it “replaces Application Access Policies” (New-ApplicationAccessPolicy), without calling those deprecated or dating a removal. The grants add together, so the unscoped Mail.Send grant in Entra has to go or the scope restricts nothing.
The cmdlets from Microsoft’s RBAC for Applications page, with the address filter set to the example account; not tested by nanoPost:
New-ServicePrincipal -AppId <app-id> -ObjectId <enterprise-app-object-id> -DisplayName "WordPress sender"
New-ManagementScope -Name "WordPress sender" -RecipientRestrictionFilter "EmailAddresses -eq '[email protected]'"
New-ManagementRoleAssignment -App <enterprise-app-object-id> -Role "Application Mail.Send" -CustomResourceScope "WordPress sender"
Test-ServicePrincipalAuthorization -Identity <enterprise-app-object-id> -Resource [email protected]The object ID comes from Enterprise applications; the object ID shown under App registrations is a different value. Changes take between 30 minutes and 2 hours to apply.
When IT agrees to the delegated request, the Microsoft 365 setup guide walks through the app registration step by step.