← Blog/Authentication

SMTP error 534: encryption, app passwords, and browser sign-in

October 15, 2026·5 min read·By MailPilot

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=InvalidSecondFactor

The 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

ProviderTypical replyNotes
Gmail / Google Workspace534-5.7.9 Application-specific password required or 534-5.7.14 Please log in via your web browserThe two most common real-world 534s; both are Google-specific.
Microsoft 365 / Exchange OnlineRarely uses 534; the closest equivalent is 535 5.7.3 Authentication unsuccessful with modern-auth guidance in the textMicrosoft's app-password and MFA flows surface through 535, not 534 - see the dedicated 535 5.7.3 piece.
Yahoo Mail534 5.7.9 Account has 2-step verification enabledSame 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=InvalidSecondFactor

The 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

  1. Read past the `534` to the enhanced code. 5.7.9 and 5.7.14 need completely different

actions.

  1. 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.

  1. For `5.7.14`: sign in interactively through a browser once, completing any challenge

presented, which typically clears SMTP access for a period afterward.

  1. 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.

  1. 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.9 is 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`. 534 variants 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.

MailPilot

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
Reach the Inbox, Every Time
Connect unlimited inboxes for warmup. Free 7-day trial, no credit card.
Try for Free
WORKS WITH
OZOHO
inbox placement99.2%
free trial7-day
companies trust us340+

Start for free - no credit card required.

Get started freeBook a demo