Gmail SMTP "535-5.7.8 Username and Password not accepted" (and 534-5.7.9)

What it means

Your application, website, printer or mail server tried to log in to Gmail's SMTP server (smtp.gmail.com) and Google refused the login. No email was sent. The two most common answers are:

535-5.7.8 Username and Password not accepted. For more information, go to
535 5.7.8  https://support.google.com/mail/?p=BadCredentials

534-5.7.9 Application-specific password required. For more information, go to
534 5.7.9  https://support.google.com/mail/?p=InvalidSecondFactor

535-5.7.8 means the user name and password pair was rejected. 534-5.7.9 is more specific: the account uses 2-Step Verification, so Google will not accept the normal account password over SMTP and wants an app password instead. A third variant, 534-5.7.14 "Please log in through your web browser", means Google blocked the sign-in as suspicious until you sign in from a browser.

Why it happens

Google no longer accepts a normal account password for SMTP, IMAP or POP from third-party apps (so-called "less secure apps"). This was turned off for personal Gmail accounts in 2022, and for all Google Workspace accounts on March 14, 2025. Only two methods still work:

• OAuth 2.0 (sign in with Google, then the app uses a token). This is what Google recommends.
• App passwords: a 16-character password generated for one app. They only exist on accounts with 2-Step Verification turned on.

So the usual causes are:

• You typed your normal Gmail password in the app (534-5.7.9 if 2-Step Verification is on, 535-5.7.8 otherwise).
• The app password was revoked. Changing your Google account password revokes all app passwords.
• The user name is wrong: it must be the full address, for example you@gmail.com or you@yourdomain.com.
• Spaces or a typo when pasting the app password, or an old password still cached by the app.
• App passwords are not available for the account: no 2-Step Verification, Advanced Protection turned on, or a Google Workspace admin policy that does not allow them.

How to check

1. Sign in at myaccount.google.com, open Security, and check whether 2-Step Verification is on and whether app passwords are offered.
2. Test the login from a terminal with swaks (replace the values, use the app password):

   swaks --server smtp.gmail.com:587 --tls \
     --auth LOGIN --auth-user you@gmail.com --auth-password 'abcdabcdabcdabcd' \
     --from you@gmail.com --to you@gmail.com

   A 235 2.7.0 Accepted answer means the credentials work and the problem is in your app's settings.
3. Once sending works, send a test to the unique address on the Delivmail home page and check SPF, DKIM and DMARC for your From address.

How to fix it

Option 1: use OAuth 2.0 (best)

If your software offers "Sign in with Google" or an OAuth option for Gmail (most mail clients, many WordPress SMTP plugins, nodemailer, PHPMailer), use it. You create OAuth credentials in a Google Cloud project, then the app sends with a token. No password is stored, and it keeps working after a password change.

Option 2: use an app password

1. Turn on 2-Step Verification on the Google account.
2. Create an app password in your Google account settings (search "App passwords" in the account's search bar). Give it a name such as "Website".
3. Paste the 16 characters into your app, without spaces, as the SMTP password. Keep the full address as the user name.

Example with nodemailer:

const transporter = nodemailer.createTransport({
  host: 'smtp.gmail.com',
  port: 465,
  secure: true,          // or port 587 with secure: false (STARTTLS)
  auth: { user: 'you@gmail.com', pass: process.env.GMAIL_APP_PASSWORD }
});

For PHP sites, the same values go into PHPMailer; other login errors there are covered in PHPMailer "SMTP Error: Could not authenticate". Printers and scanners are covered in scan-to-email with Office 365 or Gmail.

Google Workspace: consider the SMTP relay

For a device or server that cannot do OAuth and must not hold a user's password, a Workspace admin can use the SMTP relay service (smtp-relay.gmail.com) with IP-based authentication instead. Its own errors are covered in Google Workspace SMTP relay "550 5.7.0 Mail relay denied".

534-5.7.14

Sign in to the account in a browser from the same network if possible, confirm any security alert ("Yes, it was me"), then retry. If it keeps happening, switch to OAuth or an app password.

Remember that Gmail accounts have daily sending limits; bulk mail through smtp.gmail.com ends in "550 5.4.5 Daily user sending limit exceeded".

Check that it is fixed

Send a message from the app to the unique address on the Delivmail home page. If it arrives, login works. Read the report: when you send through Gmail with your own domain, DKIM should be signed by your domain (set up in the Workspace admin console), and SPF and DMARC should pass. Then retry the original send.