SMTP Error 534

What does SMTP Error 534 mean?

SMTP 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 authentication mechanism is weaker than server policy permits for that user. The client SHOULD retry with a new authentication mechanism." In other words, your credentials may even be correct — but the SASL mechanism you negotiated (or the channel it ran over) doesn't satisfy the server's security policy. The enhanced code 5.7.9 is registered in the IANA registry with the description "Authentication mechanism is too weak" (Reference: RFC 4954).

This is distinct from a flat credential rejection (535 5.7.8, authentication credentials invalid) and from a missing-auth error (530 5.7.0, authentication required). A 534 specifically says: authenticate, but with something stronger.

Why Gmail and Google Workspace return 534

On Google's SMTP servers, 534 most often appears in two provider-specific variants documented in Gmail SMTP errors and codes:

• Application-specific password required. You tried to log in with LOGIN/PLAIN using your normal account password on an account that has 2-Step Verification. Google rejects the plain password and requires an App Password or OAuth2 instead. Gmail's on-the-wire reply for this case has long been observed (across many independent bounce reports, 2023–2025) as 534-5.7.9 ... Application-specific password required, linking to Google's InvalidSecondFactor help page. Note: Google's own help-center table currently labels this row 534/5.7.90, not 5.7.9 — an inconsistency on Google's side. If your bounce shows 5.7.90 instead of 5.7.9, treat it identically: the fix (App Password or OAuth2) is the same regardless of which suffix you see.
• "Please log in with your web browser and then try again." Google is forcing an interactive browser sign-in (a security challenge) before it will trust the connection — common after a new IP, a suspicious-activity flag, or a first OAuth grant. Google's docs list this same message text under two different codes, 534/5.7.14 and 534/5.7.90 — match on the message text, not the code suffix, when you're troubleshooting this scenario. For reference, IANA's RFC 5248 registry ties the enhanced code X.7.14 ("Trust relationship required") to basic codes 535 and 554, not 534 — so Google's 534+5.7.14 pairing is its own non-standard combination, not an RFC-sanctioned one.

Important: Google disabled Less Secure App access for personal Gmail accounts on May 30, 2022 — don't look for that toggle, it no longer exists there. Google Workspace accounts had a separate, later phase-out: paused in late 2024, resumed January 2025, OAuth required from March 14, 2025, and fully enforced from May 1, 2025. If you administer a Workspace domain, don't assume the 2022 personal-Gmail date applied to you. Either way, the supported paths going forward are OAuth2 or an App Password.

How do I fix SMTP Error 534?

1. Use a strong auth method (most common fix). For Gmail/Google Workspace, switch from your account password to one of:

• OAuth2 (XOAUTH2) — preferred for servers and apps; obtain a token via Google's OAuth flow and pass it as the SASL XOAUTH2 credential.
• App Password — enable 2-Step Verification, then generate an App Password and use that 16-character value as the SMTP password.

2. Authenticate over TLS. Some servers treat plaintext mechanisms as "too weak" unless the session is encrypted. Connect on port 587 with STARTTLS or port 465 with implicit TLS — both are valid per RFC 8314; 465 is not deprecated. Issue AUTH only after the connection is secured.

smtp.gmail.com  587  STARTTLS  (AUTH PLAIN / XOAUTH2 after TLS)
smtp.gmail.com  465  TLS       (AUTH PLAIN / XOAUTH2)

3. For the browser-challenge variant (534 5.7.14 / 534 5.7.90), complete the browser challenge. Sign in to the account once in a browser from a trusted device and network, and clear any "Critical security alert" Google has flagged, then retry the SMTP connection within a few minutes. For unattended servers, migrate to OAuth2 so Google stops issuing the interactive challenge. (Note: Google's old DisplayUnlockCaptcha unlock page has been retired and no longer grants access, so don't rely on it.)

4. Offer a stronger SASL mechanism. RFC 4954 says the client SHOULD retry with a new authentication mechanism. If your server advertises XOAUTH2, SCRAM-*, or CRAM-MD5 and rejects what you sent, configure your client to prefer the stronger one rather than PLAIN/LOGIN.

5. Verify with your provider. Amazon SES, SendGrid, and Mailgun use their own SMTP credentials/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's SMTP integration docs.

If you relay through Courier, configure the email provider's SMTP/OAuth credentials in the Courier dashboard rather than embedding a raw account password, so the upstream sees a policy-compliant mechanism.