Office 365 SMTP Settings: Host, Port, and Authentication

Do not index

Microsoft 365 SMTP uses smtp.office365.com, port 587, with STARTTLS. Incoming IMAP uses outlook.office365.com, port 993, with SSL/TLS.

A printer that connects but won't send, or an email app that repeatedly requests credentials, often needs more than corrected server values. The deciding checks are whether the mailbox permits the protocol, whether the client supports the required encryption, and whether Microsoft 365 accepts its authentication method.

Table of Contents

Microsoft 365 SMTP and IMAP Settings at a Glance What must be enabled before sending?How to Configure an App, Printer, or Device How should an email app be configured?What changes for printers and scripts?OAuth vs App Password for SMTP Authentication When should an administrator choose OAuth?Can an app password fix a legacy device?Common SMTP Errors and How to Fix Them What should each error trigger?How should the failure be isolated?How to Verify Your SMTP and IMAP Setup with mailX How to verify it for outgoing mail How to verify it for incoming mail SMTP AUTH, SPF, DKIM, and DMARC Working Together Which control answers which question?What should be checked after submission works?Common Configuration Mistakes to Avoid Which mistakes belong to which tool?How to verify it Frequently Asked Questions About Microsoft 365 SMTP Does Microsoft 365 SMTP work on port 465?What happens when Security Defaults disable SMTP AUTH?How do Microsoft 365 sending limits affect applications?Do these settings apply to Outlook.com personal accounts?

Microsoft 365 SMTP and IMAP Settings at a Glance

The following Office 365 SMTP settings apply to authenticated client submission through Microsoft 365. SMTP handles outgoing messages; IMAP provides incoming mailbox access.

For SMTP, the username is generally the full Microsoft 365 mailbox address. The configured sender must also comply with Exchange Online permissions. Authenticating as a mailbox doesn't automatically grant permission to send as another address.

Microsoft distinguishes authenticated submission from SMTP relay and Direct Send. Relay and Direct Send use a different configuration model, normally involving port 25; Direct Send is intended for recipients within the organization, while relay can use a trusted connector or static public IP. These distinctions and the submission values appear in Microsoft's device and application configuration guidance.

What must be enabled before sending?

SMTP AUTH must be permitted by the effective organization configuration and enabled for the intended mailbox. An administrator should inspect both scopes rather than assume that successful webmail access proves SMTP access.

The practical configuration checklist is:

Mailbox identity: Use the full mailbox address, not a display name.

Protocol permission: Confirm that Authenticated SMTP is allowed for the mailbox.

Organization policy: Check that security settings and authentication policies permit the chosen method.

Sender permission: Match the sender to the authenticated mailbox or confirm the required Exchange Online permission.

For administrators connecting mail to a website or business application, Kogifi's explanation of how Microsoft 365 integrates with DXPs provides useful integration context. The application's broader integration doesn't replace these mailbox-level checks.

How to verify it: Use the outgoing server settings finder to check the provider profile. Matching server and encryption values is a good configuration baseline; a mismatch means the application may be using settings for a different service. Server discovery alone doesn't verify mailbox authentication.

How to Configure an App, Printer, or Device

Configure the transport first, then select an authentication method the client supports. A device's generic “TLS” checkbox isn't enough evidence that its SMTP implementation matches Microsoft 365 requirements.

How should an email app be configured?

When manually configuring an IMAP account in an email app, enter the incoming and outgoing values from the settings table separately. Enable outgoing-server authentication and choose the application's Microsoft sign-in or OAuth option when available.

A working incoming connection doesn't establish that outgoing authentication works. Treat sending and receiving as separate tests, even when both use the same mailbox identity.

For a small-business account deployment, Networking2000's practical email setup for small businesses offers additional setup context. Current Microsoft authentication requirements should still govern the final configuration.

What changes for printers and scripts?

For a printer or scanner, open the device's outgoing email settings and select authenticated submission, not an unauthenticated relay profile. Enter the submission endpoint, enable STARTTLS, configure the mailbox identity, and check whether the device supports OAuth.

For a custom application, configure the SMTP library explicitly:

Transport: Select the documented submission endpoint and STARTTLS mode.

Authentication: Use the supported OAuth mechanism rather than assuming a password-based login remains available.

Sender: Use the authenticated mailbox identity unless another sender has been authorized.

Logging: Capture the server response and failure stage without recording credentials or tokens.

The expected SMTP sequence is a connection, EHLO, STARTTLS negotiation, and then authentication. Credentials must not be sent before the encrypted session is established.

Microsoft requires TLS 1.2 or TLS 1.3 for standard client submission, as documented in its current SMTP client requirements. A client that can't negotiate a supported version needs an update, replacement, or a separately designed supported sending route.

How to verify it: Run the mailX SMTP test after saving the settings, then send from the actual device. Successful TLS negotiation and accepted authentication are positive results; a timeout, certificate failure, or authentication rejection identifies a different troubleshooting layer. A remote test doesn't replace testing from the printer's own network.

OAuth vs App Password for SMTP Authentication

OAuth and app passwords aren't interchangeable authentication mechanisms. OAuth uses tokens; an app password is still a password-based credential and doesn't bypass a policy that blocks Basic authentication.

When should an administrator choose OAuth?

For a new application, choose a library that supports Microsoft authentication rather than designing around a stored mailbox password. Token acquisition, permissions, and renewal must be part of the application design, not an afterthought after the SMTP connection succeeds.

For an existing application, inspect what its “Microsoft 365” authentication option does. A provider label doesn't prove OAuth support; a configuration screen that only accepts a username and password needs closer investigation.

Can an app password fix a legacy device?

An app password is only a possible option when the account configuration allows it and Microsoft still accepts the relevant password-based authentication path. Its absence isn't automatically a fault, and generating another secret won't repair a tenant-level protocol restriction.

Microsoft is retiring Basic authentication for SMTP AUTH. Administrators should check the current status on Microsoft Learn before committing to a legacy workaround, rather than relying on an old retirement date or assuming a previously working configuration remains supported.

The comparison graphic is a conceptual overview, not evidence that app passwords are available in a particular tenant. Actual availability depends on the account and current Microsoft policy.

How to verify it: Use the mailX SMTP test only with authentication methods the tool explicitly supports. A successful password-based test doesn't validate an application's OAuth implementation; the application must also acquire its token and authenticate successfully through its own configured flow.

Common SMTP Errors and How to Fix Them

Read the complete SMTP response, not just the enhanced status code. The same visible failure category can require different fixes depending on the accompanying text, authentication method, and tenant configuration.

What should each error trigger?

The graphic summarizes troubleshooting categories. Its connector suggestion isn't a universal fix for an authentication rejection. Creating a relay connector changes the sending architecture; it isn't a substitute for fixing authenticated client submission.

Microsoft states that Security Defaults disable SMTP AUTH in Exchange Online. An authentication policy can also block Basic authentication even when the mailbox's SMTP setting appears enabled, as explained in Microsoft's authenticated SMTP policy documentation.

How should the failure be isolated?

Start with the earliest failed stage:

No connection: Investigate endpoint selection, DNS resolution, and the network path.

TLS failure: Inspect STARTTLS support, certificate validation, and client compatibility.

Authentication rejection: Review the full username, supported authentication method, mailbox permission, and security policy.

Sender rejection after login: Check whether the authenticated account is allowed to use the configured sender.

A generic authentication failure doesn't prove a bad password. Conversely, a correct password doesn't prove that a tenant permits the protocol or authentication mechanism.

The mailX SMTP test can expose the server's response and the stage that fails. It cannot inspect an organization's private administrative policies or identify a particular security rule from a status code alone.

How to verify it: Repeat the same test after changing only the identified cause. A positive result advances beyond the previous failure stage; an unchanged rejection means the administrator should revisit the effective policy or client authentication path instead of making unrelated DNS changes.

How to Verify Your SMTP and IMAP Setup with mailX

Verification should separate server reachability, encrypted transport, authentication, and actual mailbox operation. A single successful connection doesn't prove every layer works.

How to verify it for outgoing mail

Open the mailX SMTP test and enter the Microsoft 365 submission settings. Use credentials only for a mailbox under the administrator's control, and only where the offered authentication method matches the intended test.

The toolkit uses supplied credentials for testing and doesn't store them. Credentials and tokens should still be excluded from screenshots, support tickets, and shared diagnostic logs.

Interpret the result by stage:

Connection succeeds: The test environment reached the endpoint. The application's own firewall path still needs checking.

STARTTLS succeeds: The endpoint and test client established encrypted transport. The original device may still have a different TLS capability.

Authentication succeeds: The supplied identity and method were accepted for that session.

Submission succeeds: Confirm the recipient received the message and inspect any subsequent failure report.

A timeout is a transport problem until evidence indicates otherwise. An authentication rejection after successful TLS negotiation calls for identity and policy checks, not a different encryption setting.

How to verify it for incoming mail

Run the incoming mailbox connection check with the IMAP values from the opening table. Confirm both encrypted connectivity and, where supported by the test, mailbox authentication.

A successful IMAP connection confirms incoming access for the tested method. It doesn't confirm outgoing submission, and successful SMTP authentication doesn't establish that IMAP is enabled or accepted.

The final verification belongs in the configured client: send a message, receive a message, and confirm the intended mailbox and sender identity. Save the non-sensitive result and configuration details so a later failure can be compared against a known working state.

SMTP AUTH, SPF, DKIM, and DMARC Working Together

SMTP AUTH authenticates the submitting client. SPF, DKIM, and DMARC address domain authentication for messages after submission. These are related controls, but they don't repair the same failures.

An application can authenticate successfully while sending messages with a domain-authentication problem. Equally, valid domain records won't enable a disabled mailbox protocol or make an unsupported login method work.

Which control answers which question?

The troubleshooting boundary matters. A connection that fails before authentication calls for transport or account investigation; a message accepted for submission but later rejected or filtered may require inspection of message authentication and recipient-side handling.

The sender identity deserves particular attention. Exchange Online permissions determine whether the authenticated mailbox may submit using another sender, while domain authentication concerns the identities that appear on the resulting message.

What should be checked after submission works?

Use a received message, not just a saved application configuration, to inspect the actual sending identity. Then compare the authentication results with the intended domain configuration.

SPF: Confirm that the published policy represents every legitimate sending route without conflicting records.

DKIM: Verify the selector used by the message rather than guessing a selector name.

DMARC: Check alignment with the visible From domain and review the published policy.

How to verify it: Run the mailX SPF checker, followed by the DKIM checker and DMARC checker as needed. A valid published configuration is a useful result; missing or conflicting records indicate domain work remains. No DNS-only check proves that an application authenticated successfully or that a recipient will place its message in the inbox.

Common Configuration Mistakes to Avoid

Configuration mistakes should be corrected at the layer where they occur. DNS edits won't fix a TLS handshake, and a new mailbox password won't correct a published record.

Which mistakes belong to which tool?

Duplicate SPF records: Multiple SPF policies can create an authentication error. The mailX SPF checker identifies the conflict; consolidate legitimate sending sources into a single policy.

Excessive SPF lookups: Exceeding the 10-DNS-lookup limit can invalidate SPF evaluation. The SPF checker helps identify lookup-heavy dependencies; remove obsolete sending routes and simplify the policy carefully.

Wrong DKIM selector: Testing an unrelated selector can make a valid configuration appear missing. The mailX DKIM checker helps inspect selectors; compare the result with the selector in an actual sent message.

Wrong record type: Publishing a CNAME where TXT is required prevents the intended lookup. The mailX TXT lookup and CNAME lookup reveal the published type. Follow the exact provider requirement, since Microsoft 365 DKIM configuration can legitimately require CNAME records.

Wrong port and encryption pair: Implicit TLS and STARTTLS aren't interchangeable. The SMTP test reveals negotiation failures; select the documented pair instead of cycling through combinations.

Missing app password where applicable: A legacy client may reject the ordinary account credential when its configuration requires a different credential. The SMTP test can reveal rejection, but only account administration can confirm whether app passwords are available or appropriate.

How to verify it

Re-run the tool that exposed the original fault, then repeat the client operation as originally intended. A corrected record should resolve with the required type and value; a corrected SMTP configuration should advance through encryption and authentication.

Avoid treating every failure as a DNS problem. Record tools validate published data, while connection tools test protocol behavior, and neither substitutes for inspecting Microsoft 365 administrative policy.

Frequently Asked Questions About Microsoft 365 SMTP

Does Microsoft 365 SMTP work on port 465?

Port 465 implicit TLS shouldn't be treated as interchangeable with Microsoft's documented client-submission profile. The appropriate baseline is the STARTTLS configuration in the opening table. If an application defaults to an implicit-TLS option, the administrator should select the documented mode rather than assuming that every encrypted SMTP setting is equivalent.

What happens when Security Defaults disable SMTP AUTH?

A mailbox-level checkbox alone may not resolve the restriction. An administrator must review the effective security configuration and choose a supported authentication or sending design. Disabling organization-wide protections merely to accommodate a legacy printer is a broader security decision, not a routine password fix, and should undergo the organization's normal review.

How do Microsoft 365 sending limits affect applications?

Microsoft lists 30 messages per minute and 10,000 recipients per day, per user, for SMTP AUTH in its outbound sending-limit guidance. Applications should queue bursts, pace submission, and retry throttled work appropriately. Successful authentication doesn't make the transport unlimited, and bulk workloads need a suitable sending architecture.

Do these settings apply to Outlook.com personal accounts?

This page covers Microsoft 365 organizational mailboxes in Exchange Online. The Outlook application name doesn't identify the underlying account service. A personal Outlook.com account should use the current settings and authentication requirements documented for that service rather than inheriting organizational SMTP AUTH instructions merely because both accounts appear in Outlook.

mailX provides free SMTP and IMAP diagnostics, live email-authentication checks, and plain-English explanations without signup. Visit mailX to verify the failing connection first, then check domain authentication once Microsoft 365 accepts the submission.