nanoPost

The WordPress Email Authority

WordPress SMTP with Google Workspace

Last reviewed/updated:

Use Google Workspace as the SMTP server for a WordPress site when the site sends a small, predictable volume of operational mail (password resets, contact-form notifications, order receipts) on behalf of a real Workspace mailbox. The fit is a site sending well under 2,000 messages a day, ideally under fifty, where every message goes out as a single Workspace identity ([email protected]) and where nobody needs delivery logs, bounce webhooks, or per-recipient suppression. Push past that profile and three Workspace behaviours catch operators out: From addresses get silently rewritten, App Passwords die on routine password rotations, and the day’s outbound caps on a rolling 24-hour window rather than at midnight. Mail keeps flowing until it doesn’t, and the diagnostic surface is thin.

If the site doesn’t fit, the catalog of dedicated providers is at SMTP services for WordPress and a four-name shortlist sits at the bottom of this page.

When this is the right approach

Workspace is a mailbox system being repurposed as a transactional sender, and the fit is narrow.

  • Volume well under the 2,000-messages-per-day per-mailbox cap, with headroom for a marketing send or a runaway notification loop.
  • A single Workspace identity that the site is acting on behalf of. Most plausibly, a real [email protected] or [email protected] mailbox the site owns.
  • No need for bounce webhooks, per-message delivery logs, or per-recipient suppression. Workspace’s admin-console reporting lags by hours and isn’t structured for per-message visibility.
  • No requirement to keep transactional and broadcast traffic on separate reputations. If the same site sends order receipts and a monthly newsletter, the newsletter will eventually pull the transactional reputation down with it.

When any of these flip, the right move is a dedicated transactional provider; the off-ramp section names the shortlist.

Choosing a mailer plugin

Three mailer plugins handle Google Workspace. WP Mail SMTP presents the OAuth flow under a “Google / Gmail” provider with the client ID, secret, and redirect URI on the same settings tab as the authorise button; the free tier covers Workspace. FluentSMTP groups the same flow under “Gmail / Google Workspace”; log retention works out of the box and there is no Pro tier. Post SMTP splits the credential entry across an OAuth tab and a Connection Test, with refresh-token state under Tools → Diagnostics. The plugin-by-plugin trade-offs live in best WordPress SMTP plugins.

Generating credentials

Workspace exposes two ways for a mailer plugin to authenticate against smtp.gmail.com. OAuth (OAuth 2.0, the token-based authorisation flow Workspace and most modern services use) takes longer to set up and then survives most operational events. An App Password (a sixteen-character credential Workspace issues to bypass interactive 2-Step Verification) takes five minutes and dies the next time the account password changes. The full decision essay is at Gmail OAuth vs App Passwords; OAuth is the right default unless the account password is genuinely static.

Option A: OAuth (recommended)

OAuth gives the mailer plugin a refresh token tied to the Workspace user’s consent. The token survives most operational events that kill an App Password (admin-forced password rotation among them, in practice), but it isn’t unconditional: Google invalidates refresh tokens when the user revokes the connection in their account settings, when the consent screen is unpublished, when the token sits unused for six months, and when other security signals fire. For a Workspace account dedicated to a WordPress site, the practical lifetime is years rather than indefinite.

The click-by-click for creating OAuth credentials, scoping them to Gmail send, and pasting the client ID and secret into the plugin lives in how to get OAuth credentials from Google. Three points are Workspace-specific:

  • The scope mailer plugins request is https://mail.google.com/. The narrower gmail.send scope is enough to send, but plugins ask for the broader scope so their connection test can verify by reading a label; granting it is appropriate for a Workspace account dedicated to the WordPress site.
  • The OAuth consent screen has a Testing-mode trap. Tokens issued under a Testing-mode consent screen expire after seven days, and sending stops the moment they do. Move the consent screen to “In production” (APIs & Services → OAuth consent screen) before pasting the credential into the plugin.
  • After authorising, run the plugin’s Connection Test before relying on the path for live mail. A successful test today means the refresh-token round-trip is sound, and the same test in three months will still work.

Option B: App Password (faster but fragile)

An App Password is a sixteen-character credential the mailer plugin uses in place of the account password. It bypasses the Workspace 2-Step Verification prompt that interactive logins go through, which is the only reason an SMTP submission can use it at all.

The prerequisite tree (2-Step Verification on the account, the four states where the App Passwords option is hidden in the UI, the recovery path when it doesn’t appear) is in Gmail App Passwords. Two things are specific to this guide:

  • The App Password is the SMTP password the plugin pastes into its settings; the username is the full Workspace email address.
  • Every routine password rotation on the Workspace account revokes every App Password the account holds. The plugin keeps the cached credential and sends start failing with 535-5.7.80 Username and Password not accepted from the next outbound, with no advance warning. Workspaces that force scheduled password rotation will see this happen exactly as often as the schedule fires.

Configuring the mailer plugin

The SMTP settings are identical regardless of which mailer plugin holds them. The same spec lives in the Gmail sending-service entry as a structured np-spec.

Setting Value
Host smtp.gmail.com
Port 587 (STARTTLS, recommended) or 465 (implicit TLS)
Encryption TLS required; Workspace rejects unencrypted submission
Authentication OAuth 2.0 (recommended) or App Password
Username Full Workspace email address ([email protected])
Password / token OAuth refresh token (handled by plugin) or 16-character App Password

All three plugins handle the OAuth flow inside their own settings screen and store the refresh token in the plugin’s options table; refresh after the first authorisation is transparent.

Port 465 and port 587 are both open. Port 587 with STARTTLS is the modern submission default; pick it unless the host environment specifically requires implicit TLS on 465.

DNS alignment

Workspace sends mail regardless of DNS state. Whether that mail aligns to the sending domain (and survives a moderately strict DMARC policy at the receiver) depends on three records at the domain’s DNS host. The general SPF / DKIM / DMARC mechanism is in DNS setup for WordPress email; the Workspace specifics are below.

SPF. Add include:_spf.google.com to the domain’s TXT SPF record (SPF is the DNS-published list of servers permitted to send mail for the domain). If the domain already has an SPF record for another sender (a transactional provider, an old host’s mail server), merge the includes into a single record; multiple SPF records on the same domain invalidate all of them. The record looks like v=spf1 include:_spf.google.com ~all for a Workspace-only setup.

DKIM. DKIM (the cryptographic signature receivers use to verify a message left the claimed sender) is the record Workspace alignment depends on. Generate the domain key in the Workspace Admin Console under Apps → Google Workspace → Gmail → Authenticate email; choose 2048-bit, accept the default google selector, and publish the resulting TXT record at google._domainkey.yourdomain.com at the DNS host. After the record is live, return to the Admin Console screen and click “Start authentication.” Until that final step, message headers show d=gmail.com in the DKIM signature rather than the custom domain (observed in test sends; Google’s setup docs describe the configuration but not the interim signing behaviour). The WordPress site keeps sending; the DKIM signature simply doesn’t align to the From address, and DMARC-checking receivers treat the mail accordingly.

DMARC. A starting DMARC policy of v=DMARC1; p=none; rua=mailto:[email protected] at _dmarc.yourdomain.com will deliver aggregate reports without quarantining mail. Tightening to p=quarantine or p=reject is appropriate after a few weeks of clean reports; the DNS setup guide covers the progression.

Workspace will rewrite the From address in one specific configuration: when the SMTP authenticated user is one mailbox and the From header names a different identity that the authenticated mailbox is not authorised to send as. The rewrite is observed behaviour, not Google-documented; Google’s send-as docs cover the authorisation requirement but not the silent rewrite. The fix is to authenticate as the mailbox that owns the From identity; the section below revisits this under silent-failure modes.

Verifying the setup

The lightest end-to-end test is the WordPress password-reset flow on a test account.

  1. From a logged-out browser, visit /wp-login.php and click “Lost your password?”.
  2. Enter the test account’s email address. WordPress sends a reset email via the configured SMTP path.
  3. Confirm the message arrives in the test account’s inbox within a minute or two, and check the headers for Received-SPF: pass, dkim=pass, and dmarc=pass (Gmail surfaces these under “Show original”).

A round-trip with all three checks passing is the strongest single signal that the SMTP path, the DNS, and the DKIM alignment are configured correctly together.

If the test fails, the SMTP error code points at the cause. 5.7.0 Authentication required means the plugin isn’t authenticating at all (missing or wrong credentials). 5.7.80 Username and Password not accepted means the credentials are present but Workspace rejected them (most often a revoked App Password, occasionally an OAuth refresh-token revocation). A From-identity mismatch without send-as authorisation usually surfaces as a silent rewrite rather than an SMTP rejection (see the silent-failures section below); the next-most-likely outright rejection is in the 5.7.x range. For deeper triage, see troubleshoot WordPress email and how to read an SMTP session log.

Limits, alignment, and silent failures

Four behaviours catch operators off guard, and all four are absent from the typical “configure WP Mail SMTP with Gmail” walkthrough.

The 2,000/day cap is rolling, not calendar. Workspace caps per-mailbox sending at 2,000 messages per 24-hour window, with separate caps on total recipients per day (10,000), external recipients per day (3,000), and unique external recipients per day (2,000). The window doesn’t reset at midnight tenant time; it rolls forward 24 hours from the message that crossed the limit. A site that exhausts the day’s quota at 18:00 doesn’t get fresh capacity at 00:00; mail starts flowing again at 18:00 the next day. The first cap a transactional WordPress site hits is the 2,000-messages cap; sites with high fan-out per message will hit the recipient caps first. The cap is identical across every paid Workspace tier (Business Starter, Standard, Plus, Enterprise); a higher plan does not buy throughput.

Workspace rewrites the From address in one specific configuration. When WordPress is configured to authenticate as [email protected] and send From [email protected] (the WP Mail SMTP “From Email” override is the classic source of this), Workspace will accept the submission and rewrite the From header to match the authenticated identity if the authenticated mailbox doesn’t have explicit send-as authorisation for the From identity. The behaviour is observed rather than Google-documented; the send-as docs cover the authorisation requirement but not the silent rewrite. Recipients see mail from [email protected]; plugin templates that branded the From as [email protected] look broken; downstream systems that recorded the original header (mailing lists, archivers, reply-tracking) see a mismatch. The fix is either to authenticate as the From mailbox or to grant the authenticated mailbox explicit send-as in the Workspace Admin Console.

App Passwords die on every password rotation. A Workspace user password change (forced by org policy, voluntary, or triggered by a compromise response) revokes every App Password issued to that account, immediately. The WordPress plugin keeps the cached credential and starts failing with 5.7.80 on the next outbound. This is the single most common “Workspace SMTP was working yesterday” failure mode. The mitigation is to use OAuth instead, or to add a calendar reminder for App Password regeneration that matches the password rotation cadence.

DKIM silently misaligns until the Admin Console “Start authentication” step is clicked. Publishing the DKIM TXT record at google._domainkey.yourdomain.com is necessary but not sufficient. Until the final step in the Workspace Admin Console flips Workspace into signing with the custom domain key, every outbound message signs with d=gmail.com. The send succeeds; DMARC alignment fails; no plugin-side error fires. Verify the alignment by sending a test message and inspecting the headers for d=yourdomain.com in the DKIM signature, not just for dkim=pass.

A sibling product is worth knowing exists: smtp-relay.gmail.com, configured at the tenant level in the Admin Console with IP allowlists or SMTP AUTH. Each Workspace user can send up to 10,000 messages per 24-hour rolling window through the relay, and the organisation as a whole can fan out to 4.6 million non-unique recipients per 24 hours; the relay suits multi-site agency setups or application servers sending mail unrelated to a specific Workspace user. For a single WordPress site sending on behalf of a real mailbox, the per-mailbox smtp.gmail.com path covered above is the fit; SMTP Relay setup is documented at Route outgoing mail through the SMTP relay service.

When to migrate to a transactional provider

When the site grows past Workspace, the off-ramp criteria are sharp:

  • Volume. A WooCommerce store past a few hundred orders a day, a membership site with regular automated touch points, any setup where the day’s send count regularly clears a few hundred. The 2,000/day rolling cap looks roomy until a backlog or a seasonal surge eats through it.
  • Audience. A site sending to more than a few hundred unique external recipients a day. Workspace’s per-mailbox limits are designed for human correspondence patterns; transactional sends look pathological to its rate-limiters.
  • Visibility. Any operational requirement for bounce webhooks, per-message delivery logs, or per-recipient suppression. Workspace’s admin reporting is delayed and aggregate; transactional providers expose per-message JSON over webhooks.
  • Identity. Mail that isn’t genuinely on behalf of a Workspace user. A site that sends as noreply@, orders@, notifications@, and support@ interleaved isn’t a Workspace use case.

The catalog of dedicated providers is at SMTP services for WordPress. Four are worth shortlisting:

  • Postmark is the right default for a site under 100,000 transactional messages a month, with bounce webhooks, per-message inspection, and a strict transactional-only posture that keeps reputation clean.
  • SMTP2GO covers transactional and lower-volume broadcast in one account, with a generous free tier and a predictable pricing curve.
  • Brevo (formerly Sendinblue) covers transactional and marketing in one account, with a daily-cap free tier that suits intermittent senders.
  • Amazon SES is the per-message-cheapest option once a site is comfortable with AWS console setup, sandbox-to-production approval, and managing its own bounce-handling.

References

Workspace primary sources:

Mailer plugin OAuth setup:

Standards reference:

Sibling nanoPost guides: