A Google Less Secure App (LSA) access was Google's name for the third-party authentication path that used a plain account password against Gmail's SMTP, IMAP, and POP endpoints. Google shut it down for consumer accounts on 30 May 2022 and for Workspace accounts on 1 May 2025; OAuth, App Passwords, or a different sending provider replace it. Read full reference → is a 16-character credential generated in Google Account settings that authenticates a single application against Gmail’s SMTP server without requiring the account password or an OAuth flow. WordPress SMTP plugins reach for one when the plugin lacks Gmail OAuth support, or when the install runs in an environment where the OAuth consent redirect cannot complete (headless deployments, CLI-only servers). A third common trigger: a previously working Gmail SMTP configuration that breaks the day after the account password is rotated. The two error strings that almost always indicate “you should be using an App Password and aren’t” are 534-5.7.9 Application-specific password required and 535-5.7.8 Username and Password not accepted.
For the comparison of App Passwords against OAuth as authentication strategies, see Gmail OAuth vs. App Passwords. For the wider context of using Gmail or Google Workspace as a WordPress SMTP relay alongside the dedicated transactional providers, see How to set up email on WordPress. This piece covers execution: getting the password generated, getting it into a WordPress SMTP plugin, and decoding what fails.
Prerequisites and when the option is hidden
App Passwords are only available on Google Accounts with 
2-Step Verification enabled. The link to “App Passwords” does not appear in the Google Account security UI until 2SV is on.
Enabling 2-Step Verification:
- Sign in at
https://accounts.google.com/signin. - Open Security in the left sidebar.
- Under “How you sign in to Google,” select 2-Step Verification and follow the prompts. Google requires a phone number for the first second-factor; an authenticator app or hardware key can be added afterwards.
Once 2SV is enabled, App Passwords are available to most accounts. There are four exceptions; each hides the option rather than emitting a useful error:
- 2-Step Verification is off. The default state for accounts that have never enabled 2SV. The App Passwords entry is hidden until 2SV is enabled.
- The account’s 2-Step Verification is set up only for security keys. Per Google’s documentation, App Passwords are unavailable when “Your Google Account has 2-Step Verification set up only for security keys” (reference). Adding a non-security-key 2SV method, such as an authenticator-app code or a backup code, makes the option return.
- The account is enrolled in the Advanced Protection Program. Per Google’s documentation: “Apps that use app passwords instead of 2-Step Verification are blocked for users with Advanced Protection. When you enroll in Advanced Protection, any current app passwords are revoked” (reference). The remedy is OAuth, not a configuration toggle.
- The Workspace organisation enforces security keys for 2-Step Verification. Workspace admins set 2SV enforcement methods at Admin Console → Security → Authentication → 2-Step Verification. When the enforced method is security keys only, App Passwords are unavailable to every user in the organisation as a consequence: “You can’t require users to use a security key for 2SV and also let them use app passwords to sign in to legacy apps” (
reference). There is no separate App Passwords toggle in the Admin Console; the Less Secure Apps enforcement setting that previously lived there was retired in 2025.
If 2SV is on and the App Passwords link is still absent, walk this list before troubleshooting further.
Generating an App Password
The App Passwords screen is not in the Google Account left navigation. Two ways to reach it:
- From
https://myaccount.google.com, use the page’s Search field at the top, type App Passwords, and select the suggested result. - Go directly to https://myaccount.google.com/apppasswords.
Then:
- In the App name field, enter a descriptive label such as
WordPress SMTP (example.com). The label is for the human reading the list later; it does not affect authentication. - Click Create. A 16-character password appears, grouped as four sets of four characters with spaces between them.
- Copy the password immediately. The dialog displays it once. After closing, the password cannot be retrieved; a lost App Password must be revoked and regenerated.
An account can hold multiple App Passwords at once, each with its own label. Generating a second App Password for a different WordPress site does not invalidate the first; both remain active until manually revoked or until the account password is rotated.
The spaces in the displayed password are for legibility. SMTP authentication accepts the password with or without spaces, and most plugins strip whitespace automatically. A stray leading or trailing space in the password field is a common cause of a 535-5.7.8 immediately after pasting.
Using the App Password in WordPress
The App Password replaces the Gmail account password in the SMTP plugin’s password field. All other SMTP settings are unchanged from a standard Gmail SMTP configuration:
| Setting | Value |
|---|---|
| SMTP host | smtp.gmail.com |
| Port | 465 (SSL/TLS) or 587 (STARTTLS) |
| Username | Full Gmail address |
| Password | The 16-character App Password |
The username is the full email address, including the domain. For a consumer Gmail account, this is [email protected]; for a Workspace account, it is [email protected]. Plugins that accept only the local part of the address will fail authentication with 535-5.7.8.
WP Mail SMTP, FluentSMTP, and Post SMTP all accept this configuration under their “Other SMTP” (or equivalently named) mailer rather than under a “Gmail” mailer. The dedicated “Gmail” or “Google Workspace” mailer options in those plugins are OAuth integrations and do not accept an App Password as input.
The same App Password also authenticates IMAP and POP for the account, not just SMTP. WordPress sites that poll a Gmail mailbox inbound (some contact-form, membership, and ticketing plugins do) can use the same credential for the inbound connection.
After saving the configuration, the plugin’s test-email function is the fastest way to confirm the credential works. A successful test produces an authenticated SMTP session against smtp.gmail.com; a failed test typically produces one of the errors below.
What goes wrong, and what the error string means
534-5.7.9 Application-specific password required
The SMTP plugin is presenting the Gmail account password (or no password at all) and Gmail is rejecting it because the account has 2SV enabled. Gmail does not accept account passwords from third-party clients once 2SV is on, except via OAuth or an App Password. Replace the password field in the plugin with the 16-character App Password.
535-5.7.8 Username and Password not accepted
The plugin is presenting credentials Gmail recognises as malformed or invalid. With an App Password in the field, this almost always means one of:
- The App Password was mistyped or truncated during copy-paste. Regenerate and re-paste, paying attention to leading or trailing whitespace.
- The Gmail account password has been changed since the App Password was generated. Google revokes every App Password on an account when the account password changes: “To help protect your account, we revoke your app passwords when you change your Google Account password” (reference). This is the silent-failure pattern: SMTP that worked for months stops on the day of a routine password rotation, the plugin log records
535-5.7.8, and nothing in Google’s account UI announces the connection. Generate a new App Password and update the plugin. - The username in the plugin is not the full email address. Gmail SMTP requires the full address, including the domain, not the local part alone.
The App Passwords screen returns “The setting you are looking for is not available for your account”
The account is in one of the four states listed under prerequisites. Re-check that list before pursuing other causes; in particular, a Workspace account where the org enforces security keys for 2SV will surface this message rather than a more diagnostic error.
Revoking an App Password
App Passwords end in two ways:
- Manual revocation. Return to https://myaccount.google.com/apppasswords, locate the password by its label, and click the trash icon next to it. Revocation is immediate; any SMTP session using that password will fail authentication on its next connection.
- Automatic revocation. Changing the Gmail account password revokes every App Password on the account in a single action. This is the security-by-default behaviour; it is also the most common cause of WordPress SMTP breakage following an apparently unrelated security event such as a forced password reset.
Revoking an App Password does not affect OAuth tokens for the same account. The two authentication paths are independent.
Workspace notes
The daily sending limit on a Workspace mailbox is 2,000 messages per 24 hours, measured as a rolling window (reference). For a free Gmail account the limit is 500 per 24 hours (reference).
Workspace operators whose Gmail SMTP setups stopped authenticating in late 2024 are typically hitting a different deadline than the consumer 2022 one. Google ended Less Secure App access for Workspace on 30 September 2024 (
Workspace blog); the consumer-Gmail equivalent ended on 30 May 2022. Setups that survived the consumer cutoff because they were on Workspace, and that relied on LSA rather than App Passwords or OAuth, broke on the 2024 date. The fix is the same: generate an App Password (or configure OAuth) and update the plugin.
When App Passwords are the wrong answer
Two cases:
- The plugin supports OAuth. OAuth tokens survive account password rotations; App Passwords do not. For a WordPress site that needs to send reliably for months or years, OAuth removes the failure mode where a routine security event silently kills email delivery. See Gmail OAuth vs. App Passwords for the tradeoff, and How to get OAuth 2.0 credentials on Google for the setup walkthrough.
- The site sends more mail than Gmail’s daily limit. A WooCommerce store processing more than a few hundred orders per day, or a contact-form-heavy site on a busy week, will hit the 500-per-day or 2,000-per-day cap, at which point Gmail returns transient send failures regardless of authentication method. For higher volumes, the right path is a dedicated transactional relay; the Gmail dossier covers where that line sits.