term · office 365 smtp details

What are Office 365 SMTP details, and how do they affect application email?

Office 365 SMTP details are not one universal host and password. Microsoft documents several application and device patterns, including authenticated client submission through smtp.office365.com, connector-based SMTP relay through the tenant's MX endpoint, and Direct Send to internal Microsoft 365 recipients. They differ in authentication, TLS, ports, sender identity, external-recipient support, licensing, limits, and administrative setup. Choose the pattern from the workload and trust boundary, use OAuth where client submission applies, keep SMTP AUTH narrowly enabled, test exact envelope and From identities, and treat relay acceptance as separate from final delivery or inbox placement.

Office 365 SMTP details describe several routes

Microsoft 365 and Office 365 documentation distinguishes client SMTP submission, SMTP relay, and Direct Send. Client submission authenticates as an Exchange Online mailbox and sends through smtp.office365.com. SMTP relay treats the application or device as an organizational mail server and authenticates the connection with an inbound connector. Direct Send submits anonymously to the tenant's Microsoft 365 MX endpoint for recipients in the organization. These are operationally different products behind similar SMTP commands. Do not copy a hostname and port from a forum without deciding which route is intended. Record the tenant, accepted domains, administrator, workload, sender identities, source network, recipient scope, authentication method, TLS policy, volume, and failure owner first. SMTP transport does not authorize the originating business event, establish recipient consent, or make an application queue durable.

Client SMTP submission settings

Microsoft's current setup guide documents smtp.office365.com as the client-submission DNS name and says not to substitute an IP address. It recommends TCP port 587, allows port 25 in the documented scenario, and requires TLS 1.2 or TLS 1.3 with STARTTLS enabled. The application authenticates as a licensed Microsoft 365 or Office 365 mailbox and can send to internal and external recipients within the documented limits. Use the mailbox address as an explicit identity, and test Send As permissions when the visible From differs. Keep credentials or tokens in a server-side secret manager. A successful account login does not prove the visible From is allowed, the recipient is valid, or the message will reach an inbox. Client submission is a mailbox-scoped path, so user suspension, license changes, conditional-access decisions, and SMTP AUTH settings can interrupt an otherwise unchanged application.

Use OAuth and enable SMTP AUTH narrowly

Microsoft recommends Modern authentication with OAuth for client SMTP submission. Its OAuth documentation defines the SMTP.Send scope and SASL XOAUTH2 format, with delegated and application-oriented flows subject to Microsoft Entra registration and Exchange permissions. Treat access and refresh tokens as secrets, request only necessary permissions, validate tenant and mailbox binding, rotate application credentials, and remove unused grants. Microsoft also recommends disabling SMTP AUTH for the Exchange Online organization and enabling it only for mailboxes that still require it. An organization-wide setting and a per-mailbox override both exist, and the mailbox setting can take precedence. Security defaults disable SMTP AUTH. Do not disable a tenant-wide security baseline simply to preserve one legacy device. Prefer a connector, supported modern client, on-premises relay, or another documented service when the workload cannot meet OAuth and TLS requirements.

Client submission limits affect application design

Microsoft's current comparison documents client SMTP submission throttling of 10,000 recipients per day and 30 messages per minute. Treat those as current service limits that can change and may interact with other Exchange Online limits. Count recipients, not only messages, across To, Cc, Bcc, retries, and fan-out. Place application rate, tenant fairness, concurrency, attempt, and queue-age controls below the service ceiling. A shared mailbox path can create contention between human and automated use, while one credential used by many applications hides ownership. Monitor rate and recipient headroom, but never evade a limit by rotating mailboxes or sender domains. If the workload regularly approaches mailbox submission limits, evaluate connector relay, High Volume Email for eligible internal traffic, Azure Communication Services Email for application delivery, or another purpose-built transport using current Microsoft guidance.

Connector-based SMTP relay details

Microsoft 365 SMTP relay uses the tenant's MX endpoint rather than smtp.office365.com and an inbound connector that identifies the organization's sending system. Microsoft recommends authenticating the connector with a TLS certificate, with a public static IP address as another documented identity method. The application connects on TCP port 25 and can send from addresses in an accepted domain without requiring a licensed mailbox for each sender. This pattern fits controlled mail servers, appliances, or gateways with stable certificate and network ownership. It demands more administration: connector scope, certificate lifecycle, public IP changes, reverse DNS, accepted-domain policy, abuse prevention, and blocklist monitoring. Never create an open relay. Restrict which internal systems, tenants, senders, recipients, and message classes the gateway accepts. A connector recognizes the connection as organizational; it does not verify that arbitrary application input is legitimate.

Direct Send is internal-recipient delivery, not general relay

Direct Send submits to the tenant's MX endpoint as an external SMTP server without authenticating as a mailbox or connector. Microsoft documents it for delivery to recipients in the Microsoft 365 or Office 365 organization, not as a route to arbitrary external addresses. The device or application needs TCP port 25 access and should use a sender in an accepted domain. Because the path is anonymous from the internet-facing service perspective, sender reputation, DNS, source IP, and anti-spoofing decisions matter. Do not expose a Direct Send gateway to untrusted networks or use it to bypass mailbox authentication. Model nondelivery reports and support ownership because a printer or application may not receive bounce messages safely. If external delivery is required, choose client submission, connector relay, Azure Communication Services Email, or another supported method after evaluating identity and volume.

Keep envelope identity, visible From, and authentication separate

Every route carries an SMTP envelope sender and recipient commands plus RFC 5322 visible headers. The envelope sender controls transport bounces and often SPF identity; the visible From controls what readers see and is the central DMARC identity. OAuth mailbox authentication, connector identity, or source-IP acceptance does not automatically create SPF, DKIM, or DMARC alignment for every custom From domain. Inventory the exact MAIL FROM, From, Reply-To, DKIM d= domain and selector, and connecting IP on controlled received samples. Publish one valid SPF policy for the applicable domain, configure DKIM signing where supported, and evaluate DMARC alignment. Do not add a second SPF record or relax an organizational DMARC policy to repair one device. Separate Microsoft acceptance, destination-server acceptance, later bounce, mailbox filtering, inbox placement, and human action in status models.

Implement a durable application boundary

Place Microsoft 365 SMTP behind an authorized server worker or controlled relay. Persist a business event before connecting, including a stable idempotency key, tenant, message class, template revision, approved sender and recipients, consent or necessity basis, suppression state, and attempt history. Enforce per-tenant sender and recipient rules before generating SMTP commands. Bound message size, recipient fan-out, attachments, and header values. Store tokens, passwords, certificate private keys, and connector administration outside source, logs, analytics, tickets, and prompts. Set finite timeouts and classify 4xx responses as candidates for bounded retry and 5xx responses as permanent for that attempt using the complete enhanced diagnostic and Microsoft guidance. A disconnect after DATA but before the final reply is ambiguous; preserve the attempt and reconcile it before resending. SMTP has no product-level exactly-once guarantee.

Test configuration and failure modes before rollout

Use dedicated controlled recipients and a production-shaped source network. Verify DNS resolution, port reachability, STARTTLS negotiation, certificate hostname and chain, OAuth token acquisition and scope, SMTP AUTH organization and mailbox settings, Send As authorization, connector matching, accepted domains, and MX endpoint selection. Send plain text, HTML, attachment, Unicode, bounce, and expected-volume samples. Record raw headers, trusted Authentication-Results, SMTP replies, trace identifiers, and message trace evidence without retaining customer content. Negative tests should cover revoked tokens, expired connector certificates, changed public IP, disabled mailbox SMTP AUTH, Security defaults, invalid From, external recipient through Direct Send, per-minute and recipient limits, temporary deferral, permanent rejection, and connection loss around DATA. Rehearse pausing the workload and moving durable jobs without bypassing permanent policy or recipient failures.

Use current Microsoft guidance and test your tenant

Microsoft 365 SMTP configuration depends on the tenant's policies, identities, connectors, and network environment. Use current Microsoft Learn documentation and test the selected route in your tenant before relying on it for production email.

Frequently asked questions

What is the Microsoft 365 client SMTP hostname?

Microsoft currently documents smtp.office365.com for authenticated client submission and says to use the DNS name rather than a fixed service IP address.

Which port should client SMTP submission use?

Microsoft recommends TCP port 587 and documents port 25 for the supported client-submission scenario, with STARTTLS and TLS 1.2 or TLS 1.3 required.

Does Microsoft 365 client submission support OAuth?

Yes. Microsoft recommends OAuth and documents the SMTP.Send scope plus SASL XOAUTH2. Tenant registration, permissions, token custody, and mailbox binding still require careful configuration.

What is the difference between SMTP relay and Direct Send?

Connector relay authenticates an organizational mail system and can support external recipients. Direct Send uses the tenant MX endpoint without that connector and is intended for internal recipients.

Should SMTP AUTH be enabled for every mailbox?

No. Microsoft recommends disabling it organization-wide and enabling only mailboxes that still require it, while preferring modern authentication and supported alternatives.

Does Office 365 SMTP acceptance mean inbox delivery?

No. Acceptance is a scoped transport outcome. Later delivery, nondelivery, receiver filtering, mailbox-folder placement, and human engagement remain separate evidence.

Can an application use port 465 for Microsoft client submission?

Microsoft's current guide says a device defaulting to port 465 does not support the required client-submission TLS versions for this Microsoft 365 route.

Where should I verify a Microsoft 365 SMTP configuration?

Use current Microsoft Learn documentation and test the selected route in your tenant before relying on it for production email.

Sources

Continue learning

How to Evaluate an SMTP Relay ServiceEvaluate SMTP relay services by submission security, authentication, queues, retry behavior, limits, delivery events, suppression, isolation, and migration fit.Google SMTP Relay Service Evaluation GuideEvaluate Google Workspace SMTP relay by authorization model, TLS, sender identity, quotas, error handling, authentication, observability, and migration risk.SMTP Mail Protocol: How Application Email MovesLearn how SMTP submission, relay, envelopes, response codes, TLS, retries, and message content shape an application email workflow.SMTP Ports 25, 465, and 587: A Practical GuideChoose the right SMTP port by role and TLS mode, then diagnose connection, handshake, authentication, and message acceptance failures.How to Evaluate an Email Deliverability ServiceEvaluate email deliverability services by scope, evidence, authentication, feedback loops, suppressions, privacy, portability, and operational fit.