SMTP AUTH error messages and what they mean
If you searched or pasted an error and landed here, find it below. These are the messages Microsoft 365 and its clients produce when username-and-password authentication for SMTP is refused.
None of them mean your password is wrong. They mean the authentication method is switched off, which is a different problem with a different fix.
Or skip the reading and paste it:
npx zerosmtp-check --explain "535 5.7.139 Authentication unsuccessful"
Whatever your own client printed works — a Postfix SASL line, a Python traceback, 1102 off a Kyocera panel, or curl: (67) Login denied, which shows none of the server’s answer at all. It says which of the four cases you are in and whether it can still be switched back on. Nothing installed, nothing sent.
Why the same error has four different causes
Basic auth for SMTP AUTH gets refused in four situations, and the client-side message is identical in all of them. Knowing which one you are in decides whether you can simply turn it back on:
| Cause | Can you re-enable it? |
|---|---|
| An admin disabled SMTP AUTH for the tenant or the mailbox | Yes, until the December 2026 default flip |
| Security Defaults — on by default for tenants created recently | Yes, but it disables more than SMTP and turning it off weakens the tenant |
| A Conditional Access policy blocking legacy authentication | Yes, by scoping the policy — usually deliberate, so ask why it exists first |
| The end-of-December-2026 default change | No |
Before December 2026 the first three are the likely answer, and the fix may be a setting rather than a migration. After it, re-enabling is no longer an option — see the migration guide.
Microsoft 365 / Exchange Online
Each of these has a page of its own with the full diagnosis — follow the error you actually saw.
| Error | What it means | | — | — | | 535 5.7.139 Authentication unsuccessful, basic authentication is disabled | Microsoft 365 refused username-and-password authentication. | | 535 5.7.139 SmtpClientAuthentication is disabled for the Tenant | The same refusal, reported at tenant level: the block applies to every mailbox that inherits the tenant setting, not just the one you are testing. | | 535 5.7.139 SmtpClientAuthentication is disabled for the Mailbox | The same refusal, reported for this one mailbox. | | 535 5.7.3 Authentication unsuccessful | A generic refusal with the same set of causes as 5.7.139, but without the sub-code that tells you which. | | 5.7.12 Sender was not authenticated by organization | The receiving organisation, not yours, refused the message because the sender was not authenticated to it. | | 5.7.133 Sender not authenticated for group | The same rule as 5.7.134, applied by a group or distribution list rather than a mailbox. | | 5.7.134 Sender was not authenticated for mailbox | The recipient mailbox accepts mail only from authenticated senders, and this connection was not one. | | 5.7.136 Sender was not authenticated | The connection reached Exchange Online and sent the message without ever authenticating. | | 535 5.7.57 SMTP; Client was not authenticated to send anonymous mail | A different problem from the ones above: the client sent no credentials at all, or sent them after MAIL FROM instead of before. | | 5.7.232 Trial tenant has exceeded its daily limit for sending email | A trial tenant carries a much lower daily ceiling than a paid one, and hitting it during a migration test is common enough to be worth naming: the setup looks broken when it is merely capped. | | 5.7.233 Tenant exceeded its daily limit for sending email to external recipients | The ceiling here is on external recipients specifically, so internal mail keeps working while everything leaving the organisation stops. | | 5.7.236 Tenant has exceeded its daily limit for sending email | The tenant-wide ceiling. | | 5.4.1 Relay Access Denied | The recipient address is not one this server is willing to accept and forward on behalf of. | | 5.7.367 Remote server returned not permitted to relay | A server further along the path refused to relay the message onward. | | 5.7.64 TenantAttribution; Relay Access Denied | Authentication is not the problem here - the message was accepted and then could not be attributed to a connector that permits relay. | | 530 5.7.1 Delivery not authorized | Authentication is required and was not completed, or the authenticated account is not allowed to send as the address in the From field. | | 550 5.7.60 SMTP; Client does not have permissions to send as this sender | Authentication succeeded. |
Which mailboxes are still exposed on your own tenant is answerable in one command — see Find-SmtpAuthExposure.ps1. It is read-only, and it counts the mailboxes that inherit the tenant setting rather than having their own, which the usual one-liner misses.
Device and application wording
Vendors rarely pass the server’s message through. These are the same refusal in local dress:
| What you see | Where | What it means |
|---|---|---|
Send error 1102 / 0x1102 | Kyocera MFPs | Kyocera’s code for an SMTP authentication failure |
Authentication failed / Login failed on the panel | Most printer and scanner panels | Vendor wording for the above |
SMTPAuthenticationError (535, ...) | Python smtplib | The 535 above, wrapped |
javax.mail.AuthenticationFailedException | Java / JavaMail | Same |
AuthenticationInvalidCredentials / 5.7.139 | .NET, MailKit | Same |
| Backup or monitoring job reports “email failed”, no code | Veeam, Zabbix, Nagios, PRTG and similar | Check the tool’s own SMTP log; the 535 is usually there |
Alerting tools are the dangerous case: they fail silently, so you find out during the incident they were supposed to warn you about. What breaks has the audit list.
Not authentication at all
Two failures get mistaken for this and have unrelated fixes:
| Symptom | Actual cause |
|---|---|
| Connection times out, no auth error ever appears | The network is blocking outbound SMTP. Cloud providers block port 25 and often 587 by default — see troubleshooting. |
Certificate verify failed / unable to get local issuer certificate | The device’s trust store cannot validate the server certificate. Common on hardware whose firmware predates current root CAs — see the Canon Maxify MB2755 case. |
What to do next
- Establish which of the four causes applies. If it is one of the first three, re-enabling may be the whole fix.
- If firmware or software is the blocker, check whether your vendor shipped an OAuth update — and whether they have stated they will not. Models the vendor has ruled out are listed in devices that will never get OAuth firmware.
- If nothing on the device can change, the sending has to move: Direct Send for internal-only recipients, or a relay that still accepts a username and password. The migration guide covers every option, including the ones that are not this project.
An error not listed here?
Open an issue with the exact string and what produced it. Errors reported from real hardware and real software are worth more than anything transcribed from documentation, and get added here.
Updated 23 Aug 2026