Office 365 SMTP Settings: Config, the SMTP AUTH Gotcha, and Volume
Office 365 SMTP settings
To send through a Microsoft 365 / Outlook mailbox, configure your app, device, or client with these:
- SMTP server:
smtp.office365.com - Port:
587 - Encryption: STARTTLS (also written as TLS)
- Authentication: required
- Username: the full mailbox address
- Password: the mailbox password (or an app password if MFA is enabled)
This is client submission: one authenticated mailbox sending its own mail. It's what you want for a desktop client, a helpdesk "send as", a WordPress contact form, or a scanner that emails documents.
The gotcha that stops most setups: SMTP AUTH is off
Here's the one that costs people an afternoon. Microsoft disables SMTP AUTH by default on new tenants and on many individual mailboxes, as a security baseline. So you enter every setting correctly and still get an authentication error.
The fix isn't a setting on your end. An admin has to enable SMTP AUTH, either org-wide or per mailbox, in the Microsoft 365 admin center or via PowerShell. If you don't control the tenant, this is a ticket to whoever does. Nothing you paste into your app will work until that switch is flipped.
Two more that bite:
- Basic auth is being retired. Microsoft has been phasing out basic authentication for client submission. Where it's already off, SMTP AUTH won't work at all and you need a different path (below).
- MFA on the mailbox means the plain password is rejected. Generate an app password or use OAuth.
What Office 365 SMTP is not built for
Client submission is throttled by design. Microsoft caps it around 30 messages a minute and 10,000 recipients a day, and it's meant for a person's mail, not an application's. The moment you're sending transactional volume, receipts, confirmations, alerts, from your own product, you're using the wrong door.
Microsoft's own answer for app sending is high-volume email or a connector, both of which mean leaving the simple smtp.office365.com path and taking on tenant configuration, throttling rules, and reputation management on infrastructure you don't tune.
Volume without the tenant headaches
I've spent ten years inside email sending, and the Office 365 volume story is the same one every mailbox tells: fine until you scale, then a maze of admin toggles and rate limits.
We built Nitrosend so the volume question isn't yours to solve. On a warmed, trusted domain we clear about half a million messages in roughly ninety minutes at the current provider ceiling, streaming in continuous blocks of 10,000. The send bounds move with your domain's reputation, not a fixed tenant cap, and the whole thing runs from your AI agent with a human approving the send. No admin center, no PowerShell, no SMTP AUTH toggle.
Office 365 SMTP is the right tool for one person's mail. For a product's mail, the settings table above is a detour.
The faster path
If you're setting up Office 365 SMTP because an app or agent needs to send, connect an account from inside Claude, Codex, or Cursor and send your first 8,000 emails from a shared sandbox, no tenant config required. Verify your own sending domain when you're ready, and the volume scales with your reputation instead of a mailbox cap.
FAQ
What are the Office 365 SMTP settings?
Server smtp.office365.com, port 587, STARTTLS encryption, authentication on, username is the full mailbox address, password is the mailbox password or an app password when MFA is enabled.
Why does Office 365 SMTP say authentication failed even with the right password?
Microsoft disables SMTP AUTH by default. An admin has to enable it org-wide or per mailbox in the admin center or via PowerShell before client submission will work.
What is the Office 365 SMTP sending limit?
Client submission is capped around 30 messages per minute and 10,000 recipients per day. It's built for a person's mail, not application volume.
How do I send high-volume email from Microsoft 365?
Microsoft points you at high-volume email or a connector, both of which add tenant configuration. For product sending, a dedicated service with your own authenticated domain is simpler and scales with reputation rather than a fixed cap.