SMTP error 535 5.7.9: application-specific password required

SMTP error 535 5.7.9 means the account has two-step verification (two-factor authentication)

enabled, and the password presented during AUTH - the account's normal sign-in password - is

being rejected because SMTP requires a separate, application-specific credential once two-step

verification is on. This is a close relative of 534 5.7.9 (covered separately): the same

underlying cause, surfaced through a different base reply code depending on exactly when in the

AUTH exchange the server decides to reject.

Fault: sender configuration, specifically using the wrong credential type for an account that

has two-step verification enabled. The account password itself may be entirely correct and still

never work here.

Why it happens

• Two-step verification was turned on after the SMTP configuration was originally set up.

The stored credential - the account password - worked at the time and silently stopped working

the moment 2FA was enabled, with no warning at the point of the change.

• An app password was generated once and later revoked, either manually or automatically when

the account password changed, since most providers invalidate all app passwords on an account

password reset.

• **A shared or inherited configuration (a CMS plugin, a legacy script) still stores the account

password** rather than an app password, and nobody updated it when 2FA was enabled on the

underlying account.

• Confusion between "password" fields in a client's settings - some tools have separate

fields for account login and SMTP credentials, and the account password gets pasted into the

wrong one.

• An app password generated for one purpose being reused for a different integration, which

works until the first integration's password is revoked or regenerated, at which point every

other integration quietly sharing it breaks at the same time with no obvious common cause.

• A password manager auto-filling the account password into an app-specific-password field

because the two look identical to an autofill heuristic, silently substituting the wrong

credential type without any error until the next send attempt.

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
-> ********
<- 535-5.7.9 Application-specific password required. For more information, go to
<- 535 5.7.9  https://support.google.com/mail/?p=InvalidSecondFactor

How the big three word it

Diagnose it

$ swaks --to test@mailpilots.in --server smtp.gmail.com:587 \
        --auth LOGIN --auth-user sender@gmail.com -tls 2>&1 | grep "535\|534"
<- 535-5.7.9 Application-specific password required

A 5.7.9 anywhere in the reply - whether the base code is 534 or 535 - is the same

diagnosis: generate an app password, do not keep troubleshooting the account password.

The fix, in order

1. Confirm two-step verification is enabled on the account in its security settings.
2. Generate a new app-specific password dedicated to this one SMTP use case.
3. Replace the stored account password with the new app password in every configuration that

uses this credential, not just the one that just failed - a credential shared across several

tools needs updating everywhere at once.

1. Test immediately after generating the app password, since app passwords are typically

valid immediately with no propagation delay.

1. Migrate to OAuth for Gmail or Outlook where your platform supports it, which removes the

entire category of password/app-password management going forward.

What not to do

• Do not re-enter the account password expecting a different result. 5.7.9 specifically

means that credential type will never work here, regardless of whether it is typed correctly.

• Do not disable two-step verification to make the error go away. This removes real account

security to avoid a five-minute app-password generation step.

• Do not reuse one app password across many unrelated integrations. If you ever need to

revoke access for one integration, a shared app password forces revoking all of them at once.

• Do not store the app password in plaintext in version control or shared documents - treat

it with the same care as any other credential, since it grants full SMTP send access to the

account.

MailPilot connects Gmail and Outlook mailboxes over OAuth, which bypasses this entire

app-password workflow - there is no password of any kind stored for those providers, and

two-step verification changes on the underlying account do not affect the connection.