Fix 550 5.7.30 Basic authentication is not supported for Client Submission

The error 550 5.7.30 Basic authentication is not supported for Client Submission means a printer, scanner or application tried to send mail through smtp.office365.com with a username and password, and Exchange Online refused because Basic authentication for SMTP AUTH is turned off for your tenant. The fix is to change how the sender authenticates: move applications to OAuth, and move devices that can't do OAuth to High Volume Email (internal recipients), an SMTP relay connector (internal and external recipients) or another supported path. Resetting the password or re-entering it on the device does not help.

Who this is for and what you will have

This guide is for Microsoft 365 administrators and the people who look after multifunction printers, scan-to-email, monitoring systems and line-of-business applications. At the end you will have:

• A list of every sender that still uses Basic auth for SMTP AUTH, taken from the Exchange admin center.
• A decision for each sender based on who it sends to and what it supports.
• Working configuration for the replacement: OAuth, High Volume Email or an SMTP relay connector.
• A short troubleshooting table for the errors that appear while you switch.

Why the error appears

Exchange Online finished disabling Basic authentication for most protocols in 2022 and left SMTP AUTH client submission as the exception. In January 2026 Microsoft published the current timeline for removing it:

Microsoft's original announcement states that once Basic auth is permanently disabled, clients and apps connecting with it to the client submission endpoints smtp.office365.com and smtp-legacy.office365.com receive 550 5.7.30 Basic authentication is not supported for Client Submission. The rejection is permanent (5xx), so a device that can't retry with another method keeps failing.

Microsoft has also said that support can't re-enable Basic auth once it is permanently disabled and won't grant exceptions. The only lasting fixes are an OAuth-capable client or a different sending method.

Errors that look similar

Several SMTP errors appear when you change device configuration. Knowing which is which saves time:

Prerequisites

• Access to the Exchange admin center and Exchange Online PowerShell.
• The public IP address that each device or server uses to reach the internet, if you plan to use a relay connector.
• Admin access to each device's email settings, or the vendor documentation for it.
• For High Volume Email, Microsoft 365 pay-as-you-go billing linked to an Azure subscription.

Step 1: Find every Basic auth sender

1. In the Exchange admin center, go to Reports > Mail flow and open SMTP AUTH clients.
2. Set the date range to the maximum of 90 days. The report shows the last 7 days by default, and monthly or quarterly jobs are easy to miss.
3. In Messages sent using SMTP Auth, look at Authentication Protocol. TlsAuthLogin is Basic auth; XOAUTH2 is OAuth.
4. Note the TLS columns too. Rows with TLS 1.0 or 1.1 usage point to old devices that may also struggle with the replacements: client submission requires TLS 1.2 or later, and High Volume Email requires TLS.
5. Select Export and work through the list.

For each sender address, find the device or application that uses it. On a device, the giveaway is the SMTP server setting: smtp.office365.com means client submission; a name ending in mail.protection.outlook.com means Direct Send or SMTP relay, which this error doesn't affect.

Step 2: Choose the replacement

Microsoft also names Azure Communication Services Email as an option when you need to send to both internal and external recipients without Basic auth.

Option A: Move the application to OAuth

If the application or device firmware supports OAuth for SMTP, this is the closest replacement: same endpoint, same port, mail still saved to Sent Items. For a service that sends without a user present, use the client credentials flow with the SMTP.SendAsApp permission. The full procedure, including New-ServicePrincipal, mailbox permissions and XOAUTH2 code, is in SMTP AUTH with OAuth client credentials.

Option B: High Volume Email for internal mail

High Volume Email (HVE) is built for application and device mail to recipients inside your tenant. It uses dedicated HVE accounts instead of mailboxes, supports both OAuth and Basic authentication, and HVE accounts can authenticate even when SmtpClientAuthenticationDisabled is True in the transport configuration, because HVE uses its own endpoint. That makes it a direct replacement for a scanner that can only store a username and password, as long as it never needs to send outside the organization.

Create an account:

1. In the Exchange admin center, go to Mail flow > High Volume Email and select Add an HVE account.
2. Enter a display name, a primary email address in an accepted domain (for example scanner-hve@contoso.com) and a password that meets your password policy.
3. Select Next. On the Pay-as-you-go billing policy step, select a billing policy (you can also assign one later), select Next, review the details and select Create.

Or in PowerShell:

New-MailUser -HVEAccount -Name "Scanner HVE" -PrimarySmtpAddress "scanner-hve@contoso.com"
Get-BillingPolicy -ResourceType HVE
Set-HVEAccountBillingPolicy -Identity scanner-hve@contoso.com -BillingPolicyId "11111111-1111-1111-1111-111111111111"

An HVE account without a valid billing policy can't send. Microsoft lists the price as USD 0.000042 per delivered recipient after distribution list expansion ($42 per million recipients). Configure the device with:

Limits to plan around: internal recipients only, up to 50 recipients per message, 10 MB maximum message size, up to 100 HVE accounts per tenant, and no mailbox, so set a Reply-To address with Set-HVEAccountSettings if people reply to these messages. HVE is supported in the Microsoft 365 worldwide environment.

Option C: SMTP relay connector for internal and external mail

An inbound connector authenticates the device by its static public IP address or by a TLS certificate, so the device doesn't sign in at all. It can send from any address in an accepted domain, the address doesn't need a mailbox, and mail can go to external recipients.

1. Find your MX endpoint: in the Microsoft 365 admin center go to Settings > Domains, select the domain, open DNS records and copy the MX Points to address, for example contoso-com.mail.protection.outlook.com.
2. In the Exchange admin center, go to Mail flow > Connectors and select Add a connector.
3. Set Connection from to Your organization's email server.
4. Name the connector and leave Turn it on selected.
5. On Authenticating sent email, choose either the certificate option (enter the accepted domain that matches the certificate Subject or SAN) or By verifying that the IP address of the sending server matches one of the following IP addresses which belong exclusively to your organization and enter the device's public IP.
6. Review and select Create connector.
7. Add the IP address to your domain's SPF record so the mail isn't treated as spam.

Configure the device with the MX endpoint as the server, port 25, TLS enabled (TLS 1.2 or later) and any sender address in the accepted domain. Microsoft's requirements: dynamic IP addresses aren't supported, the IP must not be shared with another organization, port 25 must be open on your network and with your ISP, and you can't use this method from a third-party hosted service such as Microsoft Azure. Don't type the IP address of the Microsoft 365 server into the device; always use the host name.

Option D: Direct Send, with care

Direct Send needs no settings in Microsoft 365: the device sends anonymously to your MX endpoint on port 25 using an address in your domain, and messages can only reach mailboxes in your tenant. Microsoft recommends it only when nothing else works, because it is treated like anonymous internet mail and is the same path attackers use to spoof your domain. If you use it, add the sending IP to SPF and configure DKIM and DMARC. You can block it for your own domains with Reject Direct Send; Reject Direct Send in Exchange Online explains how to keep approved devices working when you do.

Bridge the gap while you migrate

If the end-of-December 2026 default has disabled Basic auth in your tenant and a critical sender can't be changed in time, Microsoft states that administrators can still enable it until the final removal date. The announcement doesn't name the control for this, so watch Message center for the follow-up details before you depend on it. Use any such exception only for named senders with a migration date. Independently of Basic auth, keep the SMTP AUTH protocol disabled for every mailbox that doesn't need it. Enable it explicitly on each mailbox from your SMTP AUTH clients report that still needs it first, then disable it for the organization, otherwise senders that rely on the organization setting stop working:

Set-CASMailbox -Identity scanner@contoso.com -SmtpClientAuthenticationDisabled $false
Get-CASMailbox -Identity scanner@contoso.com | Format-List SmtpClientAuthenticationDisabled
Set-TransportConfig -SmtpClientAuthenticationDisabled $true

These commands turn the SMTP AUTH protocol on or off per organization and per mailbox, for Basic auth and OAuth alike; they are not the Basic auth switch. The mailbox setting overrides the organization setting. Basic auth with client submission also isn't compatible with security defaults in Microsoft Entra ID, and a Conditional Access policy that blocks legacy authentication blocks it too. Weakening either control for a printer is rarely worth it compared with moving the printer to HVE or a relay connector.

Verify

1. Send a test message from each migrated device or app to an internal and, where expected, an external recipient.
2. Run a message trace in the Exchange admin center for the sender address and confirm delivery.
3. Re-check the SMTP AUTH clients report after a full business cycle. Migrated senders should no longer show TlsAuthLogin.
4. For relay connectors, keep a record of each public IP and certificate. A changed IP is the most common reason a working relay stops.
5. If you need help, the Microsoft 365 admin center offers a diagnostic for devices and applications that send email, available to administrator accounts.

Troubleshooting

HVE login fails. Check that the HVE account shows Active on the High Volume Email page; Not active means no valid billing policy. If security defaults are enabled, HVE can authenticate only with OAuth, and an authentication policy assigned to the account must allow the method you use.

Relay mail is rejected with 5.7.64 TenantAttribution; Relay Access Denied. The connector doesn't match the source. Update it with the device's current public IP or certificate.

External recipients don't receive mail sent by Direct Send. By design. Use SMTP relay or OAuth client submission instead.

The device won't accept the long MX host name. Microsoft doesn't support using an IP address instead. Use client submission with OAuth, or HVE, which have shorter host names.

Mail from the relay lands in Junk. Add the static IP to the SPF record for the sending domain, and update it whenever the IP changes.

The device only offers port 465. Microsoft notes that a device defaulting to port 465 doesn't support the TLS versions that client submission requires. Update the firmware or use a relay.

Checklist

• SMTP AUTH clients report exported for 90 days; every TlsAuthLogin sender identified.
• Each sender assigned a method: OAuth, HVE, SMTP relay, Direct Send or on-premises relay.
• HVE accounts created with an active billing policy and a Reply-To address where needed.
• Relay connectors created with static IPs or certificates, and SPF updated.
• SMTP AUTH disabled for the organization and enabled only on mailboxes that still need it.
• Any temporary Basic auth exception documented with an owner and an end date.
• Report re-checked after migration with no Basic auth submissions remaining.

References

• Exchange Online to retire Basic auth for Client Submission (SMTP AUTH)
• Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline
• How to set up a multifunction device or application to send email using Microsoft 365 or Office 365
• Fix issues with printers, scanners, and LOB applications that send email using Microsoft 365
• SMTP AUTH clients report in the new EAC
• Manage High Volume Email for Microsoft 365
• Enable or disable SMTP AUTH in Exchange Online
• Deprecation of Basic authentication in Exchange Online