The settings, from Microsoft
Microsoft publishes these values on one page and they have not moved. Here they are with Microsoft’s own wording beside each one, so you can check the source rather than take my word for it.
Office 365 SMTP settings
Client SMTP submission, one authenticated mailbox| Setting | Value | What Microsoft says |
|---|---|---|
| SMTP server | smtp.office365.com | Microsoft: “Don’t use an IP address for the Microsoft 365 or Office 365 server.” |
| TCP port | 587 or 25 | Microsoft: “587 (recommended) or port 25”. |
| Port 465 | Not supported on this path | Microsoft: a device that “recommends or defaults to TCP port 465” “doesn’t support the required versions of TLS”. |
| Encryption | STARTTLS | Microsoft: “Enabled (TLS 1.3 or TLS 1.2)”. |
| Username and password | The mailbox’s own sign-in credentials | Microsoft: “Enter the sign-in credentials of the designated mailbox.” |
| Mailbox | A licensed mailbox is required | Microsoft: “You need a licensed Microsoft 365 or Office 365 mailbox that the device uses to send email from.” |
| SMTP AUTH | Off by default | Microsoft: “SMTP AUTH is disabled for organizations created after January 2020 but you can enable it per-mailbox.” |
| Throttling | 10,000 recipients per day, 30 messages per minute | Microsoft’s published throttling limits for client SMTP submission. |
That is the configuration, and if it is all you came for you can stop here. Before you do, look at what Microsoft files it under. The article is titled How to set up a multifunction device or application, and the first example it lists is a network-connected scanner. That is the sender Microsoft had in mind for smtp.office365.com, and every constraint further down this page follows from it.
The rest of this page is about the case where the thing sending is neither a scanner nor a person. It is an application, or an AI agent writing one, running on a schedule with nobody watching. Microsoft has been closing that door deliberately, it has published the dates, and the door it points you at instead does not open where most people on this page need it to.
Why the right password still fails
This is the failure that brings most people here. Every value in the table is correct, the mailbox exists, the password is right, and the server still answers with an authentication error. The reason is that SMTP AUTH is switched off.
Microsoft is not neutral about that. Its own article on the setting says “we highly recommend that you disable SMTP AUTH in your Exchange Online organization, and enable it only for the accounts (mailboxes) that still require it”, and the setup article adds that “SMTP AUTH is disabled for organizations created after January 2020” (Microsoft Learn, Enable or disable authenticated client SMTP submission for the first, the setup article for the second). Off is the intended state, not an accident of your tenant.
Two further conditions can hold the same error in place even after somebody enables it.
- Security defaults. “If security defaults is enabled in your organization, SMTP AUTH is already disabled in Exchange Online. To use SMTP AUTH, you need to disable security defaults.” The documented route to making an SMTP client work is to switch a tenant-wide security baseline off.
- An authentication policy. “If your authentication policy disables basic authentication for SMTP, clients cannot use the SMTP AUTH protocol even if you enable the settings outlined in this article.”
Not one of those is a setting in your application. Each is a tenant-level decision taken in the Exchange admin center or in Exchange Online PowerShell, with Set-TransportConfig for the organization and Set-CASMailbox for a single mailbox. If you do not hold rights over the tenant, the fix for your integration is a support ticket to whoever does. The exact toggles and cmdlets are on SMTP authentication for Office 365.
My co-founder George wrote a line about domain verification that transfers to this exactly: “Verified” only means the DNS records are valid. It does not mean “allowed to send right now”. Being configured correctly and being permitted to send are two separate gates, and a settings table can only ever answer the first one.
The dates Microsoft has published
Most pages on this term say some version of what this page itself used to say, that Microsoft is phasing basic authentication out. That is not useful, because the phase-out has a published schedule, that schedule has been revised at least once, and the useful question is what changes and when.
Start with what has already happened. Microsoft’s deprecation article opens with “Basic authentication is now disabled in all tenants” and lists the protocols it removed: Exchange ActiveSync, POP, IMAP, Remote PowerShell, Exchange Web Services, Offline Address Book, Autodiscover, and Outlook for Windows and Mac. SMTP AUTH is not in that list. What the same article says about SMTP AUTH is narrower: “We also disabled SMTP AUTH in all tenants where it wasn’t being used.” (Microsoft Learn, Deprecation of Basic authentication in Exchange Online, last updated July 16, 2026.)
For the tenants where it is still on, the Exchange team published a revised timeline on January 27, 2026, in four lines.
SMTP AUTH basic authentication, as scheduled
Microsoft’s wording, quoted| Milestone | What Microsoft says happens |
|---|---|
| Now to December 2026 | “SMTP AUTH Basic Authentication behavior remains unchanged.” |
| End of December 2026 | “SMTP AUTH Basic Authentication will be disabled by default for existing tenants. Administrators will still be able to enable it if needed.” |
| New tenants created after December 2026 | “SMTP AUTH Basic Authentication will be unavailable by default. OAuth will be the supported authentication method.” |
| Second half of 2027 | “Microsoft will announce the final removal date for SMTP AUTH Basic Authentication.” |
Two things are worth reading off that. The final removal date does not exist yet, so what is scheduled is a default flipping rather than the protocol ending, and on an existing tenant an administrator can still switch it back on afterwards. And a tenant created in 2027 starts with no password path at all, which means the settings at the top of this page are already the legacy configuration for anybody starting fresh.
Then notice something about the source. Microsoft’s own documentation page will not carry these dates. It says “As the retirement timeline has been updated, we recommend referring to the latest official announcement for current milestones and guidance” and links out to the blog post instead. When the canonical reference declines to state a date, every date on every third-party page about this topic, this one included, is a snapshot. That is why the milestones above are quoted rather than paraphrased, and why this page carries the day they were read.
What is left, and who has to arrange it
Microsoft’s replacement for the password is OAuth, and its own article confirms that SMTP AUTH “supports modern authentication (Modern Auth) through OAuth in addition to basic authentication”. So a path remains. The question this page cares about is whether a sender with no person in it can get onto that path by itself.
Microsoft documents three flows for an SMTP AUTH connection. Two are delegated, on the permission scope https://outlook.office.com/SMTP.Send: the authorization code flow and the device authorization grant flow. Both put a human in front of a consent screen. That is a sound design for a mail client and no use at all to a process running unattended.
The third is the client credentials grant flow, and it is the only one shaped for an application. Microsoft’s own steps, in order:
- Add the
SMTP.SendAsAppapplication permission to a Microsoft Entra app registration, from the Office 365 Exchange Online API. - Obtain tenant admin consent, requesting the scope
https://outlook.office365.com/.default. - Register that application’s service principal in Exchange. Microsoft: “Once a tenant admin consents your Microsoft Entra application, they must register your Entra application’s service principal in Exchange via Exchange Online PowerShell”, using
New-ServicePrincipal. - Grant that service principal rights on the specific mailbox with
Add-MailboxPermission, plusAdd-RecipientPermissionif the application sends as a different address.
Count the actors rather than the steps. A Microsoft Entra administrator, an Exchange administrator and a PowerShell session, across two separate control planes, before a single message leaves. Worth noticing what step four grants, too: the example Microsoft gives is -AccessRights FullAccess on the mailbox (Microsoft Learn, Authenticate an IMAP, POP or SMTP connection using OAuth). The modern, recommended credential for sending one email is still a grant over the entire mailbox.
None of that is a criticism of the design. It is a mail platform, and a mail platform should make an application prove itself to an administrator before it can send as one of that organization’s people. It is an observation about fit. Every documented route to sending through smtp.office365.com terminates at somebody who is not the sender.
Where Microsoft points instead, and why it may not reach
The same article that carries the settings also carries the redirection. Under client SMTP submission it notes that the basic-auth version “is scheduled for deprecation” and recommends two alternatives, split by recipient:
- “Send email to internal recipients only: Use High Volume Email for Microsoft 365.”
- “Send email to internal and external recipients: Use Azure Communication Services Email.”
Read that split carefully if you came here to send receipts, password resets or order confirmations, because those go to customers and customers are external. High Volume Email is the successor Microsoft names for application and device mail, and its own documentation puts the recipient scope at “Internal recipients within the tenant only” and states flatly that “HVE accounts cannot be used for external email delivery”. It also will not start on its own: “Without an assigned billing policy, an HVE account cannot send email”, which means an Azure subscription attached by an administrator before the first message (Microsoft Learn, Manage High Volume Email for Microsoft 365, last updated June 2, 2026).
The other two documented methods narrow it further. SMTP relay authenticates through an inbound connector with “a certificate or static public IP address” on port 25, and Microsoft states you “can’t use SMTP relay to send email from a third-party hosted service”. Direct Send is unauthenticated on port 25 and does not relay to the internet at all. Connector setup, if the relay is the route you want, is on SMTP relay for Office 365.
Which leaves one line to pull straight off Microsoft’s own comparison table. Of the four methods it documents, client SMTP submission is the only one that both relays to the internet through Microsoft 365 and supports mail sent from an application hosted by a third party. It is also the one with the shutdown schedule on it. That is the whole problem in a sentence, and it is Microsoft’s table saying it rather than us.
The ceiling, and who it was sized for
Even while it works, client submission was never sized for an application. Microsoft’s published throttling limits for it are “10,000 recipients per day. 30 messages per minute.”, alongside the note that “Microsoft 365 or Office 365 imposes sending limits for the volume and rate of email messages from mailboxes.”
Those are mailbox numbers. They describe what one employee could plausibly send in a day, which was a sensible ceiling when the sender was one employee. A process does not get tired, does not take weekends and has no natural volume of its own. The constraint that used to hold sending down was how long it took a person to produce the mail, and for anything an agent drafts that constraint is gone. What replaces it is a decision somebody has to make on purpose, which is what email deliverability is actually about.
There is a second ceiling with no number on it. Mail through smtp.office365.com leaves as a mailbox user inside somebody’s tenant, under that tenant’s configuration and that tenant’s administrators. The standing you build there is theirs, not yours, and it does not travel with the application. A separate sending subdomain you own is the version of this that you keep.
Why we did not build an SMTP host
I should say this plainly on a page that ranks for SMTP settings. There is no Nitrosend SMTP host to point a client at. The submission surfaces we document are the REST API, the Node SDK, the MCP server and the CLI. If you came here for a host and a port to swap in for Microsoft’s, we do not have one to give you.
The reason is the shape of everything above rather than a preference about protocols. Sending through a mailbox provider’s submission endpoint means your ability to send is a setting in somebody else’s tenant. It can be off by default, it can be held off by a security baseline you did not choose, and its default has a published date on which it changes. That is a perfectly reasonable arrangement for a person’s mail client. It is a strange foundation for a feature in your product.
My own rule on the credential side is short: API keys should always be discouraged when MCP is an option. A password presented in full on every connection, and an application grant carrying FullAccess to a mailbox, are both far larger than the job of sending one message. So the two surfaces we do have are deliberately smaller. A supported client signs in once in a browser and holds no key at all, which our own reference states as “Supported remote HTTP MCP clients open a browser for Nitrosend sign-in. No API key is required for the standard Claude, ChatGPT, Cursor, Codex, Gemini, Windsurf, VS Code, or Zed setup.” An application firing a receipt sends a bearer token to POST https://api.nitrosend.com/v1/my/messages from your own verified domain, which is the email API rather than a mail conversation. The free plan is 8,000 emails up front and then 500 a month, which is enough to test the argument instead of taking it.
I am not claiming you should then leave the agent alone with it. Agents in general are not ready for “install Nitrosend skill and go ham”, and that is my read of the current state, not a marketing position. The claim here is narrower, and it is the one this page is about: acquiring the ability to send at all should not require a person with tenant administrator rights, and on Microsoft’s path it always does. The MCP server is what that looks like when the operator is a model.
Microsoft’s settings at the top of this page are correct and they will keep working for what they were built for, which is a device or a client that a person configured and a person will notice going quiet. If your sender is an application, put the end of December 2026 in the calendar, and decide now whether you want the thing your product depends on to be a toggle in a tenant you do not control.
FAQ
What are the Office 365 SMTP settings?
The server is smtp.office365.com. Microsoft documents port 587 as recommended, or port 25, with STARTTLS enabled on TLS 1.3 or TLS 1.2. Port 465 is not supported on this path. The username and password are the sign-in credentials of a licensed Microsoft 365 mailbox, and SMTP AUTH has to be enabled on it.
Why does Office 365 SMTP say authentication failed with the correct password?
Because SMTP AUTH is off. Microsoft disables it for organizations created after January 2020 and recommends disabling it organization-wide and enabling it only per mailbox. Security defaults being enabled, or an authentication policy that disables basic authentication for SMTP, will each keep the same error in place. All three are tenant-level settings an administrator has to change.
When does Microsoft turn off basic authentication for SMTP AUTH?
Microsoft published a revised timeline on January 27, 2026. Behavior is unchanged to December 2026. At the end of December 2026 it becomes disabled by default for existing tenants, with administrators still able to enable it. Tenants created after December 2026 will not have it available by default, and OAuth becomes the supported method. A final removal date is to be announced in the second half of 2027.
What is the Office 365 SMTP sending limit?
Microsoft publishes 10,000 recipients per day and 30 messages per minute for client SMTP submission. Those are mailbox limits, sized for a person rather than for an application.
What does Microsoft recommend instead of SMTP AUTH?
It depends on the recipient. Microsoft recommends High Volume Email for Microsoft 365 for internal recipients only, and Azure Communication Services Email for internal and external recipients. High Volume Email cannot be used for external email delivery, so it does not cover receipts, password resets or anything else addressed to a customer.
Does Nitrosend have SMTP settings?
No. There is no Nitrosend SMTP host to point a client at. The submission surfaces are the REST API, the Node SDK, the MCP server and the CLI. Microsoft’s settings on this page are Microsoft’s and they keep working, but the send Nitrosend takes is an authenticated HTTP call rather than an SMTP conversation.