Office 365 SMTP settings: choose the right Microsoft sending path

The server name is the easy part.

For most authenticated Microsoft 365 mailbox connections, it is smtp.office365.com, using port 587 with STARTTLS. But that answer is only useful after you confirm that client SMTP submission is the right path. Microsoft also documents SMTP relay, Direct Send, High Volume Email, and Azure Communication Services Email. They do different jobs.

Pick the path first. Then configure the endpoint, authentication, tenant controls, and message verification that belong to it.

Office 365 SMTP settings at a glance

Microsoft’s current documentation uses Microsoft 365 and Office 365 names across different pages. This guide is about Exchange Online business mailboxes and Microsoft’s documented application-and-device sending paths—not the consumer Outlook.com settings page.

That table is a routing aid, not a configuration you can paste into every sequencer.

If your cold-email platform offers a documented Microsoft OAuth connection, use that supported path unless you have a specific reason not to. A generic SMTP form can hide important differences in token handling, tenant policy, sent-item behavior, error visibility, and account removal.

Choose the sending path before touching the form

Use this order:

1. Identify what is sending: a user mailbox, sequencer, application, device, or server.
2. Decide whether messages must reach external recipients.
3. Confirm whether the sender can use OAuth, a mailbox credential, a certificate, or a stable public IP.
4. Check whether the operator owns the Microsoft tenant and can change Exchange Online settings.
5. Apply the endpoint for that path.
6. Send an external test and inspect the actual result.

The mistake is starting at step five.

Use client SMTP submission for a mailbox identity

Client SMTP submission authenticates through a Microsoft 365 or Office 365 mailbox. Microsoft documents smtp.office365.com, port 587 as the recommended port, and TLS/STARTTLS. The mailbox must be licensed, and the authenticated account normally appears as the sender.

This path can send to recipients inside and outside the organization. It also saves mail to the mailbox’s Sent Items folder under Microsoft’s documented behavior, which can matter when an operator needs to reconcile a platform event with mailbox history.

There are two checks before it will work:

• Is SMTP AUTH allowed for the organization?
• Is it allowed for this mailbox?

Microsoft recommends disabling SMTP AUTH across the organization and enabling it only for mailboxes that still need it. Security Defaults disables SMTP AUTH. The per-mailbox setting can override the organization-wide setting, so a tenant-level screenshot is not enough to prove the individual account is enabled.

OAuth matters here. Microsoft’s current application-sending guide says Basic-authenticated client SMTP submission is scheduled for deprecation and recommends modern authentication. Do not design a new integration around a username and password because an old setup article still shows it.

Use SMTP relay only when you control the relay prerequisites

SMTP relay uses the tenant’s MX endpoint, not smtp.office365.com. The endpoint usually looks like the MX destination published for the accepted domain. Copy it from the domain’s current DNS or Microsoft admin surface rather than constructing it from memory.

The connection is authenticated through an Exchange Online inbound connector. Microsoft documents certificate-based authentication as the recommended option, with one or more static public IP addresses as another documented route. That means the sender has to control the certificate or the unshared public IP Microsoft sees.

SMTP relay can deliver to internal and external recipients through Microsoft 365. It does not save messages to a user’s Sent Items folder. Microsoft also says relay is subject to reasonable limits and cannot be used to send spam or bulk mail.

That makes relay a poor accidental fallback for a cold-email tool that failed OAuth. If the sequencer runs on shared third-party infrastructure and cannot give you a stable IP or certificate under your control, you may not have the prerequisite needed to authenticate the connector safely.

Direct Send is internal-only

Direct Send also uses the tenant’s MX endpoint and port 25, but it does not authenticate. Microsoft treats the message as anonymous internet mail addressed to the organization.

It can reach recipients in your Microsoft 365 organization. It cannot relay through Microsoft 365 to outside recipients.

That one constraint eliminates it for normal outbound campaigns. Direct Send is useful for certain internal device notifications. It is not a workaround for an external cold-email connection.

Microsoft recommends a static IP for an SPF record and notes that standard anonymous-mail throttling applies. If you do not own the source IP or cannot describe the sending path, stop there. Adding a guessed source to SPF makes the record less trustworthy, not more functional.

High Volume Email is not “unlimited outbound”

Microsoft positions High Volume Email for high-volume internal mail. Its current comparison lists port 587, TLS, and an HVE account credential or OAuth token. The same table does not list internet relay support.

Do not read the words “high volume” and assume it is Microsoft’s recommended cold-email endpoint. Match the recipient scope and current HVE requirements first. Microsoft can change preview status, quotas, endpoints, and eligibility, so use the current HVE page for any implementation—not a copied settings table.

Azure Communication Services Email solves a different application job

Microsoft’s current guide points applications that need external delivery away from Basic-authenticated SMTP submission and toward Azure Communication Services Email. ACS Email is an application service. It is not the same as signing into a Microsoft 365 user mailbox, and it does not make a sequencer’s mailbox-connection requirements disappear.

Choose it when you are building or operating an application-mail path that fits ACS. Do not quietly swap it into a workflow that requires a real user mailbox, inbox, replies, or provider-native OAuth behavior.

The configuration record to save

Before anyone enters a password, token, IP, or hostname, create one connection record:

connection_owner:
tenant_primary_domain:
sending_domain:
sending_identity:
sending_application:
required_recipient_scope: internal | external | both
selected_microsoft_path:
endpoint_source_url:
smtp_endpoint:
port:
tls_mode:
authentication_method:
licensed_mailbox:
connector_name:
certificate_subject_or_static_ip:
smtp_auth_tenant_state:
smtp_auth_mailbox_state:
created_at:
last_verified_at:
external_test_message_id:
rollback_owner:

This does two things. It makes the setup reviewable, and it stops a future operator from treating five unrelated Microsoft settings as one mysterious password problem.

Never store the live password or token in the handoff document. Store the approved secret location and the owner who can rotate or revoke it.

Configure client SMTP submission without guessing

For a new mailbox connection, walk the checklist in order.

1. Confirm the mailbox and sender

The authenticated mailbox must exist and hold the required license. If the visible From address differs from the authenticated account, Microsoft requires the appropriate Send As permission. Without it, the connection may authenticate and still fail when it tries to send.

Record the exact mailbox, tenant, visible From domain, and person or system that owns the account. “Microsoft inbox” is not enough.

2. Confirm SMTP AUTH policy

Check both the Exchange Online organization setting and the mailbox setting. If Security Defaults is enabled, SMTP AUTH is disabled. Do not disable a tenant-wide security control just to make one legacy integration easier.

The better sequence is:

1. Confirm whether the application supports Microsoft OAuth.
2. Use the application’s documented Microsoft connection if it does.
3. If SMTP AUTH is truly required, scope enablement to the specific mailbox.
4. Record who approved the exception and when it should be reviewed.

An old mailbox that still connects does not prove the same method is acceptable for a new one.

3. Enter the endpoint exactly

Use:

server: smtp.office365.com
port: 587
encryption: STARTTLS / TLS as named by the application
authentication: OAuth where supported
username: full Microsoft 365 mailbox address

Different applications label the encryption field differently. “SSL,” “TLS,” and “STARTTLS” are not always interchangeable in a settings screen. Microsoft documents STARTTLS and current TLS support for client submission. If the tool only offers implicit SSL on port 465, do not force the settings. Confirm that tool’s Microsoft connection path.

4. Verify DNS separately

SMTP authentication and domain authentication are not the same check.

The connection can succeed while SPF, DKIM, or DMARC is wrong. It can also fail authentication while the DNS is perfect. Keep those lanes separate:

• SMTP/OAuth proves the application can submit as the account.
• SPF describes authorized sending sources for the envelope domain.
• DKIM signs the message for a domain.
• DMARC evaluates alignment with the visible From domain.

Use the SPF, DKIM, and DMARC guide for the message-level relationship. If you are configuring Microsoft DKIM, follow the tenant-specific process in the Office 365 DKIM setup guide; do not copy a generic target from another tenant.

A failure tree that starts with the evidence

“SMTP failed” is not a useful incident report. Keep the exact timestamp, application, account, endpoint, response code, and enhanced status text.

The connection times out

Check the hostname, port, DNS resolution, outbound firewall, and whether the network allows TCP 587 or 25. A timeout happens before Microsoft can reject a password or sender permission.

Do not rotate credentials yet. First prove that the application reached the endpoint.

TLS negotiation fails

Check whether the client supports the TLS versions Microsoft currently requires and whether it uses STARTTLS on the selected port. Look for an application setting that incorrectly assumes implicit SSL.

If a middlebox, proxy, or gateway intercepts the connection, capture that fact. The mailbox team cannot fix a TLS failure caused before the connection reaches Exchange Online.

Authentication fails

Confirm the full mailbox address, OAuth token scope and expiry, SMTP AUTH organization state, mailbox override, Security Defaults, and account status. A successful web login does not prove SMTP AUTH is enabled.

If the application uses a stored password, treat Microsoft’s Basic-auth deprecation as a design problem, not a temporary error message to bypass.

Authentication succeeds but Send As fails

Compare the authenticated mailbox with the From address. If they differ, verify the current Send As permission and allow time for the documented permission change to take effect. Keep the exact response instead of relabeling it “deliverability.”

Relay is denied

First confirm which path the application is using. Client submission and SMTP relay have different endpoints and authentication.

For relay, inspect the inbound connector, certificate or public IP, accepted domain, sender address, and the source Microsoft actually observed. A private IP copied from a server is not the public IP Exchange Online sees.

The message is accepted but never appears externally

Acceptance by the submission endpoint is not proof of inbox placement. Check message trace where authorized, the full SMTP response chain, recipient-side headers or rejection, and the actual recipient scope of the selected path.

If you used Direct Send or HVE for an external recipient, the path selection is the first suspect. If the path supports external recipients, continue with provider policy, message authentication, account state, and recipient evidence.

Verify a real message outside the tenant

A green connection indicator proves the application completed its own test. It does not prove the live campaign path.

Send a controlled message through the exact application, mailbox, domain, and connection intended for use. Deliver it to an external account you are authorized to inspect. Save:

• the application event or message ID;
• the Microsoft message-trace identifier when available;
• the recipient timestamp;
• the full Received chain;
• Authentication-Results;
• the DKIM-Signature d= and s= values;
• the SPF-authenticated domain;
• the visible From domain;
• the final SMTP response or folder placement observed in that test.

You are checking four separate statements:

1. The application used the intended Microsoft connection.
2. Microsoft accepted the message under the intended identity.
3. The message reached the external receiver through the path you expected.
4. SPF or DKIM aligned with the visible From domain for DMARC.

Keep the result as dated evidence. Provider controls and application connections change.

Fit SMTP into the cold-email stack

A sequencer needs more than permission to open an SMTP socket. It needs account lifecycle, reply handling, stop-on-reply behavior, error visibility, disconnection, and a clear owner when Microsoft revokes a token or restricts an account.

Before choosing manual SMTP over a supported provider connection, ask:

• Does the sequencer support Microsoft OAuth for this mailbox type?
• Where are refresh tokens stored and revoked?
• Does sent mail appear where the operator expects?
• How are replies detected?
• What exact provider errors remain visible?
• Can one mailbox be disconnected without disturbing the rest of the workspace?
• Who owns the tenant-side fix?
• What evidence survives if the sequencer is replaced?

Cheap Inboxes supports Microsoft mailboxes and documented infrastructure operations. The developer overview is the right place to inspect the current public workflow. Microsoft still owns its authentication, sending, throttling, and enforcement decisions. Buying the mailbox through an infrastructure provider does not create a different Exchange Online SMTP service.

The final handoff

The connection is ready when the next operator can answer these questions without opening a chat thread:

• Which Microsoft sending path is in use?
• Why was it chosen?
• Which mailbox, connector, certificate, or public IP authenticates it?
• Is SMTP AUTH enabled only where required?
• Does the application use OAuth?
• Can it reach the required recipient scope?
• Did a real external message pass the intended authentication checks?
• Who can revoke, rotate, reconnect, or roll back the setup?

If those answers are missing, the server field is not the problem yet. The setup is unfinished.

Sources

• Microsoft Learn: Set up a device or application to send email using Microsoft 365 or Office 365
• Microsoft Learn: Enable or disable authenticated client SMTP submission
• Microsoft Learn: Authenticate IMAP, POP, or SMTP using OAuth
• Microsoft Learn: Email authentication in Microsoft 365