How to Troubleshoot Gmail SMTP 535 5.7.80 in 2026?

This week, treat Gmail SMTP 535 5.7.80 as an authentication rejection: verify the mechanism and credentials your client actually sends, then test authentication, message submission, and controlled receipt separately. This applies when you are testing your own product or an environment you are authorized to use.

For developers diagnosing a test program: identify the exact stage where Gmail rejects SMTP AUTH.
For QA engineers validating email regressions: collect separate evidence for authentication, submission, and receipt.
For independent developers maintaining a test environment: keep tokens, passwords, and full verification links out of logs.

Gmail SMTP 535 5.7.80 troubleshooting: rejection versus delivery

Google’s Gmail SMTP error guidance associates 535 5.7.80 with a username and password that are not accepted. That description identifies an authentication problem. It does not prove that a message entered Gmail’s delivery process, landed in spam, or reached a recipient.

This distinction matters because a test can stop before Gmail accepts any message content. If the server returns the error during AUTH, changing a recipient address or searching its spam folder will not resolve that authentication exchange. First locate the last successful SMTP command in the client’s trace. Redact secrets before sharing the trace or saving it in a ticket.

Keep the outcomes separate:

• Authentication: Did Gmail accept the client’s SMTP AUTH exchange?
• Submission: After authentication, did Gmail accept the message for processing?
• Receipt: Did the controlled recipient mailbox actually receive the message?

These are separate checkpoints, not interchangeable descriptions of “email works.” RFC 4954 defines general SMTP AUTH response behavior. It helps explain the protocol boundary, but it cannot tell you why Gmail rejected a particular account, application, or credential.

Key takeaway: 535 5.7.80 points to rejected authentication; it is not a diagnosis of the later delivery path.

A useful incident note says “AUTH rejected before message submission,” rather than “the test email went to spam.” The first statement describes evidence. The second assumes a message was sent when the exchange may have stopped earlier.

The configured mechanism versus the one actually sent

Gmail’s SMTP documentation supports OAuth 2.0 authentication for SMTP, and Google documents SASL XOAUTH2 as the authentication mechanism. The practical question is not whether your application supports OAuth in general. It is whether this particular SMTP connection uses the mechanism you intended.

A common debugging trap is to inspect the application’s settings page, see an OAuth option, and assume the wire-level exchange uses it. A stale environment variable, a different configuration file, a fallback authentication mode, or a separate test process can leave the client sending a different mechanism. Confirm what the running process uses, not what its source code appears to request.

Use Google’s XOAUTH2 protocol specification to check the expected exchange format. It includes the account identity and a bearer token in a SASL XOAUTH2 payload. Compare the configured mailbox with the identity represented in the authorization flow, and check that the client is passing the token as a bearer credential through XOAUTH2. Do not print the payload into an ordinary application log: it contains sensitive authentication material.

If a trace shows the client attempting another AUTH mechanism, troubleshoot that configuration first. Do not attribute an error from one mechanism to an OAuth token that the client never sent. Conversely, if the client does use XOAUTH2, verify the token and identity without assuming the mechanism alone guarantees acceptance.

Account, token, and authorization alignment

A token can look plausible in a configuration file and still fail in the SMTP session. The account that authorized the application, the mailbox the client presents in XOAUTH2, and the account your test expects to send from must agree. A mismatch is especially easy to miss when a developer’s local environment and a QA runner use different secrets or identity settings.

Check the following without exposing credential contents:

• Mailbox identity: Compare the configured sending account with the account used to authorize the client. Do not assume that a successful login in a separate browser session confirms the identity used by the test process.
• Authorization: Review the scopes or permissions requested and granted by the application. Google’s OAuth 2.0 documentation for server-side applications explains the authorization flow; apply it to the account and application actually used by the SMTP client.
• Token state: Confirm the application is obtaining and using a current token for the connection. Check token refresh and authorization handling in the client, but never write token values to diagnostic output.
• Mechanism: Verify that the SMTP AUTH request uses SASL XOAUTH2 rather than a different login method.

Do not collapse similar-looking authentication errors into a single cause. Google’s error documentation describes 535 5.7.80 in terms of credentials not being accepted. That wording does not prove that a token is expired, that a scope is missing, or that a password was mistyped. Those are possibilities to investigate against the client configuration and the actual response—not conclusions established by the code alone.

Decision branches for the next check

• If the trace shows no AUTH attempt, check connection setup and client configuration before investigating credentials.
• If AUTH is attempted with a mechanism other than the intended XOAUTH2 flow, fix the active mechanism or its configuration, then repeat the test.
• If XOAUTH2 is present but Gmail returns 535 5.7.80, compare the presented mailbox, authorized account, token acquisition, and authorization settings. Keep the response text as evidence; do not choose a single cause without confirming it.
• If authentication succeeds, stop treating 535 as the current failure. Move on to message submission and controlled receipt.

This branch-based approach keeps the diagnosis tied to what the client actually did. It also prevents a token change from being credited with fixing a problem that was really caused by a different runtime configuration.

Connection setup versus SMTP AUTH rejection

A TLS or connection problem occurs at a different stage from an AUTH rejection. Start by checking the SMTP host, the client’s selected TLS connection method, and whether the connection reaches the point where the client attempts AUTH. Confirm these settings against Google’s current Gmail SMTP connection documentation, rather than copying an unverified host or port from an old setup note.

Then read the trace in order. If the client cannot establish the configured connection, the failure is not evidence that Gmail rejected its username, password, or OAuth token. If the trace shows that the connection is established and Gmail returns 535 after AUTH, focus on the mechanism and credentials. Keeping those stages separate avoids changing transport settings to “fix” a credential rejection—or rotating credentials to address a connection that never reached authentication.

A practical case: a QA runner may pass locally but fail in the test environment after a secret or connection setting changes. Compare the two environments’ effective configuration, including which process loads the credentials and which AUTH mechanism it selects. Do not copy a complete authorization exchange into a bug report. Preserve the command sequence and response text, while redacting tokens and account details that are not needed for diagnosis.

Authentication recovery versus received mail

After Gmail accepts AUTH, send a controlled message through your own product. Make the test easy to identify without putting personal data or secrets in the subject or body. Record three separate results in the test report:

• AUTH result: the client’s authentication outcome and the mechanism it used.
• Submission result: the SMTP response after the client sends the message. Record the response at this stage; do not rewrite it as proof of inbox delivery.
• Receipt result: whether the controlled test mailbox received the matching message, including whether it appeared in spam or another folder.

This separation reflects the SMTP boundary. RFC 5321 describes the responsibilities associated with accepting a message for processing; acceptance by an SMTP server is not the same observation as a recipient confirming receipt in a mailbox. A successful AUTH exchange is earlier still: it says nothing by itself about message submission.

Use a controlled test recipient that your team is authorized to use. If your workflow needs a disposable address for a short-lived registration or notification test, choose a mailbox you can inspect during the test and avoid sending real personal information. SendTmp may be one option for controlled testing; it should not be treated as a guarantee that every sender, message, or delivery path will work. For broader guidance on limiting personal data in test workflows, see our notes on email privacy.

Evidence quality and safe test logs

A useful diagnostic record should let another engineer reconstruct the sequence without revealing a secret. Keep the original error text, the stage where it appeared, the active AUTH mechanism, the SMTP connection outcome, and a redacted test correlation value. If you are investigating recipient receipt, record the test mailbox result separately from the SMTP trace.

Do not include access tokens, passwords, full verification URLs, or complete authentication payloads in tickets, screenshots, CI logs, or shared chat. A verification link can grant account access just as surely as a credential. When a trace is necessary, remove sensitive values while retaining enough structure to see which command and response belong together.

State the result with a clear limit: “AUTH passed in this test run,” “the SMTP server accepted the submission,” or “the controlled mailbox received the message.” Avoid claiming that Gmail delivery is generally fixed based on one test. The conclusion applies to the tested product configuration, account, recipient, and environment.

When the recipient is temporary, check its actual availability and retention rules before relying on it for a regression run. Our guide to the email lifecycle explains why a short-lived inbox is different from a mailbox intended for password recovery or long-term correspondence. Do not use a disposable address for a critical account that must remain recoverable.

FAQ

What does Gmail SMTP 535 5.7.80 tell me?

Google describes this response as a case where the username and password are not accepted. It tells you Gmail rejected authentication, but it does not identify the exact cause or prove that a message was submitted. Check the client’s configured mechanism and credentials, then inspect the SMTP stage where the response occurred.

How can I tell whether my client uses OAuth 2.0 for Gmail SMTP?

Inspect the SMTP library configuration and the authentication exchange in a safe, redacted trace. OAuth-based Gmail SMTP authentication uses SASL XOAUTH2, with the account identity and bearer token in the mechanism’s defined format. A successful browser sign-in alone does not prove that the SMTP client is actually sending XOAUTH2.

Why can Gmail reject a valid OAuth token over SMTP?

A token that appears valid may still belong to a different Google account, lack the authorization needed for the requested Gmail operation, or no longer be usable when the SMTP connection is made. Compare the account identity, granted authorization, token lifecycle, and client’s actual AUTH mechanism. Do not infer the cause from a similar-looking error alone.

How do I confirm a test email arrived after Gmail SMTP authentication succeeds?

Record the SMTP response to the message submission separately from receipt at a controlled mailbox. Then check that mailbox, including its spam folder, and match the message using a non-sensitive test identifier. An authentication success proves only that the AUTH exchange passed; a submission response does not by itself prove inbox placement.

Once Gmail SMTP 535 5.7.80 is resolved, the final check is still the controlled recipient—not just a green authentication result. For a short-lived registration, notification, or verification test, SendTmp offers an option to receive test mail without exposing your primary address or flooding its inbox. Keep long-term and recovery-critical accounts on a mailbox you control; use a temporary inbox only when the test does not depend on lasting access.