SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Email New Added 26 October 2026

SMTP: 534-5.7.9 Application-specific password required

Gmail accepted the connection but will not take the account's normal password over SMTP, because the account has 2-Step Verification turned on. Since Google ended less secure app access in 2024, a plain password does not work for SMTP, IMAP or POP at all (without 2-Step Verification you get 535-5.7.8 instead). You need either an app password, which Google only offers once 2-Step Verification is on, or OAuth 2. Accounts in Advanced Protection cannot use app passwords at all.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# See exactly what the server says to your credentials
swaks --to [email protected] --server smtp.gmail.com:587 --tls \
  --auth LOGIN --auth-user [email protected] --auth-password 'app-password-here'

# 1. Turn on 2-Step Verification, then create an app password at
#    https://myaccount.google.com/apppasswords
# 2. Use the 16 character app password (no spaces) in place of the real one
#    host smtp.gmail.com, port 587 (STARTTLS) or 465 (TLS), full address as user

# Postfix relaying through Gmail: store it and rebuild the map
echo "[smtp.gmail.com]:587 [email protected]:abcdefghijklmnop" | sudo tee /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo systemctl reload postfix

# For an application you control, OAuth 2 (XOAUTH2) beats a stored password

How to diagnose Email errors

SMTP errors follow a strict convention: a 4xx code is temporary and will be retried, a 5xx is permanent and will not. Beyond delivery mechanics, most modern email problems are authentication problems (SPF, DKIM and DMARC alignment) which cause silent filtering into spam rather than an explicit bounce, and therefore need to be checked proactively.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Read the full bounce message. The enhanced status code (for example 5.7.1) is far more specific than the three-digit code and usually names the exact policy that rejected the message.
  2. Test the SMTP conversation manually with swaks --to [email protected] --server smtp.example.com --tls. It shows each command and response.
  3. Verify SPF, DKIM and DMARC records with dig TXT example.com, dig TXT selector._domainkey.example.com and dig TXT _dmarc.example.com.
  4. Check DMARC alignment, not just presence: the domain in the From: header must align with the SPF or DKIM domain, or DMARC fails even when both pass individually.
  5. Confirm the sending IP is not on a blocklist and has valid reverse DNS. Missing PTR records cause rejection by many large providers.

Tools worth reaching for

  • swaks
  • dig TXT
  • openssl s_client -starttls smtp
  • postfix mail logs
  • DMARC aggregate reports

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

support.google.com support.google.com

Related Email errors

See all 20 Email errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.