Office 365 SMTP Settings: Server, Port, TLS, Auth, and Testing

Office 365 SMTP settings usually start with smtp.office365.com, port 587, and STARTTLS. That is the right short answer for many authenticated client-submission setups, but it is not the whole setup.

Before you ship a workflow that depends on Office 365 SMTP, confirm the mailbox, tenant policy, authentication method, sender identity, TLS support, and receive-side behavior. A connection that succeeds in one tool can still fail when your app sends password resets, invoices, OTPs, or alerts.

Quick Office 365 SMTP settings

For most Office 365 and Microsoft 365 SMTP client-submission setups:

Setting	Typical value	What to verify
SMTP server	smtp.office365.com	Use the DNS name, not a hardcoded IP address
Port	587	Use port 25 only when your documented path requires it
Encryption	STARTTLS	The client must support current TLS requirements
Username	Full mailbox email address	Use the mailbox that is allowed to send
Password or token	Account-approved credential	Tenant policy may require a specific auth path
Authentication	Required for client submission	SMTP AUTH must be allowed where the account needs it
Sender address	The mailbox address or permitted Send As identity	Sender mismatch can produce bounces or relay failures

Do not treat this table as a copy-paste finish line. Office 365 SMTP failures usually come from tenant policy, mailbox-level SMTP AUTH settings, TLS support, or sender permission rather than the hostname alone.

Pick the right Microsoft 365 sending path first

Teams often search for office 365 smtp settings when they are choosing between different Microsoft mail paths. The path matters more than the port.

Mail path	Typical server	Best fit
SMTP client submission	smtp.office365.com	App, script, or device signs in as a licensed mailbox and sends as that identity
SMTP relay	Your Microsoft 365 MX endpoint	Internal systems relay through accepted-domain and connector policy
Direct Send	Your Microsoft 365 MX endpoint	Internal-only or limited unauthenticated device scenarios
API or dedicated email service	Provider-specific endpoint	App-native sending, richer events, or higher-control workflows

Use smtp.office365.com when your app or device is using authenticated client submission. For relay or Direct Send, the server is usually your domain's Microsoft 365 MX endpoint, not smtp.office365.com.

When smtp.office365.com is the right server

smtp.office365.com is the common Office 365 SMTP server when all of these are true:

• the sending account is a licensed Microsoft 365 or Office 365 mailbox
• the app, script, client, or device can authenticate
• the mailbox is allowed to use SMTP submission
• the client supports STARTTLS on port 587
• the sender address is the mailbox itself or a permitted Send As identity
• the workflow needs to send to recipients inside or outside the organization

If the device cannot authenticate, needs a different sender model, or sends from a static infrastructure path, review SMTP relay and the Microsoft 365 relay model before forcing the client-submission settings.

Port and TLS rules that matter

Use port 587 with STARTTLS as the normal Office 365 SMTP starting point.

Port details:

• 587: standard starting point for authenticated client submission through smtp.office365.com
• 25: sometimes used for documented Microsoft 365 relay or direct-send paths, but not the default app submission choice
• 465: not the normal Office 365 client-submission setting; if a device only supports implicit TLS on 465, it may not be a good fit for this path

TLS details:

• STARTTLS must be negotiated correctly before authentication.
• Old devices and libraries can fail before credentials are even checked.
• Network firewalls and proxies can block or interfere with outbound SMTP on port 587.

If the connection fails before login, fix the transport layer first. If login fails after STARTTLS succeeds, move to mailbox and tenant policy checks.

Authentication and tenant policy checks

Office 365 SMTP authentication is partly a security-policy question.

Check these items before changing passwords repeatedly:

1. The username is the full mailbox email address.
2. The mailbox is licensed and allowed to send.
3. SMTP AUTH is enabled where the mailbox still needs authenticated SMTP submission.
4. Tenant-wide policy does not block the auth method your client is using.
5. The application supports the authentication path required by your organization.
6. The sender address matches the mailbox or the account has Send As permission.
7. The workflow does not rely on an old "basic username and password always works" assumption.

Modern authentication, security defaults, and mailbox-level controls can make two visually similar Office 365 accounts behave differently. Treat authentication failures as policy evidence, not only credential mistakes.

Office 365 SMTP configuration checklist

Before you test:

1. Confirm whether the workload should use client submission, SMTP relay, Direct Send, or an API.
2. If using client submission, set the SMTP server to smtp.office365.com.
3. Use port 587 with STARTTLS.
4. Confirm the device or library supports the required TLS version.
5. Use the full mailbox address as the username.
6. Confirm the mailbox and tenant allow the selected auth method.
7. Confirm the visible From address is allowed for the mailbox.
8. Send one controlled message into a test inbox.
9. Inspect headers, authentication results, content, links, and timing before using live recipients.

Related setup guides:

• SMTP authentication guide
• SMTP server guide
• SMTP relay guide
• Office 365 DKIM setup

Common Office 365 SMTP errors

535 5.7.3 Authentication unsuccessful

Likely causes:

• SMTP AUTH is disabled for the mailbox or tenant
• the client is using an unsupported auth method
• the username is not the full mailbox address
• the mailbox credential or token path is wrong
• security policy blocks the submission

First check whether the mailbox is allowed to use SMTP AUTH and whether the app supports the required authentication model.

5.7.57 Client not authenticated to send mail

Likely causes:

• the connection did not authenticate successfully
• the mailbox or client submission path is blocked
• a relay path is being used like a mailbox submission path

Re-check account type, tenant policy, and whether the workflow should be SMTP relay instead of client submission.

TLS or connection timeout

Likely causes:

• port 587 is blocked by a firewall or proxy
• the client does not support the TLS behavior required by the service
• the app is trying implicit TLS or the wrong encryption mode
• a network proxy is treating SMTP as if it were HTTP traffic

Use a transport check before changing mailbox credentials.

Relay or sender permission failure

Likely causes:

• the app authenticates as one mailbox but sends as another address
• the sender domain is not permitted for that path
• the workload should use a connector-based relay model

Check sender identity, accepted-domain policy, and Send As permission before testing again.

Message accepted but users still do not receive it

At that point, the SMTP settings may be correct but the workflow is still not validated.

Inspect:

• SPF, DKIM, and DMARC results in received headers
• the exact From, Return-Path, and routing path
• spam or junk placement
• template links, OTP codes, and attachments
• bounce, deferral, and complaint evidence

How to test Office 365 SMTP safely

Use a two-layer test: first transport, then message outcome.

1. Run SMTP tester to check smtp.office365.com, port 587, STARTTLS, and authentication behavior.
2. Send a controlled message from the real app or device path into Email Sandbox.
3. Inspect the received copy with Email header analyzer.
4. Check sender auth with SPF checker, DKIM checker, and DMARC checker when domain alignment matters.
5. Assert links, OTP codes, invoice content, attachments, and delivery timing with Email integration testing.
6. Use email deliverability testing when a domain or routing change could affect inbox placement.
7. Review delivered HTML, links, images, and fallback text with Free Email Render before users depend on a changed template.

This prevents the common mistake of treating "SMTP login succeeded" as proof that the customer-facing email workflow works.

Office 365 SMTP vs Outlook SMTP settings

Use Outlook SMTP settings for consumer Outlook.com and Hotmail-style accounts. Use this Office 365 guide for Microsoft 365 and Office 365 work or school mailboxes where tenant policy, SMTP AUTH, relay, accepted domains, and Send As permission can affect the outcome.

If the account type is unclear, identify it first. Switching between smtp-mail.outlook.com and smtp.office365.com without checking the account family can hide the real problem.

Use MailSlurp for Office 365 SMTP validation

MailSlurp helps teams verify Office 365 SMTP-dependent workflows without turning production users into test recipients. Use SMTP tester for configuration checks, Email Sandbox for controlled message capture, and Email integration testing when the SMTP path is part of a release gate.

Create a free account at app.mailslurp.com if you want Office 365 SMTP validation available before the next rollout.

FAQ

What is the SMTP server for Office 365?

For authenticated client submission, the common server is smtp.office365.com.

What port does Office 365 SMTP use?

Use port 587 with STARTTLS for most authenticated client-submission setups.

Can Office 365 SMTP use port 465?

Port 465 is not the normal Office 365 client-submission setting. If a device or app only supports implicit TLS on 465, review whether it can support the required STARTTLS path or whether a different mail path is needed.

Why does Office 365 SMTP authentication fail?

Common causes include disabled SMTP AUTH, tenant policy restrictions, unsupported auth methods, wrong username format, missing Send As permission, or a client that fails TLS negotiation before credentials are checked.

Is Office 365 SMTP the same as Microsoft 365 SMTP relay?

No. Office 365 SMTP client submission usually uses smtp.office365.com with mailbox authentication. Microsoft 365 SMTP relay usually uses a connector and the domain's MX endpoint.

Should teams test Office 365 SMTP changes before release?

Yes. Test the transport settings first, then prove the message reaches a controlled inbox with the correct headers, content, links, and timing.

Final take

Office 365 SMTP settings are simple only at the field level. For production workflows, the safer path is to confirm the Microsoft 365 sending model, validate port and TLS behavior, verify mailbox and tenant policy, then prove the resulting message in MailSlurp before customers depend on it.