WordPress Maintenance: SMTP Uses a Locked Google Account: How to Diagnose Missing Transactional Emails - Featured image
Illustration for WordPress Maintenance: SMTP Uses a Locked Google A

WordPress Maintenance: SMTP Uses a Locked Google Account: How to Diagnose Missing Transactional Emails

Read Google's SMTP rejection code first — it separates a suspended account from a revoked app password, a throttle, or a blocked port.

If your WordPress site stopped sending transactional email and its SMTP settings point at a Google account that has been locked, suspended, or password-reset, the mail is failing at authentication — before it ever reaches a recipient. WordPress usually reports nothing, because `wp_mail()` returns a quiet false and most plugins never surface that to an administrator. Diagnosing this is a matter of reading Google's SMTP rejection code, then confirming the account state on Google's side rather than guessing at WordPress. The repair is rarely "get the account unlocked" — it is moving the site off a human's mailbox and onto a sending identity the business controls.

Table of Contents

What "locked" actually covers, and why the site goes silent

WordPress sends every automated message — password resets, WooCommerce receipts, form notifications, user registrations — through one function, `wp_mail()`. An SMTP plugin such as WP Mail SMTP, FluentSMTP, Post SMTP, or Easy WP SMTP intercepts that function and hands the message to an external mail server over SMTP, the protocol mail servers use to relay messages. When the credentials for that server stop working, every one of those messages dies at the same point. "Locked" is a loose word covering several distinct Google states, and they produce different errors. A Google Workspace user can be suspended by an administrator, suspended automatically when a subscription payment fails, or have its licence removed. A personal Gmail account can be disabled for a terms violation or temporarily blocked after Google flags unusual sign-in activity.

Any of these leaves the mailbox reachable in theory and unusable for SMTP in practice. Two changes cause identical symptoms without the account being locked at all. Changing the account password invalidates existing app passwords, and turning off 2-Step Verification deletes them outright — an app password is the 16-character credential Google issues specifically so a program can sign in, and it exists only while 2-Step Verification is on. If the site authenticates by OAuth instead, a revoked token or a removed app authorisation fails the same way. The silence is the real problem. A failed `wp_mail()` call returns false, and unless the plugin logs it or an error notification is configured, nothing appears in wp-admin. Customers experience it as missing order confirmations and password resets that never arrive, which is why these outages are often discovered by support tickets rather than by monitoring.

Read the SMTP response code before changing anything

Google's rejection strings are specific, and each one points somewhere different. Get the raw SMTP conversation from your plugin's test-email tool or debug log, then match it: That last distinction matters because many hosts block outbound SMTP ports, and the resulting failure looks like "email is broken" too. If the transcript never gets far enough to show a `535`, stop investigating Google.

  • `535-5.7.8 Username and Password not accepted` — the credential is wrong or has been revoked. Most commonly a deleted app password, or a regular account password used where an app password is required.
  • `534-5.7.9 Application-specific password required` — 2-Step Verification is on and the site is sending the normal password.
  • `535 5.7.1 Please log in with your web browser` — Google wants human interaction on the account. This is the classic signature of a flagged, blocked, or suspended account.
  • `550 5.7.1` or an explicit *account disabled* message — the user is suspended or the licence is gone.
  • `550-5.4.5 Daily user sending limit exceeded` or `421 4.7.0 Try again later` — the credential works and Google is throttling volume. This is a capacity problem, not a lock.

An order of operations that isolates the account from WordPress

Work outward from the site, and prove each layer before moving on: Keep in mind what a successful test proves. A `250 OK` means Google accepted the message for delivery, not that it landed in an inbox. Spam filtering, bounces, and recipient-side rejection are separate problems that a working SMTP handshake does not rule out.

  • Confirm which mailer is actually running. More than one SMTP plugin can be active, and a `mu-plugins` file or a host-installed drop-in can override `wp_mail()` ahead of the plugin you are editing. Whichever loads last wins.
  • Turn on the plugin's email log and debug output, then send a test message. Post SMTP and WP Mail SMTP both store the server transcript, which is the artefact you need.
  • Test the credential outside WordPress. A command-line SMTP client such as `swaks`, or `openssl s_client -starttls smtp -connect smtp.gmail.com:587`, authenticates against Google directly. If it fails there, the site is innocent.
  • Check for a queue. Some plugins and caching layers defer mail to cron. If WP-Cron is not firing, messages sit unattempted and produce no SMTP error whatsoever.
  • Only then look at Google.

Checking the Google side

For a Google Workspace account, an administrator can see the answer directly in the Admin console. The Users list shows whether the account is active or suspended, and the login audit log shows failed sign-in attempts — your site's attempts will appear there with timestamps that match the outage. If the whole domain's service is affected rather than one user, check the subscription's billing state. Workspace also has organisation-level controls that can break SMTP while the user account is perfectly healthy. Administrators can restrict how accounts authenticate to mail clients, and Google has retired password-based sign-in for older "less secure app" connections across both Workspace and personal Gmail.

A configuration that worked for years can stop working because a policy changed, not because anyone touched the site. For a personal Gmail account, the security activity page under the account settings lists recent sign-in blocks and security events, and the app passwords page shows whether the credential your site uses still exists. If it is absent, it was revoked — generate a new one rather than trying to recover the old string. There is usually a non-technical finding here too. Ask whose account it is. Transactional mail configured against a former employee's mailbox, or a contractor's personal Gmail, breaks the moment that person's access is cleaned up, and the outage is then a symptom of correct offboarding rather than a fault.

What to rebuild the site's mail on

Restoring the same credential returns you to the same fragility. A better target is a dedicated transactional email provider — services such as Postmark, Amazon SES, Mailgun, Brevo, SendGrid, or Resend — which authenticate by API key against a domain you own and are built for automated mail. You add SPF and DKIM records for your domain, so messages align with the sender you actually advertise. Gmail SMTP has a structural limitation independent of any lock: it sends as the mailbox.

Your receipts go out from a person's address rather than something like `orders@yourdomain.com`, and replies land in that person's inbox. Google's per-account daily sending limits are documented in its help pages and change over time, so check the current figure rather than a number you remember — either way, they are consumer-mailbox limits, not transactional ones. If you must stay in the Google ecosystem, use a role-based Workspace account owned by the business, with 2-Step Verification enabled and a documented app password, or configure Workspace's SMTP relay service, which is designed for applications rather than mail clients. Either option survives a staff change; a personal account does not.

Make the next failure loud

Store the credential where you can rotate it without hunting through the database. WP Mail SMTP and several of its peers accept configuration as PHP constants in `wp-config.php`, which keeps the secret out of plugin settings tables and out of database exports. Then give yourself a signal.

Keep the plugin's email log enabled with failure alerts pointed at an address that does *not* depend on the mailer being tested, and schedule a recurring canary message to an external inbox. A monitoring service that checks for that message and alerts on its absence turns a silent multi-day outage into a same-hour notification. Finally, write down who owns the sending account and where its credential lives. On a site where password resets go through the same broken mailer, an undocumented dependency means the person who could fix it may also be the person locked out.

Frequently Asked Questions

I changed the Google account password and email stopped working. Is the account locked?

No. Changing the password invalidates existing app passwords and can revoke OAuth tokens. Generate a new app password and update the site's SMTP settings.

The plugin's test email succeeds, but customers still report missing receipts. What now?

Authentication is fine, so look past SMTP. Check that the specific plugin sending receipts uses `wp_mail()`, that WP-Cron is running, and whether messages are being filtered at the recipient end.

Can I keep sending from the same address after moving to a transactional provider?

Only if you control that domain. An `@gmail.com` From address cannot be authenticated with SPF and DKIM by a third-party provider, so switch to an address on your own domain.

Does unlocking the Google account fix everything immediately?

Not always. After a suspension or a security block, app passwords may be gone and Google may throttle the account temporarily. Recreate the credential and expect `421` deferrals for a short period.

You Might Also Like

Browse more: All | CMS | Development | Drupal | Maintenance

Related Posts