I'm setting up a new administrator for a client's church management and mailing application. The application sends email through SMTP but does not support OAuth, so it requires a Microsoft app password.
Existing users who were previously given app passwords can still use them, and their current passwords remain visible in Security Info. However, the option to create a new app password no longer appears for those users or for the new administrator.
The tenant has Security Defaults disabled, the setting allowing users to create app passwords is enabled, affected users have per-user MFA enforced and completed, Microsoft Authenticator is registered, and no Conditional Access policy appears to block legacy authentication. Users can access Security Info normally, but "App password" is missing from the available sign-in methods.
Is there another setting that controls whether new app passwords can be created, or has Microsoft retired new app-password creation? The application vendor does not currently support OAuth, so I'm also considering an Exchange relay or a third-party SMTP relay as a workaround.
4 Answers
I’d avoid spending too much time trying to restore app-password support. Even if an exception makes the option appear, it would be a temporary fix based on an authentication method Microsoft is actively removing. The application needs to add OAuth support, or the mail flow should be moved to a relay.
Exchange Online connectors can work if the application sends from a predictable, fixed public IP or uses an appropriate certificate. You would configure a connector under mail flow and restrict it carefully so it cannot become an open relay. For hosted software that does not have a fixed outbound IP, a dedicated SMTP relay is generally more practical. SMTP AUTH settings control whether SMTP authentication succeeds, but they normally do not control whether the app-password option appears in Security Info.
Microsoft’s retirement of Basic Authentication is the likely explanation. App passwords depend on the older authentication flow, and Microsoft’s guidance says that deprecating Basic Authentication also prevents app passwords from being used with applications that do not support modern authentication. Existing app passwords may continue to work for a while, but new ones can no longer be created. This is probably not a missing tenant setting.
A third-party SMTP relay is usually the simplest option for an application that cannot use OAuth. Configure the application to send through the relay, then update SPF and enable DKIM for the sending domain. Also verify DMARC alignment so newsletters do not get rejected or sent to spam. Some vendors can authenticate the domain and send mail on the client’s behalf, which may eliminate the need to manage the relay directly.
SMTP2Go is one example that works well for older line-of-business applications and scan-to-email setups. Several small organizations have moved this kind of traffic there rather than weakening their Microsoft 365 authentication settings.
That matches what we saw: previously created app passwords continued working, but the option to generate additional ones disappeared. The documentation specifically called out that new app passwords would no longer be available.