Provider guide · Outlook / Office 365
The settings are the easy half. Microsoft has spent years locking down password sign-in for SMTP, so the work is usually not in WordPress: it is a switch called Authenticated SMTP that an administrator has to allow on the mailbox.
1 · Credentials
For Microsoft 365 there is nothing to generate: WordPress signs in with the address and password of a real mailbox. What is often missing is the right to use them over SMTP.
Microsoft calls that right Authenticated SMTP, and it is switched off by default on tenants created since 2020. An administrator enables it per mailbox:
In the Microsoft 365 admin center: Users, Active users, then the mailbox WordPress will send with.
Open the Mail tab, then Manage email apps.
Save, and allow a little time to propagate.
If your organisation uses security defaults or conditional access, those block this kind of sign-in entirely, and the checkbox alone will not save you; that case belongs in the pitfalls below. A dedicated mailbox such as website@yourdomain.com is a good idea either way: the site does not break when a person leaves, and the permission is scoped to one account.
2 · In the plugin
Selecting the Outlook preset fills the server (smtp.office365.com), the port (587) and the encryption (TLS). What remains is yours.
The full address of the mailbox, website@yourdomain.com.
That mailbox’s normal sign-in password.
The same mailbox. A different From only works if the authenticated account holds Send As permission on it; otherwise Microsoft bounces the message with a permissions error.
Save, then use Send Test Email. For a personal @outlook.com or @hotmail.com address, note that Microsoft documents a different server: edit the host field to smtp-mail.outlook.com, same port, same encryption.
3 · Pitfalls
Microsoft is actively retiring this way of sending. It still works, but every pitfall below comes from that direction of travel.
This is rarely a typo. Either Authenticated SMTP is still off for the mailbox, or the tenant’s security defaults and conditional access policies block what Microsoft calls legacy authentication, SMTP included. The first has a checkbox; the second is a security policy decision for your admin, and app passwords do not get around it either.
Microsoft has announced that basic authentication for SMTP submission will be switched off by default for existing tenants at the end of 2026, re-enableable by admins for a while, with final removal to be announced. It keeps working today; just do not build a long-term plan on it, and expect the setting to need explicit re-enabling at some point.
Sending as anything other than the authenticated mailbox returns a non-delivery report with an error like “5.7.60 Client does not have permissions to send as this sender”. Either keep From identical to the username, or have your admin grant the account Send As permission on the address you want.
Client SMTP submission is capped at 30 messages per minute and 10,000 recipients per day. A burst from a busy shop can hit the per-minute ceiling and see messages throttled. For genuinely high volume, Microsoft points to its own relay options, or a transactional provider such as Brevo, Postmark or Amazon SES does the same job with less ceremony.
The email log keeps the exact error message the server returned, which is the fastest route to the cause. The documentation walks through the common ones.
There is a guide like this one for each of the twelve presets, from Gmail to Amazon SES, and the plugin takes any other SMTP server too.