SMTP error 534 is not a single, well-defined condition the way 535 is. It is a base reply
code that several large providers reuse for different authentication-upgrade requirements,
distinguished only by the enhanced status code and free text that follows it. Reading 534 alone
and searching for "the fix" is the wrong approach - the three real variants below need three
different responses.
Fault: sender, in every variant - the account itself is reachable, but the credential or
sign-in method presented does not meet the account's current security requirements.
The three real variants
- `534 5.7.9 Application-specific password required` - the account has two-step verification
enabled, and the account's normal password is being rejected on purpose. An app password (a
16-character, single-purpose credential generated separately) is required for SMTP.
- `534-5.7.14 Please log in via your web browser and then try again` - Google's response when
it wants an interactive sign-in challenge completed (often after a new location, a new device,
or a suspicious pattern of failed logins) before SMTP access will be allowed again.
- `534 5.7.1` (less common, some other providers) - used by a handful of non-Google/Microsoft
systems as an encryption-level requirement: the connection's cipher or TLS version does not
meet the account's minimum.
None of these three variants is about whether the password string you typed is correct character
for character. That is precisely what makes 534 confusing to troubleshoot: every instinct says
"check the password," and in every real-world case the password is beside the point. The account
itself has decided that password-only authentication, at this moment, through this channel, is
not sufficient - and no amount of re-typing changes that decision.
The transcript
$ swaks --to test@mailpilots.in --server smtp.gmail.com:587 \
--auth LOGIN --auth-user sender@gmail.com -tls
-> AUTH LOGIN
<- 334 VXNlcm5hbWU6
-> c2VuZGVyQGdtYWlsLmNvbQ==
<- 334 UGFzc3dvcmQ6
-> ********
<- 534-5.7.9 Application-specific password required. Learn more at
<- 534 5.7.9 https://support.google.com/mail/?p=InvalidSecondFactorThe account password was presented and is almost certainly correct - the account's own
two-step-verification policy is what rejected it, not a wrong credential.
How the big three word it
| Provider | Typical reply | Notes |
|---|---|---|
| Gmail / Google Workspace | 534-5.7.9 Application-specific password required or 534-5.7.14 Please log in via your web browser | The two most common real-world 534s; both are Google-specific. |
| Microsoft 365 / Exchange Online | Rarely uses 534; the closest equivalent is 535 5.7.3 Authentication unsuccessful with modern-auth guidance in the text | Microsoft's app-password and MFA flows surface through 535, not 534 - see the dedicated 535 5.7.3 piece. |
| Yahoo Mail | 534 5.7.9 Account has 2-step verification enabled | Same underlying cause as Gmail's 5.7.9, worded slightly differently. |
Diagnose it
$ swaks --to test@mailpilots.in --server smtp.gmail.com:587 \
--auth LOGIN --auth-user sender@gmail.com -tls 2>&1 | grep -A1 "^<- 534"
<- 534-5.7.9 Application-specific password required. Learn more at
<- 534 5.7.9 https://support.google.com/mail/?p=InvalidSecondFactorThe enhanced code and the URL in the text are the actual diagnosis - 5.7.9 always means an app
password is needed, while 5.7.14 always means a browser-based challenge is pending.
The fix, in order
- Read past the `534` to the enhanced code.
5.7.9and5.7.14need completely different
actions.
- For `5.7.9`: generate an app-specific password in the account's security settings and
substitute it for the account password in your SMTP configuration. The account password will
never work for SMTP once two-step verification is on.
- For `5.7.14`: sign in interactively through a browser once, completing any challenge
presented, which typically clears SMTP access for a period afterward.
- Confirm two-step verification status before troubleshooting further - if it is off and
you are still seeing 5.7.9, the account state and your assumption disagree, and the account
settings page is the source of truth, not your configuration file.
- Move to OAuth for Gmail and Outlook where your platform supports it, removing password and
app-password management from this flow permanently.
What not to do
- Do not retype the account password repeatedly. If
5.7.9is the code, the password is not
the variable that needs to change.
- Do not disable two-step verification to work around `5.7.9`. That removes a real security
control to fix what is actually a five-minute app-password generation step.
- Do not assume `534` always means the same thing across providers. The number alone is
insufficient; the enhanced code is the actual signal.
- Do not confuse this with `535`.
534variants are about the *kind* of credential or
sign-in step required; 535 (covered separately for 5.7.8, 5.7.3, and 5.7.9 detail) is
about a credential being outright rejected.
MailPilot connects Gmail and Outlook over OAuth specifically to avoid this entire category -
there is no account password or app password to generate, rotate, or have rejected by a two-step
verification policy.
Ready to reach the inbox every time?
Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.
Start free trial