Microsoft 365 OAuth mail failures are usually about app registration, tenant/account policy or token state—not the old SMTP password. Diagnose the Entra application, redirect URI, delegated/application permissions, mailbox identity and SMTP AUTH policy as separate controls.
Match tenant and account type
Single-tenant vs multi-tenant settings and the authorization endpoint must match the mailbox organization and plugin expectations.
Verify redirect URI and client identity
Compare the exact HTTPS callback, client ID and tenant. A copied staging/production configuration often leaves one URI wrong.
Check required permissions and consent
Distinguish delegated user consent from admin consent and grant only the scopes documented by the mail plugin/provider flow.
Inspect SMTP AUTH/mailbox policy
OAuth can succeed while SMTP AUTH is disabled for the tenant or mailbox. Confirm the chosen transport is allowed rather than falling back to legacy auth.
Handle token refresh and revocation
Record error codes such as invalid_grant without exposing tokens. Reauthorize after password/security-policy or app-secret changes when required.
Test sender identity
The authenticated mailbox must be allowed to send as the configured From address. Shared mailbox/send-as permissions are a separate layer from token acquisition.
Interpret transport with safe SMTP logs and compare legacy auth failures with SMTP authentication after credential changes.
Separate tenant, app and mailbox in one matrix
Record tenant ID, application/client ID, redirect host, authenticated account, intended From address, consent type and whether SMTP AUTH/send-as is allowed for that mailbox. Do not store secrets or tokens. Most confusing Microsoft 365 failures become simpler once you can see that authorization succeeded for one identity while WordPress is trying to send as another.