WordPress reports an authentication error even though the mailbox password is correct. Microsoft 365 has disabled authenticated client SMTP for the tenant and the mailbox, so resetting the password cannot change the result.
Treat this as a protocol-policy decision. Identify the setting that blocks the route, then choose the narrowest delivery method currently supported by Microsoft and the organization.
What it means
When SMTP AUTH is disabled, a tenant setting, mailbox setting, or applicable security policy does not permit the attempted authenticated SMTP submission. Valid credentials can still be unusable for that protocol. SMTP submission, relay, OAuth, Send As permission, and mailbox login are separate controls.
A realistic WordPress example
A site uses a dedicated mailbox, but both the tenant and mailbox settings prohibit SMTP AUTH. Rather than enabling legacy submission for the whole organization, the administrators review current Microsoft guidance and approve a narrowly scoped supported route. They verify the authenticated principal and From permission with one real WordPress message.
Why it matters and when to use it
This distinction prevents repeated password changes and broad security exceptions. Investigate it when the SMTP response points to disabled authentication, especially if the same credentials work for normal mailbox access.
A straightforward route for beginners
- Preserve the exact SMTP response, timestamp, endpoint, and authentication method.
- Check the tenant setting, mailbox override, Security Defaults, and applicable Conditional Access policy.
- Confirm mailbox ownership and the right to use the selected From address.
- Choose a current supported route with the smallest practical scope.
- Send a real WordPress message and verify Microsoft trace, provider acceptance, and delivery.
The advanced route
Separate invalid credentials from a disabled protocol and tenant policy from a mailbox override. Review the authenticated principal, application or connector scope, Send As rights, endpoint, and trace. In a controlled window, revoke the grant or disable the narrow permission to prove ownership and predictable failure, then restore it through the documented administrator.
Risks, common mistakes, backup, and rollback
Do not enable SMTP AUTH tenant-wide for one site, weaken Security Defaults, use an administrator mailbox, or create a broad hidden connector. Stop if the controlling policy or responsible account is unknown. If the new route cannot be verified, remove its grant and restore the last approved delivery path rather than cycling passwords.
How AIOWS helps:
AIOWS SMTP Manager
AIOWS SMTP Manager keeps the WordPress endpoint, authentication settings, sender identity, tests, and diagnostic results visible together. This helps determine whether WordPress reached Microsoft 365 and how the service answered.
Configure only the route approved by the Microsoft 365 administrators and test a real password reset, form, or order message. Match its timestamp and non-sensitive identifier to Microsoft trace data; a successful login alone does not prove Send As permission or delivery.
AIOWS cannot enable a tenant or mailbox protocol, change Security Defaults, grant Microsoft 365 permissions, or create a relay connector. Those changes belong to the tenant administrators. Remove temporary access and return to the last approved route if policy or ownership cannot be demonstrated.
Related AIOWS articles
- Microsoft 365 SMTP for WordPress: Outlook Setup Guide
- SMTP Ports 25, 465 and 587: Which One Should WordPress Use?
- How to Connect a Transactional Email Provider to WordPress SMTP
Conclusion and recommended route
The recommended route is to prove which tenant, mailbox or security rule disables the protocol, then choose the narrowest currently supported delivery method. Do not cycle passwords or relax the organization globally; verify one real event and a deliberate revocation.
