SMTP 534 5.7.9: an app-specific password is required

534 5.7.9 is a permanent failure meaning the mailbox provider requires an application-specific password for this login, and the one you supplied is not one. This appears specifically on accounts with two-factor (or multi-factor) authentication enabled, where providers no longer accept the regular account password for SMTP, IMAP, or POP access - "less secure app access" style logins have been deprecated industry-wide, and an app-specific password, generated separately in account security settings, is now required instead. Accounts without 2FA enabled generally do not hit this error at all, which is itself a useful diagnostic: if a previously working integration suddenly starts failing this way, check whether 2FA was recently turned on for that mailbox.

Who is at fault

This is a sending-side credentials fault - specifically, using the wrong kind of password for an account that has 2FA enabled. It is not a server bug or a reputation issue.

The exchange

220 smtp.gmail.com ESMTP ready
EHLO mail.yourdomain.com
250-smtp.gmail.com
250 AUTH LOGIN PLAIN
AUTH LOGIN
334 VXNlcm5hbWU6
c2VuZGVyQGdtYWlsLmNvbQ==
334 UGFzc3dvcmQ6
cmVndWxhcnBhc3N3b3Jk
534 5.7.9 Application-specific password required

How Gmail, Microsoft 365 and Yahoo word the same condition

Gmail and Yahoo both use essentially identical wording for this specific condition, since both deprecated regular-password SMTP access for 2FA-enabled accounts around the same period; Microsoft 365 tends to fold this into a more generic authentication failure rather than a distinct code.

Diagnostic commands

$ swaks --to recipient@example.com --from sender@gmail.com \
  --server smtp.gmail.com -p 587 -tls --auth LOGIN \
  --auth-user sender@gmail.com --auth-password 'regular-account-password'
<~  534 5.7.9 Application-specific password required

$ swaks --to recipient@example.com --from sender@gmail.com \
  --server smtp.gmail.com -p 587 -tls --auth LOGIN \
  --auth-user sender@gmail.com --auth-password 'abcd efgh ijkl mnop'
<~  235 2.7.0 Authentication successful

The second attempt, using a 16-character app-specific password generated from the account's security settings, succeeds where the regular password failed.

The ordered fix

1. Confirm 2FA is enabled on the mailbox account - this error only appears when it is.
2. Generate an app-specific password from the provider's account security settings (Google Account security, Yahoo Account security, etc.), scoped to "Mail" or "Other" app type.
3. Replace the regular password in your SMTP client configuration with this generated app-specific password.
4. Re-test with `swaks` using the new credential before resuming normal sending.
5. Store the app-specific password securely - treat it with the same care as the account password, since it grants full SMTP/IMAP access.

What not to do

• Do not disable two-factor authentication to work around this. That removes meaningful account security for the sake of a login convenience; generating an app-specific password solves the problem without that trade-off.
• Do not retry with the same regular password repeatedly. It will never succeed once 2FA is enabled and an app-specific password is required; the regular password is categorically blocked for this purpose.
• Do not share one app-specific password across many unrelated integrations. Generate separate ones per application so you can revoke access individually if one integration is compromised or retired.
• Do not assume this is a server-side bug. It is the provider correctly enforcing a security policy the account owner's settings require.

Auditing every integration sharing the same mailbox credentials

Once you generate an app-specific password for one integration, check whether any other script,

cron job, or third-party tool is still configured with the old regular password against the same

mailbox - those will keep failing with the identical 534 5.7.9 until each one is individually

updated. It is easy to fix the integration you noticed first and assume the problem is solved,

only to have a second, forgotten script trigger the same failure days later against the same

account.

What changed industry-wide, and why it will not be reversed

The shift away from accepting a regular account password for SMTP/IMAP access was driven by the

same password being reusable for a full account takeover if leaked anywhere - an app-specific

password limits the blast radius of a leak to mail access alone, and OAuth tokens go further by

being revocable individually and scoped to specific permissions. Expect this trend to continue

rather than reverse: providers are steadily reducing, not expanding, the situations in which a

plain password is accepted for programmatic mail access, so any integration still relying on one

is worth migrating proactively rather than waiting for it to break.

MailPilot's OAuth-based connections to Gmail and Outlook avoid this category of error entirely by using the provider's proper token-based authentication flow rather than a stored password, which is the direction all major providers are moving their account security model toward anyway.