Outlook SMTP server: the two hosts, and what changes when an agent sends through them

Personal Outlook.com accounts

The outgoing server is smtp-mail.outlook.com on port 587 with STARTTLS, documented in Microsoft's settings reference.

The username is the full email address including the domain, whether that is outlook.com, hotmail.com or live.com. A local part alone is rejected.

Accounts with two-step verification enabled require an app password rather than the account password. Microsoft generates these in the account security settings, and each is scoped to the client it was created for. To see where the server name appears inside the Outlook app itself, read how to find the SMTP server in Outlook.

What changes when an AI agent sends through Outlook SMTP

An agent wiring Outlook SMTP into an app works from the same settings as the table above, but it uses them differently from a person at a mail client. Four things change.

• The mailbox credential moves into code. The account password or app password ends up in a .env file, a config file or a CI secret, and anything that can read it can send as that mailbox.
• The authentication path is shrinking. A script that logs in to smtp.office365.com with a password relies on basic authentication, which Microsoft plans to retire, as the Microsoft 365 section below explains.
• The agent sends at machine pace. An alert loop or a burst of retries reaches the sending limits below far faster than a person typing, and the throttling shows up as intermittent failures rather than a clear error.
• Replies and bounces go to a human inbox. Every bounce notice and reply lands in the Outlook mailbox the agent signed in as, and nobody is reading it on the agent's behalf.

The alternative is to send app and agent email from your own domain through a transactional email API, the Nitrosend email API or the Nitrosend MCP server, which an agent calls with named tools instead of a mailbox password. Nitrosend does not offer SMTP submission, so the move is from a mailbox login to an API key or an MCP connection. The guide to sending email from LLMs covers the same choice for model-driven apps.

Microsoft 365 work and school accounts

The outgoing server is smtp.office365.com on port 587 with STARTTLS at TLS 1.3 or 1.2, documented in Microsoft's guide for devices and applications.

Two account-level requirements sit outside the connection settings. SMTP AUTH must be enabled for the specific mailbox, and Microsoft disables it by default for organizations created after January 2020. It is enabled per mailbox in the admin center, described under authenticated client SMTP submission.

Authentication method is the larger constraint. Microsoft plans to retire basic authentication for client SMTP submission and recommends OAuth instead, with High Volume Email and Azure Communication Services as the documented alternatives for applications.

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

Sending limits

Client submission carries throttling sized for a person rather than an application. For Microsoft 365 mailboxes on smtp.office365.com, Microsoft's device and application guide sets 10,000 recipients per day and 30 messages per minute.

Exceeding those limits results in the account being throttled rather than a clear error at send time, which presents as intermittent failures that are hard to attribute.

The mailbox is also the sending identity. Mail sent this way authenticates as an individual user, so it carries that mailbox's reputation and its address appears as the sender.

Other Microsoft sending methods

Microsoft documents two alternatives to client submission, and they suit different cases.

SMTP relay uses the tenant's MX endpoint on port 25 with an inbound connector authenticating by certificate or static IP. It does not require a licensed mailbox and carries higher limits, and it cannot be used from a third-party hosted service.

Direct Send also uses the MX endpoint on port 25, unauthenticated, and can only deliver to recipients inside your own organization. Mail to external addresses is rejected.

Each Microsoft path has a catch for application mail: client submission has per-mailbox limits, relay needs a connector with a certificate or static IP, and Direct Send reaches internal recipients only. An email API that sends from your own verified domain has none of the three, and it reports each delivery, bounce and suppression, which mailbox submission does not.

Worked example: moving an agent's alerts off an Outlook mailbox

The prompt, in the user's words: "Our monitoring agent emails alerts from my Outlook account and keeps getting blocked. Move it to our domain and send me a test."

Before. The agent connects to smtp-mail.outlook.com on port 587 with the personal account password stored in a .env file. Every alert goes out as that person's mailbox, and once a burst of alerts passes the mailbox's sending limits, sends are blocked until the throttle clears.

With the Nitrosend MCP server connected, the agent works through these calls in order.

1. nitro_get_status reads the account context, sender identity and readiness.
2. nitro_manage_domains adds the team's sending domain and verifies it, so alerts come from that domain rather than a personal mailbox.
3. nitro_manage_template creates a reusable alert template with fields for the service name, the check that failed and the time.
4. nitro_review_delivery runs the read-only review of the template, with validation, spam analysis, preflight and previews. It never sends.
5. nitro_send_test_message puts one genuine send of the template in front of the test recipients named in nitro_configure_account.
6. The person who asked opens the test and confirms the alert reads correctly before any live alert goes out.
7. From then on the monitoring agent sends each alert with nitro_send_message, one transactional email per alert, and reuses the idempotency_key only for an exact retry of the same alert.
8. nitro_get_insights returns email analytics with trends, benchmarks and recommendations, so alert delivery can be checked without anyone opening an Outlook inbox.

After. Alerts go out from the team's verified domain through nitro_send_message, and no Outlook password sits in the repo.

Domain sending has limits too. A new Free account gets 5,000 non-expiring starter emails, and its allowance starts at 100 recipients per rolling 24 hours, rising with sender standing to 500 and then 5,000 (see pricing). To try the flow above, connect the Nitrosend MCP server to the agent.

Switching providers costs you a settling period

One practical consequence of changing where your mail comes from is that the large receivers need time to adjust. Moving between providers means Gmail and Outlook take a while to get used to your mail arriving from somewhere new, and delivery during that window is worse than it was before or after.

The adjustment is short, usually a message or two rather than a long degradation, but it is enough that an A/B comparison run immediately after a switch will not be meaningful. Give it a few sends before drawing conclusions about the new provider.

Nitrosend records the email stack behind every customer domain as part of onboarding, so this settling period is something the team plans for rather than discovers.

The tenant question sits underneath all of this. A Microsoft tenant provisioned for staff correspondence is not sized for application mail, and running both through it means an application send can throttle the organization's own email. Application mail sent from your own domain through the Nitrosend API stays out of the Microsoft tenant, so it cannot throttle staff email. Expect the same short settling period after that move.

Where it goes wrong when an agent uses Outlook SMTP

Each of these comes from pointing an agent at an Outlook.com or Microsoft 365 mailbox.

• The password committed to a repo. The agent writes the account password or app password into a config file, the file is committed, and anyone with the repo can send as that Outlook address until the password is revoked.
• An alert loop that throttles the mailbox. An outage trips every health check at once, the agent fires and retries dozens of alerts inside one minute, a Microsoft 365 mailbox passes the 30 messages per minute limit, and the throttle blocks the person's own mail along with the alerts.
• A From address the account cannot send as. The agent sets a team or no-reply address in the From header on smtp.office365.com while authenticating as one user's mailbox, and Microsoft rejects the message because that mailbox has no permission to send as the address.
• A retry that delivers twice. The connection times out after Outlook has already accepted the message, the agent retries, and the same alert arrives twice. SMTP submission has no idempotency key, while nitro_send_message accepts one for an exact retry.
• Bounces nobody reads. A mistyped recipient produces a bounce notice in the Outlook inbox the agent signed in as, and the agent keeps sending to the dead address.

Go deeper