SMTP error 534
Authentication mechanism too weak.
Updated Jul 1, 2026
SMTP 534 is an authentication-rejection reply from the SMTP AUTH extension (RFC 4954). The canonical form, 534 5.7.9 "authentication mechanism is too weak", means the SASL mechanism you offered is weaker than the server policy allows. Fix it by upgrading auth: on Gmail or Google Workspace use OAuth2 or a 2-Step-Verification App Password over TLS on port 587 or 465, not your normal password.
Use OAuth2 or an App Password over TLS.
What it means
534 is a negative reply to the AUTH command, defined by the SMTP Service Extension for Authentication (RFC 4954). Its canonical text is "534 5.7.9 Authentication mechanism is too weak". Per RFC 4954 this means the selected mechanism is weaker than server policy permits for that user, and the client should retry with a new mechanism. Your credentials may even be correct, but the SASL mechanism you negotiated, or the channel it ran over, does not satisfy policy. The enhanced code 5.7.9 is registered in the IANA registry with that description. This is different from a flat credential rejection (535 5.7.8) and from a missing-auth error (530 5.7.0): 534 says authenticate, but with something stronger.
Common causes
You logged in with LOGIN or PLAIN using your normal password on an account with 2-Step Verification. Google rejects the plain password and requires an App Password or OAuth2. The on-the-wire reply has long been seen as "534-5.7.9 ... Application-specific password required". Google help currently labels this row 534/5.7.90 rather than 5.7.9, an inconsistency on Google side; if your bounce shows 5.7.90, treat it identically, since the fix is the same.
Google is forcing an interactive browser sign-in before it trusts the connection, common after a new IP, a suspicious-activity flag, or a first OAuth grant. Google docs list this message under two codes, 534/5.7.14 and 534/5.7.90, so match on the message text rather than the suffix. For reference, the RFC 5248 registry ties X.7.14 ("trust relationship required") to 535 and 554, not 534, so Google 534 plus 5.7.14 pairing is its own non-standard combination.
Some servers treat PLAIN or LOGIN as too weak unless the session is already encrypted with TLS.
How to fix it
- Use a strong auth method
For Gmail or Google Workspace, switch from your account password to OAuth2 (XOAUTH2), preferred for servers and apps, obtained via Google OAuth flow and passed as the SASL XOAUTH2 credential; or an App Password, by enabling 2-Step Verification, generating the 16-character value, and using it as the SMTP password.
- Authenticate over TLS
Connect on port 587 with STARTTLS or port 465 with implicit TLS, both valid per RFC 8314, and issue AUTH only after the connection is secured. For Gmail: smtp.gmail.com 587 STARTTLS, or smtp.gmail.com 465 TLS, with AUTH PLAIN or XOAUTH2 after TLS.
- For the browser-challenge variant (5.7.14 or 5.7.90), complete the challenge
Sign in to the account once in a browser from a trusted device and network, clear any critical security alert Google flagged, then retry the SMTP connection within a few minutes. For unattended servers, migrate to OAuth2 so Google stops issuing the challenge. The old DisplayUnlockCaptcha page has been retired and no longer grants access.
- Offer a stronger SASL mechanism
RFC 4954 says the client should retry with a new mechanism. If your server advertises XOAUTH2, SCRAM, or CRAM-MD5 and rejects what you sent, configure your client to prefer the stronger one over PLAIN or LOGIN.
- Verify with your provider
Amazon SES, SendGrid, and Mailgun use their own SMTP credentials or API keys, not your console password, and require TLS. A 534-class rejection there usually means you used the wrong credential type. Check the provider SMTP docs.
Paired code
A real bounce often shows both a 3-digit code and an enhanced code together. This one commonly pairs with:
Common questions
Is SMTP 534 the same as 535?
No. 535 5.7.8 means the username and password pair was rejected outright. 534 5.7.9 means the mechanism itself is too weak for policy; your credentials might be valid, but you need a stronger method such as OAuth2, an App Password, or auth over TLS.
Why do I get 534 5.7.9 with the correct Gmail password?
On an account with 2-Step Verification, Google refuses the plain password over SMTP and requires an App Password or OAuth2 instead. The password being correct does not matter; the mechanism is what Google rejects.
What is the difference between 534 5.7.9 and 534 5.7.14?
5.7.9 means the mechanism is too weak, fixed with an App Password or OAuth2 over TLS. 5.7.14 (and Google 5.7.90) is the browser-challenge case, where Google wants an interactive sign-in first; match on the message text and, for servers, move to OAuth2.