Gmail no longer accepts plain passwords from third-party apps. Google removed Less Secure App Access for consumer accounts on 30 May 2022 and for Workspace accounts on 30 September 2024. Two authentication methods remain: OAuth 2.0 and App Passwords. Both work. They differ in setup complexity, durability, and what breaks when.
This piece is the decision between the two. For the broader WordPress email setup context that Gmail relay sits inside (including when a dedicated transactional provider is the better answer than the Gmail SMTP path), see How to set up email on WordPress.
OAuth 2.0
OAuth grants access through tokens instead of passwords. The app redirects to Google’s consent screen, the user approves, and Google issues an access token and a refresh token. The app uses the access token to authenticate SMTP sessions; when it expires (typically after one hour), the refresh token fetches a new one automatically. The app never sees the user’s Gmail password.
Setup requires creating a project in the Google Cloud Console, enabling the Gmail API, configuring an OAuth consent screen, and generating OAuth client credentials (client ID and secret). For a step-by-step walkthrough, see How to get OAuth 2.0 credentials on Google.
The process takes 10-15 minutes for someone familiar with the Google Cloud Console, longer for a first attempt. Google’s consent screen verification process adds friction for apps used by external users, though WordPress SMTP plugins authenticating a site owner’s own account (internal use) do not need verification.
What makes OAuth durable: tokens survive password changes. Changing the Gmail account password does not revoke OAuth tokens – only explicitly revoking access in the Google Account security settings or deleting the Cloud Console project does. For a WordPress site, this means SMTP authentication keeps working through routine password rotations.
What can break: if the Google Cloud Console project is deleted, if a Workspace admin restricts the OAuth client’s API scope, or – the non-obvious one – if the OAuth consent screen is set to “Testing” mode. Testing-mode tokens expire after 7 days. A WordPress site configured against a testing-mode OAuth app will lose authentication weekly until the consent screen is published. The SMTP error gives no indication that consent screen status is the cause.
App Passwords
App Passwords are 16-character codes generated in the Google Account security settings. They replace the Gmail password for a single app or device. Generating one requires 
2-Step Verification enabled on the account.
Setup takes under two minutes: go to 
myaccount.google.com/apppasswords, name the app, copy the generated code, paste it as the SMTP password. No API project, no consent screen, no client credentials.
What makes App Passwords fragile: they are revoked when the account password changes. Every password rotation – whether voluntary, forced by a security policy, or triggered by a compromise response – kills every App Password on the account. A WordPress site using an App Password for SMTP will silently stop sending email until the App Password is regenerated and updated in the plugin settings.
App Passwords are also tied to the account that generated them. If a team member leaves and their Google account is suspended or deleted, any WordPress site using that account’s App Password loses SMTP access immediately. For shared WordPress sites, this creates an operational dependency on a specific person’s account.
Workspace administrators can disable App Passwords org-wide via the Admin Console (Security > Authentication > App Passwords). If the setting is off, users in that organisation cannot generate App Passwords regardless of their 2-Step Verification status.
For WordPress sites
The recommendation is simple: use OAuth if your SMTP plugin supports it. WP Mail SMTP, FluentSMTP, and Post SMTP all include native Gmail OAuth integrations. Configure once, and the token refreshes indefinitely with no manual intervention.
Use App Passwords when OAuth is impractical:
- Headless or CLI-only servers where the browser-based OAuth consent redirect cannot complete
- Hosting environments that block outbound HTTPS to Google’s token endpoint (rare, but some locked-down hosts restrict egress)
- Quick testing where the site is temporary and durability does not matter
For a site that needs to send email reliably for months or years, OAuth eliminates the class of failure where a password change silently breaks email delivery. That elimination is worth the extra 10 minutes of setup.
SMTP settings (both methods)
Both OAuth and App Passwords connect to the same Gmail SMTP server:
| Setting | Value |
|---|---|
| Host | smtp.gmail.com |
| Port | 587 (STARTTLS) or 465 (SSL/TLS) |
| Encryption | TLS |
| Username | Full Gmail address ([email protected] or [email protected] for Workspace) |
| Password | App Password (16-char code) or OAuth token (handled by plugin) |
Gmail’s sending limits apply regardless of authentication method: 500 emails per day for consumer accounts, 2,000 per day for Workspace accounts. A WooCommerce store processing more than a few hundred orders per day will hit these limits. For higher volumes, use a dedicated A transactional email is the automated message a WordPress site sends in response to a single user action – a password reset, an order confirmation, a form receipt – addressed to the user who triggered it. Read full reference → relay like SMTP2GO or Amazon SES instead of Gmail.
LSA sunset dates verified against 
Google Workspace blog and Google support. Gmail SMTP settings verified against Google support documentation.