Microsoft is retiring Basic Authentication for SMTP AUTH Client Submission in Exchange Online. If your printers, scanners, scripts, or legacy applications send email through Microsoft 365 using username and password authentication, they need a new solution before Basic Auth is permanently removed.
Here’s everything you need to know about the timeline, impact, and your options for keeping email flowing without interruption.
Quick Summary: What’s Changing and When
The short version:
- Now through December 2026: SMTP AUTH Basic Authentication continues unchanged
- End of December 2026: Basic Auth disabled by default for existing tenants (administrators can still re-enable if needed)
- New tenants after December 2026: Basic Auth unavailable by default, OAuth required
- Second half of 2027: Microsoft will announce the final removal date
Who’s affected: Systems using smtp.office365.com or smtp-legacy.office365.com with username and password authentication
Best next step: Inventory your SMTP senders now, choose a migration path, and test your preferred solution
Current Microsoft SMTP AUTH Basic Authentication Timeline
| Date | Microsoft Change | What It Means | What You Should Do |
|---|---|---|---|
| Now to December 2026 | No behavior change | Basic Auth continues working normally | Inventory affected senders, plan migration |
| End of December 2026 | Basic Auth disabled by default for existing tenants | Systems will fail unless admin re-enables (temporary option) | Migrate to OAuth or SMTP relay service |
| New tenants after December 2026 | Basic Auth unavailable by default | New Microsoft 365 accounts cannot use Basic Auth for SMTP | Use OAuth or external SMTP service |
| Second half of 2027 | Final removal date announced | Microsoft will set absolute end date for all Basic Auth | Complete migration before announced deadline |
Source: Microsoft’s January 2026 Exchange Online update
What Is SMTP AUTH Basic Authentication?
SMTP AUTH Client Submission is how applications and devices send email through Microsoft 365’s SMTP endpoints (smtp.office365.com and smtp-legacy.office365.com).
Basic Authentication uses simple credentials:
- A username (typically your Microsoft 365 email address)
- A password (your account password or app password)
- Sent with every SMTP connection
Modern Authentication (OAuth 2.0) uses temporary tokens instead of passwords:
- Applications request a limited-time access token
- No permanent passwords stored or transmitted
- Tokens can be revoked without changing account passwords
- Supports multi-factor authentication and conditional access policies
Why Microsoft is ending Basic Authentication: Basic Auth sends credentials with every request, making them vulnerable to interception, credential stuffing attacks, and brute force attempts. OAuth tokens are time-limited and can be easily revoked if compromised.
Who Is Affected?
Systems that will stop working:
Printers and multifunction devices
- Scan-to-email functions using SMTP authentication
- Print-to-email services
- Document workflow automation
- Note: Devices using AppSMTP may not be affected—check your specific configuration
Legacy applications and scripts
- ERP systems with email notification features
- Accounting software sending invoices or reports
- Custom applications with hardcoded SMTP credentials
- PowerShell, Python, or PHP scripts using username/password SMTP
Monitoring and alerting systems
- Network monitoring tools sending SMTP alerts
- Security systems emailing logs or notifications
- Backup software sending status reports
- Server monitoring sending failure alerts
Scheduled jobs and automation
- Database report emailers
- Batch processing status notifications
- Automated billing or invoice systems
- Data extraction and reporting tools
Systems that may NOT be affected:
- Applications already using OAuth 2.0 for SMTP
- SMTP2GO users sending through mail.smtp2go.com (not using Microsoft’s SMTP servers)
- Some relay configurations that don’t use SMTP AUTH Client Submission
- Exchange Online configurations using IP-based relay instead of authenticated SMTP
How to Check if You’re Using Basic Auth for SMTP AUTH
To identify affected senders in your Microsoft 365 environment:
- Access Exchange Admin Center
- Go to admin.microsoft.com
- Navigate to Exchange Admin Center
- Select Reports > Mail flow > SMTP AUTH clients report
2. Review the SMTP AUTH Clients report
- Look for devices/applications using Basic Authentication
- Check the Authentication Type column for “Basic Auth”
- Note the Client IP addresses and Usernames for affected senders
3. Categorize your senders
- Can support OAuth: Modern applications that can be updated
- Cannot support OAuth: Printers, legacy devices, simple scripts
- Internal-only sending: Email that stays within your organization
- External sending: Email going to customers, partners, or outside recipients
- High-volume sending: Bulk notifications, reports, or marketing emails This inventory helps you choose the right replacement option for each type of sender.
What Happens If You Do Nothing?
When Basic Authentication is disabled, affected systems will experience:
Immediate failure: SMTP connections will be rejected with error code 550 5.7.30 Basic authentication is not supported for Client Submission
Silent breakage: Many devices and background processes don’t provide visible error notifications, so you may not realize email has stopped working until users report missing notifications
Permanent rejection: Unlike temporary network issues, authentication failures don’t retry successfully—systems will continue failing until you update their configuration
Business impact: Missed alerts, unreported system failures, broken workflows, customer communication gaps, and compliance issues for systems that rely on email notifications
Your Migration Options: Complete Comparison
| Option | Best For | Supports External Recipients | Works With Legacy Devices | Setup Difficulty | Key Limitation |
|---|---|---|---|---|---|
| OAuth SMTP | Modern applications that can be updated | Yes | No (OAuth requires app updates) | Medium | Many legacy systems cannot support OAuth |
| Microsoft Graph API | Custom applications and scripts | Yes | No (requires API integration) | High | Not suitable for simple SMTP-only devices |
| Microsoft High Volume Email | Bulk sending, newsletters | External bulk email only | No | Medium | Limited to high-volume scenarios |
| Azure Communication Services | Applications needing email + SMS | Yes | No (API-only, no SMTP) | High | Requires significant code changes |
| Exchange Online SMTP Relay | Internal organizational email | Internal recipients only | Yes (if using static IP) | Low | External email requires hybrid setup |
| On-premises relay | Organizations with existing Exchange Server | Yes | Yes | High | Requires on-premises infrastructure |
| SMTP2GO | Printers, scanners, legacy apps, scripts | Yes | Yes (standard SMTP) | Low | Requires account setup and DNS verification |
When SMTP2GO Is Your Best Option
Perfect fit scenarios:
- Printers and scanners that only support basic SMTP authentication
- Legacy applications that cannot be updated to use OAuth
- Simple scripts that need reliable SMTP without complex authentication
- Monitoring tools requiring straightforward email alerting
- Mixed environments where some systems can use OAuth and others cannot
Why changing SMTP servers is often simpler than adding OAuth:
- No application updates required—just change server settings
- Same username/password authentication model your devices already understand
- No token management, app registration, or API integration complexity
- Works with any device or application that supports SMTP
SMTP2GO configuration at a glance:
- SMTP Server: mail.smtp2go.com
- Ports: 2525, 587 (TLS), 25, 80, 8025, 465 (SSL)
- Authentication: SMTP username and password (created in your SMTP2GO account)
- Encryption: TLS/SSL supported and recommended
- Sender verification: Domain verification required for reliable delivery
- Reporting: Detailed delivery logs and analytics included
Migration Guide: From Microsoft SMTP AUTH to SMTP2GO
Step 1: Inventory Your SMTP Senders
Document each system that sends email:
- Device/application name and location
- Current SMTP settings and credentials
- Email volume and frequency
- Sender email addresses used
- Recipients (internal, external, or both)
- Business criticality and failure impact
Step 2: Verify Sender Domains and DNS Records
Before switching to SMTP2GO:
- Ensure you control the DNS for sender domains
- Check existing SPF, DKIM, and DMARC records
- Plan DNS updates to include SMTP2GO’s sending infrastructure
- Consider using SMTP2GO’s automatic DNS record feature for easier setup
Step 3: Create SMTP2GO Account and Users
Account setup:
- Sign up for SMTP2GO (free plan available for testing)
- Add and verify your sender domains
- Create SMTP users for your devices and applications
- Note the SMTP username and password for each user
Step 4: Update Device and Application Settings
For each sender system:
- Change SMTP server from smtp.office365.com to mail.smtp2go.com
- Update port to 587 (TLS) or 2525 (recommended for legacy systems)
- Replace Microsoft 365 credentials with SMTP2GO username/password
- Enable TLS/SSL encryption if supported by the device
- Test with a single email before full deployment
Common device types:
- Printers: See setup guides for Ricoh, Kyocera, Lexmark, Xerox, and Sharp
- Applications: Check the SMTP2GO setup guide library for your specific platform
- Scripts: Use standard SMTP library configuration with new server and credentials
Step 5: Test and Monitor Delivery
Verification checklist:
- Send test emails to internal recipients
- Send test emails to external recipients (Gmail, Outlook.com, etc.)
- Check SMTP2GO delivery reports for successful sending
- Monitor bounce rates and delivery issues
- Verify emails reach inboxes and don’t land in spam folders
Step 6: Document Configuration and Ownership
For ongoing management:
- Document the new SMTP settings for each device/application
- Assign ownership and maintenance responsibility
- Set up monitoring for SMTP2GO account limits and usage
- Plan for credential rotation and security updates
- Create runbook for troubleshooting common issues
Frequently Asked Questions
Is SMTP AUTH Basic Authentication already disabled?
No. Microsoft’s current timeline keeps Basic Auth working through December 2026. However, it will be disabled by default for existing tenants at the end of December 2026, and new tenants created after December 2026 won’t have Basic Auth available by default.
Does this affect current SMTP2GO users?
No. If you’re already sending email through SMTP2GO’s servers (mail.smtp2go.com), Microsoft’s changes to Exchange Online SMTP Auth don’t affect you. You’re using SMTP2GO’s infrastructure, not Microsoft’s SMTP servers.
Can printers and scanners use OAuth instead of Basic Auth?
Most printers and scanners cannot use OAuth because they lack the ability to handle modern authentication flows. OAuth requires web browser-like functionality for token exchange, which simple embedded systems don’t support. Some newer enterprise devices may support OAuth, but it’s rare and often complex to configure.
Is Microsoft Graph API a good replacement for SMTP-only devices?
No. Microsoft Graph API is designed for custom applications that can make HTTP API calls. Printers, scanners, and legacy applications that only understand SMTP cannot use Graph API without significant software changes or replacement.
Is Microsoft High Volume Email a viable alternative?
Microsoft High Volume Email is designed specifically for bulk sending like newsletters and marketing emails. It’s not intended for transactional email like printer notifications, system alerts, or automated reports. It also requires API integration rather than simple SMTP.
Can Microsoft grant exceptions for legacy devices that can’t be updated?
While administrators can temporarily re-enable Basic Auth after it’s disabled by default in December 2026, Microsoft plans to remove this option entirely in the second half of 2027. This is meant as a temporary migration aid, not a permanent solution for legacy devices.
What should MSPs do for multiple client environments?
MSPs should inventory SMTP usage across all client tenants, develop a standardized migration approach (likely SMTP relay services like SMTP2GO for legacy devices), and plan bulk transitions. Consider SMTP2GO’s reseller program for managing multiple client accounts efficiently.
Keep Your Email Flowing After Microsoft’s SMTP AUTH Changes
Microsoft’s timeline gives you time to plan, but waiting until December 2026 means dealing with urgent failures under pressure. Starting your migration now lets you test thoroughly and address issues before they impact your business.
For systems that can support OAuth: Migrate to Microsoft’s modern authentication for the best long-term security and integration.
For printers, scanners, scripts, and legacy applications that cannot support OAuth: SMTP2GO provides reliable SMTP relay service that works exactly like your current setup—just with a different server address.
Ready to test SMTP2GO for your legacy SMTP senders?
Start with our setup guide to configure your first device, or contact our support team if you need help planning your migration strategy.
One category is missing from the comparison table. 'On-premises relay' is listed as needing an existing Exchange Server, but there is a much lighter version: a small local service that accepts plain SMTP from the device and speaks OAuth2 and Graph outbound to the tenant. No Exchange, no changes to the sending application, and the printer keeps doing what it already does.
What makes that interesting is not the price, it is where the mail goes. With a hosted relay the message leaves the organisation and is processed by a third party. For a lot of European companies that is the deciding factor, whether it is a works council, a GDPR assessment or simply a policy that invoices do not travel through outside providers.