Office 365 SMTP Settings: smtp.office365.com, Ports, and Authentication

The Office 365 SMTP settings for a work or school account are server smtp.office365.com, port 587, STARTTLS enabled, and the full sign-in address and password of a licensed mailbox. SMTP AUTH must be enabled for that mailbox, because Microsoft disables it by default for organizations created after January 2020. Microsoft has also announced it will retire basic (password) authentication for SMTP AUTH, so new setups should plan for OAuth 2.0. The status as of October 2, 2026 is covered below.

Office 365 SMTP settings for Microsoft 365 and Outlook.com accounts

Use these values in your app, script, printer or WordPress SMTP plugin. Sources: Microsoft Learn (work and school) and Microsoft Support (personal).

Setting	Microsoft 365 work or school	Outlook.com or Hotmail (personal)
SMTP server	smtp.office365.com	smtp-mail.outlook.com
Port	587 (recommended) or 25	587
Encryption	STARTTLS, TLS 1.2 or 1.3	STARTTLS
Authentication	Sign-in credentials of a licensed mailbox, or OAuth 2.0	OAuth 2.0 (modern auth)
Username	Full email address of the mailbox	Full email address

Two details trip people up. Microsoft says to use the DNS name, never an IP address. And if your app defaults to port 465, it does not support the TLS versions Microsoft requires for client submission. For personal accounts, Microsoft states that Outlook.com requires modern auth, and you may need an app password if sign-in fails. This post covers sending only; see IMAP vs POP3 for receiving.

Port 587 is the message submission port defined in RFC 6409, which requires authentication by default. For general tradeoffs, see port 587 vs 25. The Google equivalent is the Gmail SMTP settings.

Three ways to send through Microsoft 365, and which to pick

Microsoft documents three methods, plus a fourth for internal-only mail. The rule of thumb: use SMTP AUTH when the app can sign in, use a connector when it cannot and has a fixed IP or certificate, and use Direct Send only for internal mail from a legacy device.

	SMTP AUTH (client submission)	SMTP relay (connector)	Direct Send	High Volume Email (HVE)
Server	smtp.office365.com	Tenant MX endpoint, for example contoso-com.mail.protection.outlook.com	Tenant MX endpoint	smtp.hve.mx.microsoft
Port	587 or 25	25	25	587
Authentication	Mailbox username and password, or OAuth	Inbound connector matching a certificate or static IP	None	HVE account credentials or OAuth token
External recipients	Yes	Yes	No, rejected	No, internal only
Static IP needed	No	Yes, unless you use a certificate	Recommended, for SPF	No
Limits	10,000 recipients per day, 30 messages per minute	“Reasonable limits”, no bulk or spam	Standard anonymous throttling	No recipient or message rate limit, 50 recipients per message
Best for	Apps and scripts that can authenticate	Printers and apps that cannot authenticate	Legacy devices mailing your own staff	Internal alerts and notifications at volume

A few distinctions matter in practice:

• SMTP AUTH needs a licensed mailbox, saves to Sent Items, and works from any IP, including third-party hosting.
• SMTP relay needs no licensed mailbox and accepts any address in an accepted domain. Microsoft says it cannot be used from a third-party hosted service such as Azure.
• Direct Send behaves like anonymous internet mail, so all scanning applies. Microsoft recommends it only when a legacy device supports nothing else.
• HVE uses dedicated accounts instead of mailboxes and is billed pay as you go ($42 per million recipients, per Microsoft).

Microsoft has also added a tenant setting to block Direct Send. Per the Exchange Team Blog, Set-OrganizationConfig -RejectDirectSend $true makes Exchange Online refuse anonymous mail that uses one of your own accepted domains, returning 550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources. As of the post’s last update on May 20, 2026, the feature is in public preview and off by default, with no fixed general availability date. Legitimate senders then need a partner connector.

Basic authentication for SMTP AUTH: status as of October 2, 2026

Checked October 2, 2026 against the Exchange Team Blog and Microsoft Learn. Basic authentication for SMTP AUTH still works today. Microsoft’s revised timeline, published January 27, 2026, says:

• Now to December 2026: SMTP AUTH basic authentication behavior remains unchanged.
• End of December 2026: it will be disabled by default for existing tenants, and administrators can still enable it.
• New tenants created after December 2026: it will be unavailable by default, with OAuth as the supported method.
• Second half of 2027: Microsoft will announce the final removal date.

There has been no later announcement, and Microsoft Learn’s basic authentication page (updated July 2026) still points to that January post. Nothing is retired yet, but the default flips at the end of this year. What to do depends on the workload:

1. App that signs in as a user: switch to OAuth 2.0 with SASL XOAUTH2. Microsoft’s documented scope for SMTP AUTH is https://outlook.office.com/SMTP.Send. For service apps using the client credentials flow, the permission is SMTP.SendAsApp and the token scope is https://outlook.office365.com/.default.
2. Internal-only mail: move to High Volume Email.
3. Mail to external recipients: Microsoft recommends Azure Communication Services Email. A dedicated sending service or a connector-based relay (if the source has a static IP) are the other routes.
4. Printers and scanners that only support passwords: use SMTP relay or Direct Send, or relay through an on-premises mail server.

Basic authentication is also incompatible with Entra security defaults, so you may already be blocked.

How to enable SMTP AUTH for a mailbox

Microsoft recommends disabling SMTP AUTH organization-wide and enabling it only where needed. The per-mailbox setting overrides the tenant setting.

Admin center: open the Microsoft 365 admin center, go to Users > Active users, select the user, choose Mail, then Manage email apps, check Authenticated SMTP, and save.

PowerShell (Exchange Online):

# Enable for one mailbox (use $null to follow the tenant setting)
Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false

# Verify
Get-CASMailbox -Identity [email protected] | Format-List SmtpClientAuthenticationDisabled

# Tenant-wide: $true disables SMTP AUTH, $false enables it
Set-TransportConfig -SmtpClientAuthenticationDisabled $true

False means enabled, True disabled, blank means the tenant setting applies. If security defaults are on, SMTP AUTH is already disabled and you must turn them off to use it. An authentication policy that blocks basic auth for SMTP also overrides these settings.

Example configuration: Python with STARTTLS

Illustrative example with placeholder credentials. It works only while basic authentication is enabled for the mailbox. For OAuth, replace the login step with an XOAUTH2 token exchange.

import smtplib
import ssl
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "[email protected]"
msg["To"] = "[email protected]"
msg["Subject"] = "SMTP test"
msg.set_content("Sent through smtp.office365.com on port 587.")

context = ssl.create_default_context()
with smtplib.SMTP("smtp.office365.com", 587, timeout=30) as server:
    server.starttls(context=context)  # upgrade the connection first
    server.ehlo()                     # then say hello again, per the Python docs
    server.login("[email protected]", "app-password-here")
    server.send_message(msg)

Keep the From address the same as the mailbox you sign in with. The connection starts in plain text and upgrades with STARTTLS, so an implicit-TLS port such as 465 does not apply.

Common Office 365 SMTP errors and fixes

Error	Cause	Fix
535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant (or ...for the Mailbox)	SMTP AUTH is switched off for the organization or the mailbox	Enable it per mailbox with Set-CASMailbox, as above. Check security defaults too
535 5.7.3 Authentication unsuccessful	Wrong credentials, SMTP AUTH disabled, MFA on the mailbox, security defaults, or a Conditional Access policy that blocks legacy auth	Confirm the password in Outlook on the web, enable SMTP AUTH, exclude the mailbox from the blocking policy, or move to OAuth
5.7.57 Client not authenticated to send mail	Microsoft lists it beside 535 5.7.3 and also documents it as “Client was not authenticated to send anonymous mail during MAIL FROM” when no credentials are set	Enter mailbox credentials. If the device has no login field, use relay or Direct Send. Make sure the device negotiates TLS
5.7.60 SMTP; Client does not have permissions to send as this sender	The From address differs from the signed-in mailbox	Send from the authenticated address, or grant Send As on the other mailbox. Otherwise use SMTP relay
550 5.7.68 TenantInboundAttribution	Reject Direct Send is on and the mail is anonymous	Create a partner connector for the legitimate sender
Timeout or no connection on 587 or 25	Firewall or ISP blocks the port	Test the connection from the same network with an OpenSSL or swaks test. Microsoft notes port 25 is often blocked

For generic rejections, see 550 errors. To see where submission ends and relay begins, read how SMTP works and what an SMTP relay does.

Microsoft 365 sending limits you will hit first

Microsoft’s Exchange Online limits page lists these per-mailbox limits for sending:

• Recipient rate limit: 10,000 recipients per day.
• Message rate limit: 30 messages per minute.
• Recipient limit: customizable up to 1,000 recipients per message.
• Tenant External Recipient Rate Limit (TERRL): a daily cap on external recipients that depends on your license count. Trial tenants are capped at 5,000 external recipients per day.
• Mail from default onmicrosoft.com domains: 100 external recipients per organization per rolling 24 hours, then 550 5.7.236.

Microsoft’s own footnote says Exchange Online “isn’t suited to accommodate bulk-mailing scenarios.” Application and bulk mail belongs on a dedicated sending service, reached through an email API or SMTP credentials. Google’s caps work differently: see Gmail sending limits for comparison.

Frequently Asked Questions