Fix: Application Email Notifications Stopped Working (SMTP AUTH & MFA Conflict)
This typically occurs during security enforcement changes — especially when legacy authentication is deprecated and MFA is enforced on service accounts, breaking SMTP-based authentication for every connected application simultaneously.
⚠️ Key Warning
Simply disabling MFA as a workaround resolves the issue temporarily but introduces significant security risks and is not Microsoft-recommended best practice. This guide covers the correct, secure resolution path.
🔍 Symptoms
⚠️ What You May Experience
- Application email notifications stopped across all systems simultaneously
- SMTP authentication failures from applications
- Connection test to
smtp.office365.com:587succeeds, but emails are not sent - No errors in application logs beyond “authentication failed” or “unable to relay”
🧠 Root Cause
Why do all applications stop at the same time?
The issue occurs due to a combination of factors:
- SMTP AUTH being disabled at tenant or mailbox level (often done automatically by Microsoft for unused tenants)
- MFA enforced on the service account used by applications
- Applications using basic authentication (username/password), which does not support MFA and is being deprecated by Microsoft
As a result, authentication fails silently and all applications using that service account are impacted simultaneously.
🛠️ Step-by-Step Resolution
Validate SMTP AUTH Configuration
Check whether SMTP AUTH is enabled at both the mailbox level and the tenant level — both must be enabled for SMTP client submissions to work.
Connect-ExchangeOnline # Check mailbox SMTP AUTH status Get-CASMailbox -Identity "user@yourdomain.com" | Select SmtpClientAuthenticationDisabled # Enable SMTP AUTH for the mailbox ($false = enabled) Set-CASMailbox -Identity "user@yourdomain.com" -SmtpClientAuthenticationDisabled $false # Check tenant-wide SMTP AUTH setting Get-TransportConfig | Select SmtpClientAuthenticationDisabled # Enable SMTP AUTH org-wide (if disabled) Set-TransportConfig -SmtpClientAuthenticationDisabled $false
💡 How to Read the Output
SmtpClientAuthenticationDisabled = True→ SMTP AUTH is disabled (bad)SmtpClientAuthenticationDisabled = False→ SMTP AUTH is enabled (good)SmtpClientAuthenticationDisabled = $null→ mailbox inherits the org-level setting
Validate SMTP Connectivity
Confirm network connectivity to the SMTP endpoint is not the issue before investigating authentication further.
Test-NetConnection smtp.office365.com -Port 587
✅ Expected Result
TcpTestSucceeded : True — if this fails, the issue is network/firewall, not authentication.
Verify Application SMTP Settings
Confirm all applications are configured with the correct SMTP endpoint and settings.
| Setting | Required Value |
|---|---|
| SMTP Server | smtp.office365.com |
| Port | 587 |
| Encryption | STARTTLS |
| Authentication | Enabled |
| Username | Full email address of the service account |
| Password | App password or OAuth token (see Step 4) |
Resolve the MFA Conflict (Choose the Right Approach)
This is the root fix. Choose the option that fits your environment and security requirements.
❌ Not Recommended — Disabling MFA
Excluding the service account from MFA resolves the issue temporarily but reduces your security posture significantly. Only use this as an emergency measure while implementing a permanent solution.
✅ Option A — Use an App Password (Quick Fix for MFA Accounts)
- Sign in as the service account at mysignins.microsoft.com/security-info
- Navigate to Security Info → Add sign-in method → App password
- Generate an App Password — a 16-character password that bypasses MFA for legacy apps
- Update the SMTP password in all affected applications with this app password
✅ Option B — Migrate to OAuth 2.0 (Recommended Long-Term)
- Register your application in Microsoft Entra ID (formerly Azure AD)
- Grant the SMTP.Send permission under API permissions
- Configure the application to authenticate using an OAuth 2.0 access token instead of username/password
- This eliminates MFA conflicts entirely and is Microsoft’s recommended approach
⚠️ Requires application-level support for OAuth. Check your application’s documentation for SMTP OAuth compatibility.
⚠️ Important: Basic Auth Deprecation Timeline
Microsoft has announced the permanent removal of Basic Authentication for SMTP AUTH. Organizations still using basic auth must migrate to OAuth 2.0 or an alternative sending method.
Optional — Verify Inbound Connectors (Relay Scenarios)
If applications are configured to send through a connector rather than direct SMTP AUTH, verify the connector is healthy.
Get-InboundConnector | Select Name, Enabled, ConnectorType, SenderIPAddresses, TlsSenderCertificateName
💡 What to Check
- Connector is Enabled = True
- Correct IP ranges are listed in
SenderIPAddresses - TLS certificate name matches what the sending application presents
✅ Final Outcome
After completing these steps:
- SMTP AUTH validated and enabled at mailbox and tenant level
- MFA incompatibility resolved via App Password or OAuth migration
- Application SMTP settings verified against correct endpoint and port
- ✅ Applications successfully resume sending email notifications
💡 Best Practices & Recommendations
- Avoid disabling MFA for service accounts — use App Passwords or OAuth instead
- Prefer OAuth 2.0 modern authentication over basic SMTP authentication for all new integrations
- Use dedicated service accounts with least privilege for SMTP sending — never use admin accounts
- Regularly audit SMTP AUTH usage via the SMTP AUTH Clients report in the Exchange Admin Center to identify accounts still using basic auth
- For high-volume internal notifications, consider migrating to Microsoft Graph API mail sending, which avoids SMTP AUTH entirely
📚 References & Further Reading
- 🔗 Enable or Disable SMTP AUTH in Exchange Online — Microsoft Learn
- 🔗 Deprecation of Basic Authentication in Exchange Online — Microsoft Learn
- 🔗 Authenticate an IMAP, POP or SMTP Application Using OAuth — Microsoft Learn
- 🔗 Plan a Microsoft Entra ID Multifactor Authentication Deployment — Microsoft Learn