SMTP authentication Office 365: enabling SMTP AUTH, and what changes when an agent sends

Connection settings

The server is smtp.office365.com on port 587 with STARTTLS at TLS 1.3 or 1.2, per Microsoft's device and application guide.

The username is the full email address of a licensed mailbox. Client submission requires a license, so an unlicensed or shared mailbox cannot be used this way.

Port 465 is not supported on this path. Microsoft states that a device defaulting to it does not support the TLS versions required for client submission.

What changes when an AI agent asks for SMTP AUTH

When the request comes from an AI agent, an admin usually enables SMTP AUTH per mailbox for the one account the agent will send from. The credential that then authenticates, whether the mailbox password, an app password or an OAuth token, ends up in the agent's code or configuration, and the agent sends as that licensed mailbox inside its limits of 10,000 recipients per day and 30 messages per minute.

Turning SMTP AUTH on lets that mailbox sign in with a password, and Microsoft treats that basic authentication as legacy. Security defaults in Microsoft Entra ID refuse it, and accounts under multi-factor authentication need an app password that policy may prohibit. An agent built on this path depends on a timeline it does not control. A person who skims the Outlook SMTP server settings may not notice the mailbox is now open to password logins.

Nitrosend co-founder George Hartley's view is that Gmail and Microsoft are hostile to setting up multiple inboxes for agents. On this path, each mailbox an agent sends from needs a license, SMTP AUTH enabled and a stored credential. The alternative is to leave SMTP AUTH off and send app and agent mail from a verified domain through a transactional email API, the Nitrosend email API or the Nitrosend MCP server. Nitrosend has no SMTP host, so this is an API or MCP path rather than another SMTP server to configure. The guide to sending email from LLMs covers the prompting side.

Enabling SMTP AUTH when it is disabled for the tenant

When a mail client reports that SMTP client authentication is disabled for the tenant, this is the setting that is off. It exists at two levels, the tenant and the mailbox, and both must permit it.

Per mailbox, it is enabled through the Microsoft 365 admin center on the individual account, or through Exchange Online PowerShell by setting the mailbox's SMTP client authentication property. Microsoft documents the procedure under authenticated client SMTP submission.

At the organization level, a tenant-wide block can be lifted through Exchange Online PowerShell using the transport configuration setting for SMTP client authentication. Where the tenant blocks it, enabling the per-mailbox setting alone has no effect, which is the configuration that produces the most confusing failures.

Security defaults in Microsoft Entra ID also disable legacy authentication protocols, so a tenant with those enabled will refuse basic-auth SMTP regardless of either setting.

Authentication method

Basic authentication with a username and password still works on many tenants and is on a deprecation path. Microsoft recommends OAuth, carried over the XOAUTH2 mechanism, and treats basic auth as legacy.

Where multi-factor authentication applies to the account, an app password is required rather than the account password, and organizational policy may prohibit app passwords entirely.

Anything built to last should target OAuth. A working basic-auth integration today has a deadline attached to it that Microsoft rather than you controls.

Limits on this path

Client submission is throttled at 10,000 recipients per day and 30 messages per minute, per Microsoft's device and application guide. Those figures are per mailbox and sized for a person rather than an application.

Exceeding them results in throttling rather than a clear error, which presents as intermittent failures that are difficult to attribute to a quota.

Mail sent this way authenticates as one licensed mailbox and appears from that address, carrying that mailbox's reputation rather than a domain identity you manage separately.

Worked example: an agent sends invoices without turning SMTP AUTH on

Prompt: "Our finance agent needs to email invoices from accounts@ on Microsoft 365. Don't enable SMTP AUTH. Set it up another way and send me one."

Before. Given only "Email this month's invoices from accounts@ on Microsoft 365", the agent asks an admin to enable SMTP AUTH on the accounts@ mailbox, saves that mailbox's password in its config, and loops through the invoice list over smtp.office365.com on port 587, retrying any invoice that fails. Every invoice carries the mailbox's identity and counts against its per-mailbox throttle.

After. Given the prompt above, with Nitrosend over MCP, the sequence is gated:

1. nitro_get_status gets the account context, sender identity and readiness.
2. nitro_manage_domains adds and verifies the company's sending domain, so invoices authenticate as the domain rather than as the accounts@ mailbox.
3. nitro_manage_template creates a reusable invoice email template.
4. nitro_review_delivery runs a read-only review of the template with validation, spam analysis, preflight and previews. It never sends.
5. nitro_send_test_message fires the template once at the account's test recipients, which nitro_configure_account sets.
6. Person checks. Someone in finance checks that test before anything else goes out.
7. The finance app calls nitro_send_message once per invoice through the transactional API, with one idempotency_key per invoice, reused only for an exact retry of that invoice.
8. nitro_get_insights reports email analytics with trends, benchmarks and recommendations once the invoices are out.

SMTP AUTH stays disabled on the tenant and on the accounts@ mailbox throughout, and no mailbox password is stored anywhere in the agent.

Where it goes wrong when an agent uses SMTP AUTH

• Tenant-wide instead of per mailbox. SMTP AUTH is lifted through the transport configuration setting when only one mailbox needed it, which lets every mailbox use it unless it is switched off on that mailbox.
• Password in config or logs. The mailbox password or app password is written into the agent's config or echoed into its logs, where anyone who reads them can sign in as that mailbox.
• Mailbox throttle hit. An invoice or reminder run passes 10,000 recipients a day or 30 messages a minute. Microsoft throttles rather than returning a clear error, so the agent sees intermittent failures and keeps going.
• From address the mailbox cannot send as. The agent sets a From address the mailbox is not allowed to send as, and the message can be refused, because the submission authenticates as one licensed mailbox.
• Blind retries on an auth failure. When the tenant block or security defaults refuse the login, no retry succeeds, and an agent that restarts the whole batch can resend invoices that already went out before the failure.

When to use a different method

Microsoft's device and application guide documents two alternatives for higher volume. SMTP relay through an inbound connector authenticates by certificate or static IP on port 25, requires no licensed mailbox and carries higher limits, though it cannot be used from a third-party hosted service. High Volume Email covers large internal sending.

For application mail generally, a submission service authenticating as a verified sending domain avoids the license requirement, the per-mailbox throttle and the deprecation timeline, and supplies the per-message delivery events, bounce classification and suppression handling that client submission does not report.

To hand that path to an agent, connect the Nitrosend MCP server and follow the worked example above.

Go deeper