Office 365 & Outlook SMTP test — ports & modern auth

Microsoft 365 (formerly Office 365) and Outlook.com share the same SMTP submission endpoint: smtp.office365.com on port 587 with STARTTLS. The SMTP username is your full email address, and the password depends on your tenant's authentication policy: either an app password or an OAuth2 token.

Unlike most providers, Microsoft 365 has no implicit TLS port for client submission. Port 465 does not work, and port 25 is reserved for inbound mail flow between servers. Every client submission goes through port 587 and upgrades to TLS with the STARTTLS command after the initial greeting. If your mail client or library tries 465 with implicit TLS, the connection fails before any authentication happens.

Recommended settings

Two details trip people up:

• The username is always the full UPN or primary SMTP address, never just the local part.
• The From address must match the authenticated mailbox unless Send As permission is configured, and Microsoft enforces this on every submission.

Basic auth is off by default

This is the single biggest difference between testing Microsoft 365 and testing Gmail or a transactional provider. Microsoft started disabling basic authentication (username plus password) across Exchange Online tenants in late 2022. In most tenants created today, SMTP AUTH with a plain password is disabled at the tenant level from the start.

What that means in practice:

• Basic auth (account password): disabled by default in most tenants. An admin can re-enable it, but Microsoft positions this as a short-term compatibility measure only.
• App passwords: available only when the mailbox has multi-factor authentication (MFA) enabled and the admin has not blocked app password creation. App passwords are themselves considered legacy auth and can be blocked by Conditional Access policies.
• OAuth2 (XOAUTH2): the long-term path. It requires registering an application in Microsoft Entra ID (formerly Azure AD) and obtaining access tokens with the SMTP.Send scope. SMTP Tester does not support OAuth2, but it remains useful for verifying the TLS handshake and diagnosing permission errors that OAuth2 setups also hit.

SMTP AUTH must be allowed twice: once for the tenant and once for the mailbox. The tenant-wide toggle lives in the Microsoft 365 admin center under the mail flow settings. The per-mailbox toggle lives in the Exchange admin center: open the mailbox, edit its email apps settings, and enable the Authenticated SMTP option. If either is off, password-based SMTP login fails regardless of credential correctness.

An admin can check the mailbox-level state with Exchange Online PowerShell:

Get-CASMailbox -Identity user@company.com | Select SmtpClientAuthenticationDisabled

If the value is True, SMTP AUTH with username/password is blocked for that mailbox. The tenant-level equivalent is Get-TransportConfig | Select SmtpClientAuthenticationDisabled.

Getting working credentials

Which password you use depends on your tenant policy. Work through these in order:

1. Try your normal account password. If your tenant still allows basic auth, this works and you are done.
2. If you have MFA, create an app password. Go to mysignins.microsoft.com/security-info, choose Add sign-in method, select App password, and copy the generated value immediately. It is shown only once.
3. If neither works, ask your admin whether the tenant-wide SMTP AUTH toggle and the per-mailbox Authenticated SMTP setting are enabled, and whether a Conditional Access policy blocks legacy authentication for your account.

Testing with SMTP Tester

1. Host: smtp.office365.com, port 587, security STARTTLS.
2. Username: your full Microsoft 365 email address.
3. Password: your app password, or account password if basic auth is still enabled.
4. From: the same email address, unless you have Send As permission on another address.
5. To: any recipient you control. With "Send to myself" you get the actual delivery in your inbox as proof.
6. Click Run.

Reading the transcript as it streams:

• 220 greeting from a Microsoft host, then 250 after EHLO: the endpoint is reachable and your network allows outbound 587.
• STARTTLS then 220 2.0.0 SMTP server ready: the plaintext connection upgraded to TLS. Microsoft requires this before AUTH, so a failure here usually means TLS interception by a firewall or proxy.
• 334 prompts then 235 2.7.0 Authentication successful: credentials and both SMTP AUTH toggles are correct.
• 250 2.6.0 after DATA: Microsoft accepted the message for delivery. Queued does not mean delivered; check the recipient inbox and any bounce that follows.

Common errors

535 5.7.3 "Authentication unsuccessful"

Credentials were rejected. Causes, roughly in order of frequency:

• Wrong password. If MFA is enabled, you need an app password, not your normal login.
• SMTP AUTH is disabled for the mailbox or the tenant, so Microsoft rejects every password.
• Security defaults or a Conditional Access policy blocks legacy authentication entirely.
• The account is locked, unlicensed, or requires a password change before sign-in.
• The username is incomplete: it must be the full email address or UPN.

535 5.7.139 "Authentication unsuccessful, SmtpClientAuthentication is disabled"

SMTP AUTH has been disabled for this mailbox by policy. The connection, TLS, and credentials may all be correct, but the tenant blocks password-based SMTP login. Fixes: enable Authenticated SMTP on the mailbox in the Exchange admin center (the PowerShell equivalent is Set-CASMailbox -Identity user@company.com -SmtpClientAuthenticationDisabled $false), switch to OAuth2, or move to Microsoft Graph or a transactional provider. Our SMTP authentication failed guide covers the whole 535 family in more depth.

550 5.7.60 "SMTP; Client does not have permissions to send as this sender"

Authentication succeeded, but the From address does not match the authenticated mailbox and is not configured as a Send As alias. Microsoft 365 enforces strict sender identity, so you cannot just type any address into the From field.

Fix: set From to the mailbox you authenticated as, or grant Send As permission on the target mailbox in the Exchange admin center (mailbox delegation settings) and wait for replication, which can take up to an hour. This is the classic error when sending on behalf of a shared mailbox: authenticating as your own user works, but the shared mailbox has not granted your user Send As.

554 5.2.0 STOREDRV submission errors

A 554 5.2.0 response from STOREDRV means Microsoft accepted the submission but rejected the message during mailbox store processing. Common triggers:

• The From address domain is not a verified accepted domain in the tenant.
• The authenticated account does not resolve to a valid mailbox, for example an unlicensed or disabled account.
• The message violates a transport rule or exceeds the mailbox's send quota.

The error text usually names the component (STOREDRV.Submit or STOREDRV.Deliver). Match it against the From address and license state of the account you authenticated with, since the usual root cause is an identity mismatch rather than a protocol problem.

Connection timeout or TLS failure

smtp.office365.com only accepts client submissions on port 587. Port 25 is for inbound relay to Exchange Online, not submission, and port 465 is not supported. If 587 times out, check your network's outbound firewall. If STARTTLS fails after connecting, suspect a TLS-intercepting proxy or a corporate appliance pinning certificates. See SMTP port 587 vs 465 for the broader port comparison.

Shared mailboxes, aliases, and licensing

Shared mailboxes in Microsoft 365 have no password and cannot authenticate by default. Two supported patterns:

1. Authenticate as a licensed user, send as the shared mailbox. Grant your user Send As permission on the shared mailbox (Exchange admin center, mailbox delegation). Authenticate with your own credentials and set the From address to the shared mailbox address. This is the pattern most devices and scripts should use.
2. Authenticate as the shared mailbox directly. This requires assigning a password (reset it in the Microsoft 365 admin center) and a license, since Microsoft licenses authentication itself. It also requires SMTP AUTH to be enabled for that mailbox. Most tenants do better with pattern 1.

Aliases and proxy addresses follow the same rule: you can send from a secondary alias only if the authenticated account has permission for it. By default, sending from an alias of the same mailbox is restricted, and Microsoft's guidance has changed on this over time, so test it rather than assuming.

Licensing matters more than on most providers. Unlicensed mailboxes are blocked from sign-in, which surfaces as 535 errors even with the correct password. Any account you use for SMTP submission should hold an active license.

Sending limits

Microsoft 365 applies three types of limits to mailbox submissions:

Exact per-tenant values vary with license type and configuration, so treat these as ballpark figures and check your admin center for current numbers. When you hit the limits, SMTP returns 452 4.5.3 Too many recipients or a 421 temporary error. Back off and retry; repeated hammering can extend the throttle. If your volume regularly approaches these caps, use a transactional provider such as SendGrid (see our SendGrid SMTP test) or Amazon SES (see our Amazon SES SMTP test) instead of a shared mailbox.

Sending from Node.js with nodemailer

const nodemailer = require("nodemailer");

const transport = nodemailer.createTransport({
  host: "smtp.office365.com",
  port: 587,
  secure: false, // 587 uses STARTTLS, not implicit TLS
  requireTLS: true, // fail hard if STARTTLS is unavailable
  auth: {
    user: "app@company.com",
    pass: process.env.SMTP_PASSWORD, // app password or basic-auth password
  },
});

await transport.verify(); // full handshake + auth, no message sent
console.log("Office 365 SMTP connection OK");

await transport.sendMail({
  from: "app@company.com", // must match auth user unless Send As is granted
  to: "you@company.com",
  subject: "Office 365 SMTP test",
  text: "Sent via smtp.office365.com:587 with STARTTLS.",
});

Two mistakes to avoid: setting secure: true (which forces implicit TLS on port 465 and fails against Microsoft 365) and omitting requireTLS, which lets nodemailer proceed without encryption if the server offered it. To move to OAuth2 later, nodemailer supports XOAUTH2 via an accessToken in the auth object.

When SMTP AUTH is not the right tool

Microsoft positions SMTP AUTH as a compatibility protocol for devices and legacy applications: printers, scanners, monitoring systems, and older line-of-business apps. For anything newer, consider:

• Microsoft Graph sendMail with application permissions: modern auth, no stored password, and tenant policies still apply.
• Direct Send on port 25 to your tenant's MX endpoint: no authentication, internal recipients only, suited to multi-function printers inside your network.
• Transactional providers (SendGrid, Amazon SES, Mailgun): built for application volume, with better deliverability tooling and a sending reputation separate from your corporate mailboxes.

Related: the Gmail SMTP test guide covers the consumer-mailbox equivalent, and what is an SMTP test explains each protocol stage if a transcript line above is unfamiliar.

Security notes

• Always use port 587 with STARTTLS. Never send credentials over an unencrypted connection.
• App passwords bypass MFA, so treat them as sensitive secrets. Store them in environment variables or a secrets manager, and rotate them when staff leave.
• SMTP Tester redacts all credentials from the live transcript, and nothing is stored server-side.
• Monitor Microsoft 365 sign-in logs for unexpected SMTP AUTH activity; a spike from an unknown IP can indicate credential compromise.
• Plan the move to OAuth2 for any application you control, since Microsoft continues to retire basic auth.

Frequently asked questions

Can I still use app passwords with MFA?

Yes, if three things line up: your mailbox has MFA enabled, your admin has not blocked app password creation, and no Conditional Access policy blocks legacy authentication for your account. If any of those fail, the App password option will not appear or will be rejected at login.

Should I use port 25 or 587?

Port 587 with STARTTLS for anything that authenticates. Port 25 against your MX endpoint is for Direct Send: no authentication, internal recipients only, no routing to external domains. Port 465 is not offered for Microsoft 365 client submission at all.

How is this different from Exchange on-premises?

On-prem Exchange uses your own server names, may still expose port 465 or 25 for submission, and relies on receive-connector permissions instead of Microsoft 365's tenant and mailbox toggles. The modern auth requirements and basic-auth retirement described here apply to Exchange Online only; on-prem servers keep basic auth until you disable it yourself.

Why does my password fail even though it is correct?

In most cases SMTP AUTH is disabled for the mailbox or the tenant, or a Conditional Access policy blocks legacy authentication. Check SmtpClientAuthenticationDisabled on both the transport config and the mailbox before assuming the credential itself is wrong.

Can I send from a shared mailbox without a license?

You can send from it, but not authenticate as it. Authenticate as a licensed user with Send As permission on the shared mailbox, then set the From address to the shared mailbox address.

Does a successful test prove my emails will reach the inbox?

No. A 250 response means Microsoft accepted the message. Deliverability then depends on your content, sender reputation, and SPF/DKIM configuration. Use the test to validate connectivity, authentication, and permissions; use a real inbox test for placement.