Microsoft 365 SMTP at a glance
Microsoft 365 uses smtp.office365.com on port 587 with STARTTLS. Yes, the host still says "office365" — Microsoft renamed the product line in 2020, but the SMTP submission server kept the original hostname. There's no separate smtp.microsoft365.com. If you searched for "Microsoft 365 SMTP settings" expecting a different value than Office 365, that's the answer: it's the same.
What did change with the rebrand isn't the hostname. It's the authentication posture. Microsoft 365 in 2026 is in the late stages of retiring Basic Authentication for SMTP submission. New tenants block it by default. Security Defaults policies block it. The official guidance is that every SMTP-sending device and application should be on OAuth 2.0 (Modern Auth) by now, and applications that genuinely can't move should switch to High Volume Email or Azure Communication Services Email instead.
If you came here from "Office 365 SMTP"
Two things to know up front. First, the product is the same. "Office 365" was Microsoft's branding from 2011 to 2020, then most plans got renamed to "Microsoft 365" to reflect that the bundle now includes Windows, Intune, and the security and compliance suite — not just Office apps and Exchange Online. The mail backend, the Exchange Online admin surface, the SMTP submission server: all unchanged.
Second, some plans kept the old name. Office 365 E1, E3, E5, and Office 365 Apps for Enterprise still exist as standalone SKUs without the Microsoft 365 bundle. SMTP-wise it doesn't matter — both Office 365 SKUs and Microsoft 365 SKUs use Exchange Online, which means both use smtp.office365.com.
Step-by-step Microsoft 365 SMTP setup
1. Confirm the mailbox can submit SMTP
Sign in to the Microsoft 365 admin center at admin.microsoft.com. Find the user, open the mailbox, and check that Authenticated SMTP is enabled under Mail → Manage email apps. Tenants created after January 2020 have this off by default. The PowerShell equivalent: Set-CASMailbox -Identity user@yourdomain.com -SmtpClientAuthenticationDisabled $false.
If your tenant has Security Defaults turned on, Basic Auth SMTP submission is blocked at the tenant level regardless of the per-mailbox setting. Either move the workload to OAuth 2.0 or, if you absolutely need Basic Auth temporarily, replace Security Defaults with explicit Conditional Access policies that allow legacy auth from specific identities.
2. Configure the application
- SMTP server:
smtp.office365.com - Port:
587 - Encryption: STARTTLS, TLS 1.2 or TLS 1.3
- Authentication: required — OAuth 2.0 if the client supports it, Basic Auth as a fallback
- Username: full email address of the mailbox
- Password: mailbox password (Basic) or OAuth access token (Modern)
Port 465 is not supported. The submission server only accepts STARTTLS on 587. Older devices that default to 465 with implicit SSL won't connect to Microsoft 365 at all on this hostname.
3. Set up Modern Auth (recommended)
The OAuth 2.0 flow for SMTP submission against Microsoft 365 is well-documented but takes more setup than Basic Auth. Three pieces:
- App registration in Entra ID. Create a new application registration. Add the
SMTP.Senddelegated permission under Microsoft Graph (or use the application permission for daemon scenarios where no user is interactive). - Token acquisition. Your application uses the standard OAuth 2.0 authorization code flow (delegated) or client credentials flow (application) to get an access token. Token lifetime is typically 60-90 minutes, so the app needs to refresh.
- SMTP submission. Connect to
smtp.office365.com:587, do the EHLO, STARTTLS, and then sendAUTH XOAUTH2with a base64-encoded blob containing the user, the access token, and required SASL framing.
4. Configure incoming mail
Microsoft 365 IMAP runs on outlook.office365.com port 993 with SSL/TLS. POP3 is the same hostname on port 995. The same Modern Auth requirement applies — IMAP and POP3 against Microsoft 365 also expect OAuth 2.0 at this point, with Basic Auth retired in stages.
The Basic Auth deprecation timeline
Microsoft has been deprecating Basic Auth in waves since 2019. The current state for SMTP AUTH submission specifically:
- Tenants created before January 2020: Basic Auth SMTP submission still works, but Microsoft is working through the long tail to disable it by default. New mailboxes in old tenants ship with SMTP AUTH disabled.
- Tenants created after January 2020: SMTP AUTH disabled by default. Admins can enable per-mailbox or per-tenant.
- Security Defaults enabled: Basic Auth SMTP submission blocked at the auth layer regardless of the per-mailbox toggle.
- End state: Microsoft has signaled that Basic Auth SMTP submission will eventually be retired entirely. The current public guidance is to migrate now rather than wait.
For applications stuck on Basic Auth with no path to OAuth — old multifunction printers, hardcoded LOB systems, third-party tools that haven't updated — Microsoft now points to two replacements rather than asking you to find a workaround. High Volume Email (HVE) handles internal mail. Azure Communication Services Email handles external mail. Both use REST APIs rather than SMTP and side-step the auth question entirely.
Sending limits and what they actually mean
Per-mailbox SMTP submission caps at 30 messages per minute and 10,000 recipients per day. The recipient count matters: an email to 50 people consumes 50 of your daily 10,000, not 1. A campaign sending to 200 people on a 10-step drip sequence eats 2,000 recipients per cycle.
The 30-per-minute cap is sustained, not burst. Brief spikes above 30 are throttled rather than refused with a hard error. Sustained throughput above 30/min triggers 4.7.500 "Server busy" responses, and the right pattern is exponential backoff rather than retrying immediately.
If your workload genuinely needs more than 10,000 recipients per day from a single source, mailbox-level SMTP submission is not the right tool. Either set up an SMTP relay with an inbound connector (certificate or static IP authenticated, much higher limits), use HVE for internal recipients, or move to a transactional email service for high-volume external mail.
Common Microsoft 365 SMTP errors
5.7.57 Client not authenticated to send mail. SMTP AUTH disabled on the mailbox. Enable it via Exchange admin or PowerShell. Single most common error in 2026 because of the post-January-2020 default.
Modern Auth library can't sign in. Confirm the app registration has the right permission (SMTP.Send), admin consent has been granted, the token includes the SMTP.Send scope, and SMTP AUTH is still enabled on the mailbox itself. Modern Auth doesn't bypass the per-mailbox toggle — it still has to be on.
5.7.708 Access denied. The submitting IP is on a reputation block. Submit a delisting request through the Microsoft 365 admin center.
STARTTLS handshake failure. The client is negotiating TLS 1.0 or 1.1, which Microsoft 365 stopped accepting. Update the client library or operating system.
Microsoft 365 SMTP for cold outreach — the honest answer
Microsoft 365 inboxes are a strong origin for cold outbound. The 10,000-recipient daily cap is generous, the reputation that comes with the M365 backbone is real, and Modern Auth makes the access pattern manageable.
What you don't do is run cold outbound from your primary Microsoft 365 tenant. The reputation cost of a single bad cold-email week lands on the same tenant as your billing, your customer service, your exec mail. The standard pattern in cold email is reputation isolation — separate tenant, separate domains, separate inboxes, treated as disposable infrastructure that gets refreshed every 12-18 months.
Within that separate tenant, the right inbox math is two to three inboxes per sending domain (each domain forwarding to your real business website), 5 to 10 cold messages per day per inbox during the 14-day ramp, then 15-25 cold per day after warmup. The 2:1 warmup-to-cold ratio holds forever — for every cold email, two warmup emails go out from the same mailbox to keep positive engagement signals dominant. That all happens inside your sequencer (Smartlead, Instantly, EmailBison, PlusVibe), not inside Microsoft 365.
ScaledMail provisions and monitors that infrastructure as a managed service: real Microsoft 365 inboxes on dedicated cold-email domains, isolated from your production tenant, ready to plug into the sequencer of your choice. smtp.office365.com:587 is the right host either way. The right tenant is the dedicated one.