Exchange Online SMTP Basic authentication retirement: what to migrate

What is being retired?

Your application may be able to keep using SMTP. The part you need to replace is Basic authentication for Exchange Online client submission.

SMTP AUTH is authenticated SMTP client submission: an application or device authenticates before submitting mail. It is not another name for Basic authentication. Microsoft’s SMTP AUTH documentation explicitly supports OAuth as well.

This guide concerns Exchange Online. Do not apply its retirement schedule automatically to consumer Outlook.com or on-premises Exchange. For the broader authentication review, use the 2026 email authentication changes checklist.

Where can you find Microsoft’s timeline information?

Microsoft’s application and device sending guidance identifies Basic authentication for Exchange Online client SMTP submission as scheduled for deprecation and links to timeline information. Follow that link when planning your migration deadline.

Start by finding every sending workflow that still relies on Basic authentication.

Which applications and devices are affected?

Classify the sending path, not just the product name. An accounting application, monitoring service, or printer belongs in the inventory if it submits mail through Exchange Online using Basic authentication.

For each workload, record its owner, application version, configured sending endpoint, authentication method, sending identity, and recipient types. Include business-critical dependencies: a scheduled report that sends monthly can be easier to miss than a service sending daily notifications.

Keep organization-wide SMTP AUTH settings and mailbox settings in separate inventory columns. Microsoft documents that the mailbox setting takes precedence over the organization setting. It also states that enabling security defaults disables SMTP AUTH in Exchange Online.

To inspect the mailbox setting in the Microsoft 365 admin center, follow "Users" → "Active users" → select the user → "Mail" → "Manage email apps". "Authenticated SMTP" is enabled when checked and disabled when unchecked. This setting does not identify which authentication method the application actually uses.

For related connection troubleshooting, see Outlook IMAP and SMTP settings and Basic authentication failures.

What should replace Basic authentication?

Prefer SMTP OAuth when the application supports it and keeping SMTP avoids an unnecessary rewrite. Choose Graph when changing the application’s sending interface makes sense. For older devices, evaluate Microsoft’s documented relay and Direct Send configurations against the actual recipient requirements.

Keep SMTP with OAuth

Microsoft’s SMTP OAuth implementation guide specifies SASL XOAUTH2 for transmitting an access token. The documented delegated SMTP scope is https://outlook.office.com/SMTP.Send.

Ask the application vendor whether the installed version supports that authentication flow. A generic claim that the product supports Microsoft 365 is not a substitute for checking its sending configuration.

Client SMTP submission requires a licensed Microsoft 365 or Office 365 mailbox and supports recipients inside and outside the organization. OAuth changes authentication; it does not remove those requirements.

Change the interface with Graph

Microsoft Graph sendMail accepts JSON or MIME messages. Microsoft lists Mail.Send for both delegated work-or-school access and application access in the Graph sendMail reference.

Choose this path when you can change the application code and permissions model. Graph is not an SMTP server setting. The IMAP, Graph, and SMTP comparison explains the interface distinction in more detail.

Evaluate relay and Direct Send separately

Microsoft 365 SMTP relay uses an inbound connector. It requires a certificate or a static public IP address that is not shared with another organization, and it does not require a licensed sending mailbox. It supports internet relay through Microsoft 365.

Direct Send submits unauthenticated mail directly to Microsoft 365 as an external email server. It does not provide internet relay. Do not choose it for a workflow that needs external recipients merely because it avoids mailbox authentication.

How do you validate a migration?

Use a mailbox or device you control, with test recipients appropriate to the workflow.

1. Inventory dependencies. Name the application owner and identify where credentials or sending settings are stored. Record the business process that depends on successful delivery.
2. Confirm the current method. Inspect the application configuration rather than inferring authentication from a successful mailbox sign-in. Record organization and mailbox SMTP AUTH settings separately.
3. Choose a supported path. Check the client’s OAuth capability, the application’s ability to adopt an API, or the device’s suitability for Microsoft’s relay configurations.
4. Configure a test workload. Record the application version, tenant configuration, granted permissions, and test date. Complete the consent required by the chosen integration.
5. Test sending and delivery separately. Record authentication success, the sending result, recipient receipt, and any non-delivery report. Keep sanitized errors without credentials or tokens.
6. Roll out in stages. Move a limited workload first, observe its normal sending cycle, and then expand. Define a recovery path using a supported configuration rather than assuming Basic authentication will remain available.

A successful Graph request is not proof of delivery. Microsoft documents that 202 Accepted means the request was accepted, not that processing has completed. Delivery remains subject to Exchange Online limitations and throttling.

When planning application retries and recovery, use the broader reliable email API workflow guide.

What commonly goes wrong?

Treating SMTP AUTH availability as permission to use Basic authentication. Protocol configuration and authentication method are different checks. Microsoft recommends disabling SMTP AUTH organization-wide and enabling it only for mailboxes that need it.

Assuming OAuth overrides policy. Token-based authentication still needs the applicable protocol settings, consent, and permissions. Do not weaken tenant security settings simply to make an old application’s connection test pass; evaluate another sending path.

Changing the credential instead of the authentication method. An OAuth migration must implement the documented token flow. Replacing a stored password with another password is not that change.

Treating relay and Direct Send as interchangeable. Their authentication and recipient capabilities differ. Test the external-recipient requirement before choosing a device configuration.

Stopping at sign-in success. A connected mailbox, an accepted API request, and a received message are different observations. Your migration checklist needs all the relevant checks.

Where does Mailera fit?

Mailera connects existing Microsoft mailboxes through OAuth and Microsoft Graph. Microsoft mailboxes are not connected to Mailera with an app password. The Microsoft connection guide covers that path; the product overview explains how connected mailboxes become available to applications.

To connect a test mailbox:

1. Sign in to Mailera with an Admin or Leader role.
2. Open Mailboxes → Add mailbox.
3. Select Sign in with Microsoft and complete Microsoft’s OAuth consent flow.
4. Return to Mailboxes and inspect the connected mailbox’s status.

For an application moving to REST, Mailera exposes POST /mailboxes/{id}/send, which requires the send scope. Use the developer documentation to integrate that endpoint. It is an API integration option, not an SMTP host replacement for an unchanged legacy client.

Mailera does not create mailboxes or email addresses; you connect mailboxes you already control. It does not provide bulk or marketing sending, and it cannot guarantee inbox placement. Connecting a mailbox does not migrate an existing SMTP-only application: that application still needs a supported sending integration.