Scan to Email Not Working in Microsoft 365: Fix SMTP Authentication Errors

Start with the exact error text

Scanners are famously unhelpful. Many show only 'Send failed', but most keep a log or test-send screen with the real server response, and that response narrows the problem quickly. If yours genuinely shows nothing, ask whoever manages it whether a log or SMTP test function exists before changing anything in Microsoft 365.

The wording below is what we would look for. Treat it as a pointer to where to look, not a verdict. A rejected sign-in can have several causes and the error text does not always say which.

• 535 5.7.139 Authentication unsuccessful, with text saying SmtpClientAuthentication is disabled for the Tenant or for the Mailbox: SMTP AUTH is switched off at that level. This wording is widely reported in Microsoft's community Q&A rather than listed in Microsoft's own documentation, so confirm it against what your device actually shows. Security defaults can produce the same message even when the mailbox setting is on.
• 535 5.7.3 Authentication unsuccessful: the server rejected the sign-in. Microsoft's own documentation shows this response for a failed authentication attempt. It could be a wrong or changed password, a blocked sign-in method or a policy, so use the checks below to separate them.
• 5.7.60 SMTP; Client doesn't have permissions to send as this sender: sign-in worked, but the scanner is trying to send as a different address from the one it signed in with. The signed-in account needs Send As permission on that other mailbox.
• A timeout, connection refused or TLS/SSL handshake failure with no 5xx code: this is a network or encryption problem, not a Microsoft 365 permissions problem. Port 465 and old TLS versions are the usual suspects, covered in the next section.

Check the scanner's settings (no admin rights needed)

Whoever can open the scanner's web interface or panel can do this part. It costs nothing and rules out the most common self-inflicted cause: settings left over from an older mail system, or a password changed in Microsoft 365 but not on the device.

Microsoft's documented settings for client SMTP submission are below. Different manufacturers label them differently, so check the scanner's own manual for the matching field names.

• Server or smart host: smtp.office365.com. Use the name, not an IP address.
• Port: 587 (recommended) or 25. Port 25 is often blocked by firewalls and internet providers.
• Encryption: STARTTLS or TLS enabled, using TLS 1.2 or TLS 1.3. If the device only offers port 465 or SSL by default, Microsoft says it does not support the TLS versions needed for client SMTP submission. If the scanner cannot do TLS 1.2 at all, go straight to the relay section below.
• Username and password: the full sign-in of a licensed Microsoft 365 mailbox, entered exactly as Microsoft 365 knows it. Re-type the password rather than trusting what the device displays.
• From address: the same mailbox as the sign-in unless that account has been granted Send As on the other address.

Find out what Microsoft 365 is blocking (administrator, read-only)

The commands below only read settings. You need the Exchange Online PowerShell module (ExchangeOnlineManagement) and an account allowed to view Exchange Online configuration. Replace YOUR_SCANNER_MAILBOX with the scanner's sign-in address and YOUR_POLICY_NAME with the policy name reported by the earlier command.

SMTP AUTH has two switches: a tenant-wide one and a per-mailbox one. The mailbox setting overrides the tenant setting, which is why a tenant that has SMTP AUTH turned off can still have scanners working through mailbox overrides.

1. Connect to Exchange Online PowerShell and sign in when prompted.
   powershellCopy

   Connect-ExchangeOnline

2. Check the tenant-wide setting. True means SMTP AUTH is switched off for the organisation.
   powershellCopy

   Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

3. Check the scanner mailbox. False means SMTP AUTH is enabled for that mailbox, True means disabled, and a blank value means it follows the tenant setting.
   powershellCopy

   Get-CASMailbox -Identity YOUR_SCANNER_MAILBOX | Format-List SmtpClientAuthenticationDisabled

4. Check whether Basic authentication is being limited by an authentication policy. The first command shows the organisation's default policy. The second shows whether the scanner user has its own policy, which takes precedence over the default.
   powershellCopy

   Get-OrganizationConfig | Format-Table DefaultAuthenticationPolicy
   Get-User -Identity YOUR_SCANNER_MAILBOX | Format-List Name,AuthenticationPolicy

5. If a policy is assigned, look at its SMTP setting. AllowBasicAuthSmtp should be True for password-based SMTP AUTH to work for users on that policy.
   powershellCopy

   Get-AuthenticationPolicy -Identity "YOUR_POLICY_NAME" | Format-List Name,AllowBasicAuthSmtp

6. Separately, ask whoever manages Microsoft Entra whether security defaults is switched on and whether any Conditional Access policy blocks legacy authentication. Microsoft's documentation says SMTP AUTH is already disabled in Exchange Online when security defaults is enabled, and that Basic client SMTP submission is not compatible with it. The Entra sign-in logs can show legacy authentication attempts from the scanner's mailbox.

Allow SMTP AUTH for the scanner's mailbox only

If the mailbox or tenant check showed SMTP AUTH disabled and nothing else is blocking it, enable it for the one mailbox rather than the whole organisation. Microsoft itself recommends keeping SMTP AUTH off organisation-wide and enabling it only for accounts that still need it.

This change keeps a password-based sign-in alive for that mailbox, so use a dedicated licensed account for the scanner with a long unique password, not a person's own mailbox. It only affects that one account, and you can undo it by setting the value back to True, or to null to follow the tenant setting. Microsoft does not publish a guaranteed propagation time for this setting, so allow some time before deciding it has not worked.

1. In your existing Exchange Online PowerShell session, enable SMTP AUTH for the scanner mailbox.
   powershellCopy

   Set-CASMailbox -Identity YOUR_SCANNER_MAILBOX -SmtpClientAuthenticationDisabled $false

2. Confirm the change. The property should now read False.
   powershellCopy

   Get-CASMailbox -Identity YOUR_SCANNER_MAILBOX | Format-List SmtpClientAuthenticationDisabled

3. Send a test scan and check whether the error has changed. If it still fails with the same message after a reasonable wait, move on to the next section.

If an authentication policy blocks password-based SMTP

Do this only if the earlier check showed an authentication policy with AllowBasicAuthSmtp set to False for the scanner's account. If security defaults or a Conditional Access rule blocking legacy authentication is the cause, do not switch those off just to get a scanner working. They protect every account in the organisation, and a relay connector (below) avoids the problem entirely.

The least invasive approach is a separate policy that allows Basic authentication for SMTP only, assigned to the scanner account alone. A new policy blocks every Basic authentication protocol by default, so the one switch you specify is the only thing allowed. Microsoft says policy changes normally take effect within 24 hours.

1. Create the policy, allowing only authenticated SMTP.
   powershellCopy

   New-AuthenticationPolicy -Name "Scanner SMTP only" -AllowBasicAuthSmtp

2. Assign it to the scanner's account. This replaces whatever policy that account had, so only do this for a dedicated scanner account.
   powershellCopy

   Set-User -Identity YOUR_SCANNER_MAILBOX -AuthenticationPolicy "Scanner SMTP only"

3. Optionally, ask Microsoft 365 to apply it sooner. Microsoft says this usually brings the wait down to about 30 minutes.
   powershellCopy

   Set-User -Identity YOUR_SCANNER_MAILBOX -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

4. Retest with a scan. A successful sign-in is the only confirmation that matters here.

Why a working fix may be temporary

As of October 2026, Microsoft's most recent published timeline for retiring Basic authentication for SMTP AUTH client submission says behaviour is unchanged until the end of December 2026. At that point Basic authentication is planned to be disabled by default for existing tenants, with administrators still able to enable it if needed. Tenants created after that date are not expected to have it by default, and Microsoft plans to announce a final removal date in the second half of 2027. Earlier March and April 2026 enforcement dates still quoted on some sites have been superseded.

Two practical points follow. First, the enabling steps above are a bridge, not a destination. Most scanners cannot sign in with OAuth, the replacement method, and only the manufacturer can add that, so check whether firmware or a newer model offers it. Second, if a scanner that worked in December stops in January, check the tenant-wide setting first. The sources we read do not describe exactly how Microsoft will apply the default change, so verify against your own tenant then rather than assuming. This timeline concerns client submission with a mailbox sign-in; it does not describe a change to IP-based relay connectors.

Use a relay connector when the scanner cannot sign in properly

If the scanner cannot do TLS 1.2, cannot be updated, or you would rather not keep a password-based mailbox sign-in alive, an SMTP relay connector is Microsoft's documented alternative for devices. Instead of signing in, the scanner connects on port 25 from a fixed public IP address that you tell Microsoft 365 to trust.

This needs a static public IP address that is not shared with anyone outside your organisation. Dynamic addresses are not supported. Anything sending from that IP address will be accepted as your organisation, so keep it to your own network. Relay cannot be used for services hosted by third parties such as Azure, and Microsoft imposes reasonable but unpublished sending limits. For a scanner with ordinary office volumes that should not matter. You need rights to manage mail flow connectors, and you should also be able to edit your domain's DNS records or have whoever manages them on hand.

Other options exist, such as Microsoft's High Volume Email, which only sends to internal recipients, Azure Communication Services Email or an on-premises mail server. They are separate designs and beyond the scope of this fix.

1. Find the public IP address your office uses to reach the internet (the scanner's traffic must leave from it).
2. In the Exchange admin center, go to Mail flow, then Connectors, and select Add a connector.
3. Under Connection from, choose Your organization's email server. Connection to shows Office 365 automatically. Select Next.
4. Give the connector a clear name. Make sure Turn it on is selected and Retain internal Exchange email headers is not.
5. On the Authenticating sent email page, choose the option that verifies the IP address of the sending server, enter your public IP address, then review and select Create connector.
6. Update the scanner: server is your domain's MX endpoint (it looks like YOURDOMAIN-com.mail.protection.outlook.com, and your domain's DNS records page in the Microsoft 365 admin center shows the exact value), port 25, TLS enabled, and a sender address in one of your accepted domains. No mailbox is required and the scanner does not sign in.
7. Add the public IP address to your domain's SPF record, otherwise messages are more likely to be treated as spam.

Confirm the scan arrives

Send a test scan to an internal address and then to an external one, since some setups behave differently for each. Relay-connector mail from the scanner should be accepted for any recipient the connector allows.

If you used mailbox sign-in, the scanner's Sent Items folder should contain a copy of each message, because Microsoft 365 saves mail sent through client submission there (relay does not do this). The scanner's own log should show a successful authentication, normally a 235 response. If messages are accepted by the scanner but never appear, a message trace in the Exchange admin center shows what Microsoft 365 did with them. Check the recipient's Junk folder as well.

If it still fails

Work through the remaining causes in this order. Each one points to a different team, which is often the quicker way to find the real owner.

• Send As error (5.7.60): grant the signed-in account Send As on the address the scanner uses as sender, or set the scanner's From address to the signed-in mailbox.
• Connection errors: port 587 or 25 may be blocked between the scanner and the internet. Test from another device on the same network segment. Port 465 is not supported for this method.
• Mailbox with no licence: client submission needs a licensed Microsoft 365 mailbox. An unlicensed account or a mailbox with no licence assigned will not authenticate.
• Throttling: Microsoft's documented client submission limits are 10,000 recipients a day and 30 messages a minute. A scanner emailing many people at once can hit the rate limit.
• Still rejected with the correct password: ask your identity administrator to check the Entra sign-in logs for that account and see whether security defaults or Conditional Access is the one refusing it. At this point you are looking at a policy decision, not a scanner fault.
• Scanner firmware too old: if it cannot do TLS 1.2, no Microsoft 365 setting will help. Use a relay connector or an on-premises relay, or replace the device.