Yes, but “Outlook” covers two very different products, and the answer depends on which one you mean. A personal Outlook.com account (the free consumer mailbox at @outlook.com, @hotmail.com, @live.com) works as an SMTP relay for a low-volume WordPress site. A Microsoft 365 business account works too, and is the correct route for any site sending mail from a custom domain, but requires OAuth rather than password auth and hits a daily recipient cap that transactional providers do not.
Personal Outlook.com is fine for a personal blog or a hobby site. Microsoft 365 is fine for a small business site whose sending volume stays inside Microsoft’s per-mailbox limits. Neither is the right choice for WooCommerce, a membership site, or anything else that needs to send transactional mail at meaningful volume.
Personal Outlook.com (free consumer accounts)
SMTP host: smtp-mail.outlook.com
Port: 587
Encryption: STARTTLS
Authentication: Your Outlook.com email address and password. If two-factor auth is enabled on the account, generate an 
app password at account.microsoft.com and use that instead of the account password.
Any mailer plugin with SMTP support handles this: WP Mail SMTP, FluentSMTP, and Post SMTP all work identically. Pick “Other SMTP”, enter the host and port above, paste the credentials, done.
The catch is authentication alignment. Mail sent through a personal Outlook.com account is DKIM-signed as outlook.com, not as your WordPress site’s domain. That means the DKIM key you publish on your own DNS is not the one signing the mail, and DMARC alignment will fail on any site that enforces it. For a personal blog where the sender is expected to be [email protected], that is fine. For a site that wants mail to look like it came from [email protected], this route is wrong: use a transactional email provider instead. See transactional email providers for the alternatives.
Microsoft 365 business accounts
SMTP host: smtp.office365.com
Port: 587
Encryption: STARTTLS
Authentication: OAuth 2.0 (recommended). SMTP AUTH with the mailbox username and password still works on existing Exchange Online tenants through the end of December 2026; after that Microsoft flips the default to off, and only tenants where a global admin has explicitly re-enabled SMTP AUTH per tenant or per mailbox keep sending. Tenants created from that point ship with SMTP AUTH unavailable at all, and Microsoft has said the final removal date (which closes the admin-enabled escape hatch on existing tenants) will be announced in the second half of 2027. Anyone setting M365 up as a WordPress relay in 2026 is choosing OAuth.
The mailer plugin has to support the OAuth flow. FluentSMTP, YaySMTP, and Meow Mailer handle Microsoft 365 OAuth in their free plugins. WP Mail SMTP and Post SMTP both keep it behind their paid tiers: WP Mail SMTP Pro, and the Post SMTP Pro extension. The free plugins and the manual Pro setups need an app registered in Microsoft’s Entra ID (Azure AD) portal, and the plugin’s documentation walks the specific fields. The One-Click setups in WP Mail SMTP Pro and Post SMTP’s Business plan sign in through the vendor’s own app instead, which a tenant admin may still have to approve. See the Microsoft 365 review for the entity overview and the WordPress SMTP with Microsoft 365 guide for the full setup. If the site is currently sending over M365 with a mailbox password and the error string 550 5.7.30 Basic authentication is not supported for Client Submission has started appearing in the mailer plugin’s log, Microsoft 365 is disabling password SMTP is the migration-triage hub that routes to the right per-plugin migration path.
Microsoft 365 can DKIM-sign mail from your custom domain against that domain once custom-domain DKIM is enabled in the Defender portal. That DKIM signature aligns when its signing domain aligns with the message’s From domain under the domain’s DMARC alignment mode. Until then Microsoft doesn’t DKIM-sign custom-domain mail at all (
Microsoft Learn). The failure mode here is not authentication but capacity: a Microsoft 365 mailbox is limited to 10,000 recipients per day at a rate of 30 messages per minute. That ceiling covers a small business site sending admin alerts and password resets. It does not cover a WooCommerce store on Black Friday.
Neither is the right tool for high-volume transactional mail
The pattern of using a human mailbox (personal Outlook.com, Microsoft 365, Google Workspace, or otherwise) as the relay for a WordPress site’s outbound mail works technically and fails at scale. Two failure modes recur:
- Rate limits. Personal Outlook.com throttles messages after a few hundred a day. Microsoft 365 caps at 10,000. A busy site hits these limits and the SMTP connection starts returning throttling errors instead of accepting messages.
- Mixed content. The same mailbox is now handling both the human’s inbox mail and the site’s transactional mail. Bounces from a bad WordPress recipient list end up in the same reputation bucket as the human’s normal correspondence, and a mail-service reputation problem on the site starts affecting the human’s ability to send email.
For any WordPress site sending more than a few hundred messages a month, a transactional provider (Postmark, SMTP2GO, Amazon SES, Brevo) is the correct route. See What is the best way to set up email on WordPress? for the setup that scales.
Corrections
- 2026-10-30: an earlier version said Microsoft 365 mailboxes on a custom domain are DKIM-signed against it by default; Microsoft signs custom-domain mail only after custom-domain DKIM is enabled.
- 2026-10-19: an earlier version said Post SMTP handles Microsoft 365 OAuth on its free tier; Post SMTP 4.0.2 puts the Microsoft 365 connection in its paid Pro extension.