SMTP relay Office 365: the three ways to send, and what changes when an agent sends

Client SMTP submission

This is the route for a device or app that can sign in as a licensed mailbox and sends modest volume. The device authenticates as that mailbox on smtp.office365.com, port 587, with STARTTLS at TLS 1.3 or 1.2, per Microsoft's device and application guide.

It can relay to the internet, so external recipients are reachable, and messages are saved to the mailbox's Sent Items.

Throughput is capped at 10,000 recipients per day and 30 messages per minute, and SMTP AUTH must be enabled on the mailbox, which Microsoft disables by default for organizations created after January 2020.

The same Microsoft guide notes that client SMTP submission with basic authentication is scheduled for deprecation and recommends modern authentication (OAuth), so a password-based setup on this path has a limited life. The port and encryption choices are covered in SMTP port numbers and SMTP over TLS.

SMTP relay via connector

This is the method the term usually refers to. The device connects to the tenant's MX endpoint, in the form yourdomain-com.mail.protection.outlook.com, on port 25, and an inbound connector in Exchange authenticates it.

The connector authenticates by TLS certificate or by static public IP address. Microsoft recommends the certificate approach, and dynamic IPs are not supported for the address-based option.

Compared with client submission, no licensed mailbox is required, the mailbox sending limits above do not apply, and mail can be sent from any address in an accepted domain even where no mailbox exists behind it.

Three constraints come with it:

• Port 25 must be open outbound, which many networks block.
• The source cannot be a third-party hosted service such as a cloud VM.
• A blocklisted sending IP disrupts mail flow directly.

An SPF record listing the sending IP is required, or messages route to Junk.

What changes when an AI agent picks the Microsoft 365 route

An agent asked to make an app send email through Microsoft 365 reads the same three options and tends to pick the one with the fewest credentials. That is usually Direct Send or a connector, and each one breaks on a fact about where agent-built code runs.

• Connector. A connector that authenticates by address is tied to a static public IP. A serverless function or a hosted container the agent deploys to has no fixed address, and Microsoft does not support dynamic IPs for that option. A certificate connector removes the IP tie, but still needs port 25 open outbound and cannot be sourced from a third-party hosted service such as a cloud VM.
• Direct Send. Direct Send, the unauthenticated port 25 route covered in the next section, only reaches recipients inside the organization. An app that emails customers, leads or partners gets every external message rejected.
• Client submission. Client submission needs a licensed mailbox and SMTP AUTH enabled on it. An agent wiring this up often puts a mailbox password into the app's config, because basic authentication is the shortest path, and Microsoft is moving that path to OAuth.

The alternative is to skip the Microsoft relay paths for application mail. An agent sends through the transactional email API or the Nitrosend MCP server from your own verified domain, so there is no connector to configure and no relay host to point one at. The email API covers the REST and SDK side, and sending email from LLMs covers the agent side. Microsoft 365 keeps the staff mailboxes, and the app's mail leaves from a separate sending subdomain.

For mail that must stay on SMTP, the mechanics of authenticating as a mailbox are in SMTP authentication for Office 365, and the general pattern of handing SMTP traffic to a provider is in SMTP relay services.

Direct Send

Direct Send also uses the MX endpoint on port 25, with no authentication and no connector.

It only delivers to recipients inside your own organization. Mail to external addresses is rejected outright, which rules it out for anything customer-facing.

Microsoft's device and application guide says most customers do not need Direct Send and that Microsoft is working on an option to disable it by default.

Choosing between them

The decision follows from three questions. Do you have a licensed mailbox to send as, is the sending host on a static IP you control, and do recipients sit outside the organization.

A licensed mailbox with modest volume points to client submission. An on-premises device with a static IP and internal-plus-external recipients points to the connector. Internal-only mail from a device that supports nothing modern points to Direct Send.

None of the three is a good fit for application mail at volume. All are designed to let an organization's own equipment send through infrastructure it already pays for, and none reports per-message delivery events, bounce classification or suppression state back to the sending application. A transactional email API sending from your own verified domain reports those events back to the app.

Worked example: an agent sends CRM follow-ups without a Microsoft 365 connector

A sales team logs every call in an internal CRM, and the company's mail runs on Microsoft 365. The prompt, in the user's words:

After each logged sales call, email the customer a short recap with the next step. Send it from the company domain, not from a salesperson's mailbox.

Before, unguided: the agent writes a job that opens port 25 to yourdomain-com.mail.protection.outlook.com from the CRM's cloud host with no authentication. That is Direct Send, so recaps to customers outside the tenant are rejected. Asked to fix it, the agent proposes an inbound connector scoped to the host's current IP, which changes on the next deploy.

After, the gated sequence:

1. nitro_get_status reads the account, its sender identity and readiness before anything is written.
2. nitro_manage_domains adds and verifies a sending subdomain such as crm.yourdomain.com, so the root domain and its mailboxes stay on Microsoft 365. Recaps arrive from an address at crm.yourdomain.com, still the company's domain and not a salesperson's mailbox.
3. nitro_manage_template creates a reusable call-recap template with fields for the contact's name, the call date and the agreed next step.
4. nitro_review_delivery checks the recap template read-only for validation errors, spam signals and readiness, and shows a preview. It sends nothing.
5. nitro_send_test_message sends one real recap to the test recipient configured on the account with nitro_configure_account, never to a customer.
6. A person on the sales team opens that test recap and confirms the wording, the From address and the next-step field before the job goes live.
7. The CRM job calls nitro_send_message once per logged call, with an idempotency_key built from the call record ID, so a retried job cannot send the same recap twice.
8. nitro_get_insights reports how the recaps perform over time, with trends, benchmarks and recommendations.

Nothing in this sequence touches an Exchange connector, a mailbox password or port 25. To run it from your own agent, connect it to the Nitrosend MCP server.

Where it goes wrong when an agent uses Microsoft 365 relay

• Direct Send used for external customers. The setup works in a test to a colleague, then every message to an outside address is rejected once real recipients arrive.
• A connector opened to a wide IP range. To get past a changing address, the agent allows a whole cloud provider block, which lets any host in that range relay through the tenant as your domain.
• A cloud function whose IP changes. The connector was scoped to the address seen on the day it was set up, and mail stops after a redeploy or a scale-out moves the job to a new address.
• SPF that does not include the sending path. The agent adds a new sending host but leaves the SPF record as Microsoft 365 had it, so messages from the new path fail SPF and route to Junk.
• Retries that produce duplicates. A job that times out on port 25 and retries from the top can deliver the same message twice, because a raw SMTP retry carries nothing to mark it as a repeat.

Go deeper