WordPress and Gmail SMTP: app passwords, OAuth and sending limits

Email & newsletters · By the Plain Hooks editorial team · Published 2026-09-15

White envelopes tied with a grey ribbon, a pencil and a eucalyptus sprig on a white table — Envelopes tied with a ribbon, ready to send.

Using a Google account to send your site's email used to mean typing your Gmail password into a plugin. That no longer works, and for good reasons. Here is what does.

This address once carried an announcement for a Gmail-compatible version of a ShiftThis SMTP plugin from 2006. That software is discontinued and not available here. The settings below reflect Google's current rules.

The connection settings

Google's outgoing server for Gmail and Google Workspace accounts is smtp.gmail.com, with authentication required:

Setting	Value
Server	`smtp.gmail.com`
Port and encryption	587 with STARTTLS (TLS), or 465 with SSL
Username	The full Google account address
Password	An app password, or OAuth instead of a password (see below)

Google documents these values in its help article on sending email from a printer, scanner or app, which also describes the alternatives for Workspace.

Why your normal password fails

Google has phased out "less secure app" access, meaning sign-in to SMTP, IMAP or POP with just a username and the account password. For personal Gmail accounts this ended in 2022; for Google Workspace, Google announced a staged shutdown that it has been completing since 2024. A plugin configured with your regular password will get an authentication error. You have two supported choices.

App passwords

An app password is a 16-character password that Google generates for one application. It requires 2-Step Verification on the account, and Workspace administrators can disable it. Create one from your Google Account's security settings (Google's app passwords help page explains how), paste it into your SMTP plugin's password field, and keep it out of version control. If you change the account password, Google revokes existing app passwords and you must create a new one.

OAuth

With OAuth, the plugin never sees a password. You create a project in Google Cloud Console, enable the Gmail API, configure an OAuth consent screen, and give the plugin a client ID and secret; then you authorise the connection once from the WordPress dashboard. Plugins such as WP Mail SMTP, FluentSMTP and Post SMTP document this flow step by step. It takes longer to set up, but it survives password changes and is what Google recommends. On a personal account, an OAuth app left in "testing" mode issues tokens that expire after a few days, so follow your plugin's instructions on publishing the app.

Sending limits

Gmail is a mailbox, not a bulk sending service. Google publishes daily sending limits for personal Gmail accounts and for Workspace accounts; when you exceed them, the account is temporarily blocked from sending, which also blocks your own email. For password resets and form notifications this is rarely an issue. For a newsletter or a busy shop, use a transactional service instead (see Sending WordPress email through SMTP).

Google Workspace: the SMTP relay

Workspace administrators have a third option: the SMTP relay service at smtp-relay.gmail.com. It can authenticate by the sending server's IP address instead of by account, which suits a server with a fixed IP. It is configured in the Admin console under Gmail routing settings, has its own limits, and Google describes it in the same help article linked above. On shared hosting where the outgoing IP is not yours alone, IP-based authorisation is not appropriate; use account authentication.

The From address must match

Gmail rewrites the sender to the authenticated account unless the address is one the account is allowed to send as. If you authenticate as you@gmail.com but WordPress sends "from" site@example.com, either add that address in Gmail settings under Send mail as, or set WordPress's sender to the account itself. For a site on its own domain, a Workspace account on that domain is the cleaner solution: messages then pass SPF and DKIM for your domain, provided you have enabled DKIM signing in the Admin console and added Google to your SPF record (include:_spf.google.com).

Troubleshooting checklist

"Username and Password not accepted": you are using the account password, or the app password was revoked. Generate a new app password or switch to OAuth.
Connection timed out: your host blocks outgoing ports 587 and 465. Ask the host, or use an OAuth/API connection, which runs over HTTPS.
Works, then stops after a few days: an OAuth app in testing mode with expiring tokens, or a daily limit reached.
Mail arrives but in spam: check the From address alignment and DMARC results with Gmail's Show original.

Should you use Gmail at all?

For a small site whose owner already pays for Google Workspace on the site's domain, it is a reasonable, low-cost choice. For a personal @gmail.com account sending on behalf of a business domain, it is a workaround: the From address cannot be your domain without extra configuration, limits are tight, and a problem with the site can lock you out of your own mailbox. A transactional email service on your own domain is usually the better long-term answer.

Why Google and other providers now insist on authenticated mail is explained in a short history of email authentication.