Office 365 SMTP settings, why SMTP AUTH is disabled by default, and what that means for agent-written code

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 each value can be checked against the source.

Look at what Microsoft files these settings 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 is switching the password path off on published dates, and the replacement it names for application mail cannot send to customers.

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.

Three 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.”
• A mailbox-level setting. Microsoft’s per-mailbox setting overrides the organization-wide one, so SMTP AUTH enabled for the organization still fails on a mailbox where it has been disabled individually.

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.

What an agent does differently with Office 365 SMTP

A person configures smtp.office365.com once in a mail client or on a scanner and notices when it stops. An AI agent or a coding assistant asked to send email from an app writes the connection into code, usually as basic-auth SMTP with a username and a password, because that is the shape of most of the examples it learned from. It then runs that code on a schedule nobody watches and retries when the server says no.

That snippet is the exact path Microsoft is closing. A password presented on port 587 works only while SMTP AUTH is enabled for the mailbox, security defaults are off and no authentication policy blocks basic authentication for SMTP. From the end of December 2026, basic authentication for SMTP AUTH is disabled by default for existing tenants (the published dates).

The supported replacement is OAuth, and that is where the agent stops. The only flow shaped for an application needs a tenant administrator to grant consent and register the application in Exchange, as the steps in who has to arrange it show. An agent can write the token request. It cannot grant consent on a tenant it does not administer, and that human step is there by design.

Nitrosend co-founder George Hartley has described Gmail and Microsoft as hostile to external agents, pointing to aggressive bot detection and to there being no way for an agent to hold its own address on either platform. An agent sending through an Office 365 mailbox is borrowing a person’s sign-in, identity and sending allowance. Personal Outlook.com and Hotmail accounts are covered on Hotmail SMTP settings.

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.

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.

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 conclusion comes from Microsoft’s own table.

Worked example: moving app mail to a verified domain

The prompt, in the user’s words: “Our app mail goes through an Office 365 mailbox with a password in a script. Move it.”

Before. Unguided, an agent keeps the shape it found. The mailbox password stays in the script, the code keeps connecting to smtp.office365.com on port 587, and when authentication fails the agent rewrites the same basic-auth login or wraps a retry around it. Sending still depends on a setting in the tenant, and the end of December 2026 still flips the default.

After. With the Nitrosend MCP server connected, the agent works through the calls in this order:

1. nitro_get_status gets the current account context, sender identity and readiness, so the agent knows what is already set up.
2. nitro_manage_domains adds and verifies a customer sending domain, a subdomain you own, in place of the Office 365 mailbox.
3. nitro_manage_template creates a reusable email template for the message the script used to send.
4. nitro_review_delivery reviews that template without changing or sending it, through validation, spam analysis, preflight and previews. It never approves or sends.
5. nitro_send_test_message sends one real email test for the template. It never sends to an audience. A person reads the test email before anything goes live.
6. nitro_send_message sends one transactional email now, with an idempotency_key that is reused only for an exact retry. In the app, the script makes the same kind of send through the transactional email API with an API key in place of the mailbox password.
7. nitro_get_insights gets email analytics once the first real messages have gone out, so the agent can confirm the new path is sending.

The end state is a verified domain and an API key that belongs to the application, with no mailbox password in the script. The Office 365 mailbox goes back to being a person’s mailbox, and whoever administers the tenant can switch SMTP AUTH off on it again, which is the state Microsoft recommends.

Where it goes wrong when an agent uses Office 365 SMTP

The settings table stops at the connection. These are the ways an agent-built sender on smtp.office365.com breaks, usually with nobody watching when it does.

• Stale auth code. The agent writes basic-auth SMTP from old examples. It works on a tenant where SMTP AUTH is still enabled and fails with an authentication error on one where it is not, and after the end of December 2026 the default on existing tenants is off. The code did not change. The tenant did.
• A shared mailbox password in a script. To send as a team address, the agent wires that mailbox’s sign-in credentials into a script, a .env file or a CI variable. Anyone who can read the repository or the log can then sign in as that mailbox, and rotating the password breaks every other integration that uses it.
• Retries that send twice. An agent that reads an SMTP error or a timeout as a reason to try again can deliver the same receipt twice, because a plain SMTP send carries no idempotency key to tell a retry from a new message.
• Volume ceilings sized for a person. A loop, a backfill or a batch the agent runs at once reaches the mailbox limits long before a person would, and everything else sending from that mailbox stops with it (the ceiling below).
• The mailbox account gets flagged. Mail sent this way leaves as one user inside the tenant. A mailbox that exceeds Microsoft’s sending limits can be restricted from sending, and the person whose mailbox it is loses their own outgoing mail along with the application’s.

A person meets any of these as an error in a mail client and fixes it once. An unattended sender meets an authentication failure or a throttling response on a connection nobody is watching, and an agent may retry it, log it or swallow it.

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:

1. Add the SMTP.SendAsApp application permission to a Microsoft Entra app registration, from the Office 365 Exchange Online API.
2. Obtain tenant admin consent, requesting the scope https://outlook.office365.com/.default.
3. 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.
4. Grant that service principal rights on the specific mailbox with Add-MailboxPermission, plus Add-RecipientPermission if 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.

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. For scale, a warmed, trusted domain on Nitrosend clears half a million messages in about an hour and a half, and that send is bound by the wire, not by our system. 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 Nitrosend has no SMTP host

There is no Nitrosend SMTP host to point a client at. The documented submission surfaces are the REST API, the Node SDK, the MCP server and the CLI, so there is no host and port here to swap in for Microsoft’s.

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.

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. Nitrosend’s two surfaces are deliberately smaller. A supported client signs in once in a browser and holds no key at all, which Nitrosend’s 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 5,000 emails up front and then 500 a month, which is enough to test the argument instead of taking it.

The claim here is narrow: 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

Go deeper