Diagnose SMTP 535 errors by separating credentials, authentication mechanisms, TLS, tokens, and organization policy—without exposing secrets or retrying bad logins indefinitely.
SMTP 535 means the mail server rejected an authentication attempt. The connection reached the AUTH stage, but the supplied identity, credential, authentication mechanism, or account policy was not accepted. Fix the authentication path before retrying; changing the recipient address, message content, SPF, or DKIM will not solve an AUTH rejection.
Where a 535 error happens
1 TCP connect to the submission server
2 Server greeting
3 EHLO and advertised capabilities
4 STARTTLS, when used, then EHLO again
5 AUTH using an advertised mechanism
6 235 success — or 535 authentication rejected
7 MAIL FROM, RCPT TO, and DATA happen only after success
A 535 failure occurs before recipient acceptance and message delivery.RFC 4954 defines the SMTP AUTH extension and assigns 535 to invalid or insufficient authentication credentials. Providers add enhanced codes and human-readable diagnostics that narrow the cause. Because the message has not reached MAIL FROM or RCPT TO, recipient reputation and mailbox existence are not the immediate issue.
Common 535 variants
Authentication unsuccessfulCommon in Microsoft environments. Verify the credential and whether SMTP AUTH is permitted for the mailbox and organization.
Username and password not acceptedCommon in Gmail and other providers. The password type, OAuth token, username, or account security state may be wrong.
Authentication blocked by organization configurationMicrosoft documents this when the organization does not permit the authentication request in its current context.
Application-specific password requiredNot technically 535, but frequently confused with it. Follow the provider's current sign-in policy rather than reusing the normal password.
Unrecognized authentication typeThe client requested a mechanism the server does not support.
Authentication or TLS requiredThe session may need STARTTLS or authentication before the requested SMTP command.
Fix SMTP 535 in the right order
- Confirm the SMTP hostname belongs to the provider for this account. An incoming IMAP host, MX record, or unrelated regional endpoint is not automatically a submission endpoint.
- Match port and encryption exactly: commonly port 465 with implicit TLS or port 587 with STARTTLS. Do not set both modes or send credentials over plaintext.
- Inspect EHLO after TLS and use an authentication mechanism the server advertises. Capabilities can change after STARTTLS.
- Verify the username format. Many providers require the full email address, while API-backed SMTP services may use a fixed literal username and an API key as the password.
- Verify the credential type. A normal account password, app password, OAuth access token, API key, and SMTP-specific credential are not interchangeable.
- Check whether the account is enabled, licensed, unlocked, and permitted to use SMTP submission. Then check organization-wide security and SMTP AUTH policy.
- For OAuth, verify audience, scopes, tenant, mailbox authorization, expiration, and the exact SASL mechanism. Refresh an expired access token rather than retrying it.
- Test one controlled connection, preserve the complete response, and stop after a small number of failures to avoid lockout and noisy security alerts.
Username or password rejected
First eliminate transcription and deployment errors: trailing whitespace, shell quoting, a secret mounted under the wrong name, a key copied from another environment, an old credential left in a worker, or a username that differs from the authenticated mailbox. Check secret metadata or a fingerprint, not the secret value itself. If you rotate a credential, update all producers and revoke the old one after the new path is proven.
SMTP_HOST=smtp.provider.example
SMTP_PORT=587
SMTP_SECURITY=starttls
[email protected]
SMTP_AUTH_METHOD=oauth2-or-provider-supported-method
SMTP_SECRET_SOURCE=production-secret-reference
Log host, port, mode, mechanism, and secret version—not SMTP_SECRET.App passwords and multifactor authentication
Some accounts with multifactor authentication support application-specific passwords for legacy clients. Others require OAuth and do not offer app passwords. An app password is still a long-lived secret: store it in a secret manager, scope its use, rotate it after exposure, and never embed it in frontend code. Follow the provider's current account documentation because availability depends on account type and security policy.
Microsoft 365 and SMTP AUTH policy
In Microsoft 365, authentication can fail even when a password is correct. SMTP AUTH can be controlled at the organization and mailbox levels, and security defaults or authentication policy can block legacy authentication. Microsoft's own 535 5.7.139 guidance points to organization configuration as the cause in that case. Do not weaken tenant-wide security merely to keep an old client working; prefer OAuth or a Microsoft-supported sending route and make the smallest reviewed policy change if legacy SMTP is truly required.
Gmail 535 errors
Google's SMTP error catalog associates 535 5.7.80 with a username or password the server did not accept and 534 5.7.90 with a required application-specific password. Verify that the account is allowed to use the chosen method and that the application is not attempting an obsolete password-only flow. For Google Workspace applications, prefer Google's supported OAuth or relay design for the actual use case.
Why blind retries make the incident worse
A credential or policy failure is not transient merely because it came from a network protocol. Fast automatic retries can lock an account, trigger abuse detection, obscure the first useful diagnostic, and flood logs with sensitive authentication context. Retry temporary connection and 4xx conditions with bounded backoff. Treat a repeatable 535 as configuration requiring intervention.
A production incident checklist
WHEN UTC timestamps and first known failure
WHERE application, environment, region, worker, SMTP endpoint
SESSION port, TLS mode, EHLO capabilities, AUTH mechanism
RESPONSE complete 535 + enhanced code + provider diagnostic
IDENTITY mailbox/account identifier and tenant, safely redacted
SECRET type, version, rotation time, expiration — never its value
POLICY mailbox SMTP AUTH, organization policy, account status
CHANGE deploy, rotation, MFA, provider, DNS, or tenant change
CONTROL retry stopped, affected jobs held, owner assignedFrequently asked questions
Is SMTP 535 a deliverability error?
It is a submission authentication error. The server has not accepted the message for delivery, so inbox placement, recipient existence, SPF, DKIM, and content are downstream questions. Authentication reliability still matters operationally, but the fix belongs at the client-to-server AUTH stage.
Will changing the From address fix 535?
Usually no. AUTH happens before MAIL FROM and message headers. After authentication succeeds, a provider may separately reject a From address the account is not authorized to use, but that is a different stage and response.
Should I enable basic authentication?
Do not broadly re-enable a weaker sign-in method as a first fix. Determine which supported mechanism the provider expects and use OAuth, an SMTP-specific credential, a relay, or an email API where appropriate. Any exception should be narrow, documented, and reviewed.