Basic authentication sends a reusable username-and-password proof with a connection. Exchange Online has removed it for the major user and client protocols listed in Microsoft’s retirement guidance, while SMTP AUTH Basic authentication follows a separately updated retirement path.

The migration question is not “How do we turn Basic auth back on?” It is “What job was this connection doing, and which supported design should own that job now?”

Do not confuse protocol with authentication

POP, IMAP and SMTP are protocols. Basic authentication and OAuth are authentication methods. A supported application can use OAuth with POP, IMAP or SMTP, although the protocol may still be a poor fit for the required workflow.

For example:

  • a helpdesk ingestion process may need controlled mailbox reading;
  • a scanner may need to send a few internal messages;
  • a line-of-business system may send external notifications;
  • a newsletter platform needs a purpose-built bulk-sending service; and
  • an administrator script should use current Exchange Online or Graph tooling, not old Remote PowerShell credentials.

Classify the job before selecting the technology.

Discover actual usage

Build an owner-backed inventory from sign-in logs, message traces, connector configuration, mailbox protocol settings, device/application configuration and service-desk reports.

For each dependency, record:

  • business owner and technical owner;
  • application or device and supported software version;
  • read, send or administrative job;
  • protocol and current authentication method;
  • sending/reading identity;
  • internal or external recipients;
  • volume, rate and message size;
  • source network and whether it has a stable dedicated IP;
  • data sensitivity;
  • retry and outage behaviour; and
  • retirement or replacement date.

Do not infer “unused” from an empty week. Some payroll, audit, backup and certificate alerts run monthly or only on failure.

Eliminate credentials before preserving protocols

If the software supports OAuth for the required POP, IMAP or SMTP workflow, configure a proper interactive or application identity and the narrowest permission model. Tokens are scoped and time-limited, but an overprivileged application with a long-lived certificate is still a powerful identity.

Ask whether a richer supported API is better. Microsoft Graph may provide more controlled mail access or sending for a modern application. A service designed for transactional or bulk email may fit high-volume external sending better than a user mailbox.

Do not embed client secrets, certificates or refresh tokens in source code or device configuration exports.

Choose the application/device sending route

Microsoft documents several distinct options:

  • Client SMTP submission: authenticates as a mailbox and can send internally and externally, but is subject to mailbox and service constraints. Prefer OAuth; password-based SMTP AUTH is a disappearing dependency.
  • SMTP relay through a connector: identifies an authorised source using a supported certificate or dedicated public IP and can send as accepted-domain addresses. It requires careful anti-relay and routing design.
  • Direct Send: delivers to recipients in the Microsoft 365 organisation through the tenant MX endpoint without becoming a general external relay.
  • High Volume Email: targets supported high-volume internal scenarios and has current preview/service constraints that must be checked live.
  • External transactional email service: may be the correct route for application notifications or bulk external mail, with its own authentication, reputation, data and contractual responsibilities.

Select from destination, identity, volume, platform capability, security and failure behaviour—not from whichever old SMTP settings are easiest to copy.

Avoid broad exceptions

Do not enable SMTP AUTH across the tenant to rescue one device. If a temporary per-mailbox or policy exception is genuinely necessary, give it:

  • a named owner;
  • an exact workload;
  • least scope;
  • monitoring;
  • an expiry date;
  • a documented replacement; and
  • an automatic or reviewed removal action.

Conditional Access and authentication policy changes can affect more clients than the visible request. Test with report-only or controlled scope where the feature supports it.

Test the functional and security outcome

For a sender, test:

  1. intended internal and external delivery;
  2. correct visible From and envelope identity;
  3. SPF, DKIM and DMARC alignment where applicable;
  4. message trace and application logs;
  5. reply and bounce handling;
  6. rate/volume behaviour;
  7. token or certificate expiry handling;
  8. retry after temporary service failure; and
  9. refusal of an unauthorised sender or source.

For a mailbox-reading application, test least-privilege access, expected folders/items, throttling, token renewal, disabled-account behaviour and revocation.

“The test email arrived” proves only one thin path.

Cut over with evidence

Run the old and new routes in a controlled comparison if duplication and data handling allow it. Record message IDs, timings and business acceptance. Then disable the old credential or exception and prove:

  • the replacement continues to work;
  • the old Basic-authentication attempt fails;
  • no unrelated client was affected; and
  • monitoring detects a future failure.

Remove obsolete app passwords, stored credentials, service accounts, protocol exceptions and connectors after dependencies are reconciled.

Keep the retirement alive

Microsoft’s SMTP AUTH timeline and service alternatives continue to change. Link the live Microsoft notice in operational records and recheck it at every exception review.

The durable outcome is not a one-time protocol toggle. It is an inventory in which every mail-access workload has an owner, a supported identity, a tested failure path and a credible retirement route.