Office 365 SMTP at a glance
Office 365 uses smtp.office365.com on port 587 with STARTTLS. Authentication is per-mailbox with TLS 1.2 or TLS 1.3 required. There is no port 465 option, no IP-authenticated submission to this hostname, and Microsoft is actively retiring Basic Authentication in favor of OAuth 2.0.
If you're reading this because a printer or app is failing against Office 365, the issue is almost never the hostname. It's one of three things: SMTP AUTH is disabled on the mailbox, Basic Auth is blocked at the tenant level, or the device can't negotiate TLS 1.2. Microsoft renamed the product to Microsoft 365 in 2020, but the SMTP host stayed smtp.office365.com, so older documentation still applies to the server side even if the brand has moved on.
Step-by-step Office 365 SMTP setup
Most Office 365 SMTP setup work happens in two places: the device or app you're configuring, and the Exchange admin center where you flip the per-mailbox SMTP AUTH toggle.
1. Confirm SMTP AUTH is enabled on the mailbox
Office 365 disables SMTP submission by default for tenants created after January 2020. Sign in to the Microsoft 365 admin center, go to Users → Active users, pick the mailbox, then Mail → Manage email apps. The Authenticated SMTP toggle has to be on. The PowerShell equivalent is Set-CASMailbox -Identity user@yourdomain.com -SmtpClientAuthenticationDisabled $false.
You can also set this at the organization level with Set-TransportConfig -SmtpClientAuthenticationDisabled $false, but per-mailbox is the better pattern. Granting SMTP AUTH globally exposes every mailbox in the tenant to client submission and the credential-spray attempts that come with it.
2. Configure the device or application
- SMTP server:
smtp.office365.com - Port:
587 - Encryption: STARTTLS (TLS 1.2 or higher)
- Authentication: required
- Username: the full email address of the mailbox
- Password: the mailbox password (or, preferably, an OAuth 2.0 access token)
Microsoft's documentation is explicit that if a device defaults to port 465, it doesn't support a TLS version Office 365 accepts. The submission server only listens on 587, and only with TLS 1.2 or 1.3. Older devices that can't negotiate that are out — there's no workaround on the same host.
3. Configure incoming IMAP or POP3
For Office 365 mailboxes, IMAP runs on outlook.office365.com port 993 with SSL/TLS, and POP3 runs on outlook.office365.com port 995 with SSL/TLS. The same OAuth 2.0 / Modern Auth requirement applies to IMAP and POP3, not just SMTP. Older clients that only do Basic Auth for IMAP will fail the same way they fail for SMTP.
4. Verify the From address has Send As permission
If the application authenticates as one mailbox but sends mail with a different From address, Office 365 returns a 5.7.60 error. The auth account needs explicit Send As permission on the target mailbox. Add it via Exchange admin center or with Add-RecipientPermission. The simpler pattern is to send From the authenticated mailbox itself, which sidesteps the permission question entirely.
5. Test, watch the limits
Authenticated SMTP submission caps at 30 messages per minute and 10,000 recipients per day per mailbox. Recipients are counted, not messages — sending one email to 50 people consumes 50 of your daily allotment. The rate limit applies to sustained throughput; brief bursts above 30/minute are throttled, not refused.
Modern Auth (OAuth 2.0) vs. Basic Auth
Microsoft has been signaling the end of Basic Auth for SMTP submission for years. The current state in 2026 is that Basic Auth still works on a tenant-by-tenant basis, but new tenants block it, Security Defaults block it, and Microsoft's official guidance recommends migrating every device and application to OAuth 2.0.
The migration looks like this: register an application in Microsoft Entra ID, grant it the SMTP.Send delegated permission (or the application equivalent for daemon scenarios), have the user or service principal complete the OAuth flow to obtain an access token, and use the token in place of the password with the XOAUTH2 SASL mechanism. The SMTP host and port don't change. Only the authentication step does.
For applications that genuinely cannot move to OAuth, Microsoft now points elsewhere entirely: High Volume Email (HVE) for internal mail, Azure Communication Services Email for external mail. Continuing to rely on Basic Auth SMTP submission is a roadmap risk.
Office 365 SMTP relay vs. Direct Send
Office 365 supports three submission patterns. Knowing which you need saves a lot of debugging.
Client SMTP submission is the per-mailbox auth flow described above. Use this when a device or app needs to send as a real Office 365 user. Counts against that user's 10,000-recipient cap. Works from anywhere on the internet.
SMTP relay uses an inbound connector authenticated by TLS certificate or static public IP. The device connects to your tenant's MX endpoint (something like contoso-com.mail.protection.outlook.com) on port 25. Higher caps, no per-mailbox auth, but you need a static IP and a connector configured in Exchange admin. Right answer for high-volume LOB applications.
Direct Send is anonymous submission to your tenant's MX endpoint on port 25, no auth at all. Only delivers to recipients in your own accepted domains. Useful for legacy printers scanning to internal addresses, useless for anything that needs to reach outside the org.
Common Office 365 SMTP errors
Office 365 returns enhanced status codes that are more specific than generic SMTP responses, and they tell you exactly what to fix once you know the pattern.
5.7.57 Client not authenticated to send mail. SMTP AUTH is disabled on the mailbox or at the tenant level. Enable it per the step above. This is the single most common Office 365 SMTP error in 2026 because Microsoft made it default-off for new tenants.
5.7.60 Client doesn't have permissions to send as this sender. The authenticated mailbox is trying to send From a different address. Either change the From, or grant Send As permission on the target mailbox.
5.7.708 Access denied, traffic not accepted from this IP. Your IP is on a Microsoft-side reputation block. This usually means a previous tenant on the IP burned reputation; less commonly, your tenant is sending patterns that look like compromise. Submit a delisting request via the Office 365 anti-spam IP delist portal.
4.7.500 Server busy. Throttling. You're above the per-minute cap. Back off, retry with exponential delay, and reconsider whether mailbox-based submission is the right pattern for this workload.
Office 365 SMTP for cold email — the honest answer
Office 365 mailboxes are a perfectly reasonable origin for cold outbound. The 10,000-recipient daily cap per mailbox is more than enough for low-volume-per-inbox cold email patterns. Microsoft 365 reputation is strong. Authentication, with Modern Auth, is clean.
The catch is the same one that applies to any cold-email infrastructure decision: you don't run cold outbound from your primary business tenant. One bad campaign, one filter complaint cascade, and the reputation hit lands on the same domain your internal mail and customer billing run on. The standard pattern is a separate tenant, separate domains, separate inboxes, all isolated from the production business identity.
Inside that separate tenant, the right configuration is two to three inboxes per sending domain, 5 to 10 cold messages per day per inbox during ramp, scaling to 15-25 cold per day after the 14-day warmup period. Warmup itself runs in your sequencer (Smartlead, Instantly, EmailBison, PlusVibe), where the engagement and send-pattern data lives. The 2:1 warmup-to-cold ratio (two warmup emails for every one cold email) holds forever, not just during initial ramp.
That's the infrastructure ScaledMail provisions and monitors as a service. smtp.office365.com on port 587 is the right host. The wrong move is pointing it at your production tenant.