Using Google for SMTP Transactional Email Delivery

/

Every website sends transactional email, and most of them do it badly.

Password resets, contact form notifications, order receipts and privacy request confirmations all need a reliable delivery path, and the default on most hosts is PHP’s mail() function sending unauthenticated mail from a shared server IP, which is a recipe for the spam folder. If your organization already runs on Google Workspace, you have a well-trusted SMTP server sitting right there, and a dedicated mailbox with an app password turns it into a perfectly good transactional delivery system for low-volume sites. This post covers what that setup looks like, how to do it step by step, and the limits that tell you when you’ve outgrown it.

Why Route Transactional Email Through Google?

The case for it comes down to four things:

  • Deliverability you don’t have to earn. Mail leaves Google’s infrastructure, authenticated against your domain. With Workspace handling DKIM signing and your SPF record already including _spf.google.com, your transactional mail carries the same authentication as the mail your team sends every day.
  • No new vendor. For a site sending a few dozen messages a day, standing up SendGrid, Postmark or Amazon SES is another account, another API key, another bill and another DNS change. A Workspace mailbox you already pay for does the job.
  • A built-in paper trail. Mail sent through SMTP lands in the account’s Sent folder. For anything compliance-adjacent, like privacy request confirmations or legal notices, that is a searchable record of exactly what the site sent and when, and Google Vault can retain it indefinitely if you need real retention policy behind it.
  • A real address people can reply to. Transactional mail from a genuine mailbox means replies go somewhere a human can read them, instead of bouncing off a no-reply relay.

Step 1: Create a Dedicated User

Do not wire your website to a personal mailbox.
Create a dedicated user for the function the mail serves, something like [email protected] or [email protected]:

  1. Sign in at admin.google.com as a Workspace admin
  2. Go to Directory > Users and click Add new user
  3. Give it a functional name and the primary email address the site will send from
  4. Set a strong password and save it in your password manager

A dedicated account costs one license, but it isolates the credential: if it’s ever compromised or rate-limited, nothing else in your organization is affected, and nobody’s personal password change silently breaks the website’s email.

Step 2: Enable 2-Step Verification

App passwords, which are how your site will authenticate, only exist on accounts with 2-Step Verification turned on.

On the admin side, go to Security > Authentication > 2-step verification in the Admin console and make sure users are allowed to turn it on. One caveat worth knowing: you cannot enforce “security key only” 2SV for this account and also use app passwords, so leave the enforcement at the standard level for this user.

Then sign in as the new account, go to myaccount.google.com/security, and complete 2-Step Verification setup under “How you sign in to Google.”

Step 3: Create an App Password

Still signed in as the sending account:

  1. Go to myaccount.google.com/apppasswords
  2. Name it after what it’s for, like WordPress SMTP
  3. Click Create and copy the 16-character password immediately, because Google will not show it again

Two things to remember about app passwords: they bypass 2SV by design, so treat them like any other production secret, and they are automatically revoked whenever the account’s main password changes, so changing that password means generating a new app password and updating the site.

Step 4: Configure Your Site’s SMTP Settings

Point your site or application at Gmail’s SMTP server with the new credentials:

Server:   smtp.gmail.com
Port:     587 (TLS) or 465 (SSL)
Username: the full email address ([email protected])
Password: the 16-character app password

In WordPress this is a five-minute job with any SMTP plugin (WP Mail SMTP and FluentSMTP both work fine with the “Other SMTP” or Gmail-SMTP option), or a few lines on the phpmailer_init hook if you’d rather skip the plugin. Outside WordPress, any framework mailer that speaks authenticated SMTP takes the same four values.

One behavior to design around: Gmail rewrites the From address to the authenticated account (or one of its configured aliases). You cannot send as [email protected] from this connection, which is another argument for naming the mailbox after its real function up front.

Step 5: Verify

Send a test message from the site, then confirm two things: it arrived with a passing authentication result (Gmail’s “show original” view will show SPF, DKIM and DMARC evaluations), and it appears in the sending account’s Sent folder. That Sent copy is your delivery log.

If you have retention requirements, this is also the point to turn on comprehensive mail storage (Apps > Google Workspace > Gmail > Compliance) and put a Vault retention rule over the account, which keeps every message searchable and exportable even after someone deletes it from the mailbox.

The Limitations

This setup has a ceiling, and you should know where it is before you commit to it:

  • 2,000 messages per day. That is the hard sending limit for a Google Workspace account over a rolling 24-hour period, and a free @gmail.com account gets only 500. Exceed it and Google suspends sending for the account for up to 24 hours, with no queue and no retry on their side. Whatever your site tried to send during a lockout is simply not delivered unless your application handles the failure.
  • Recipient limits too. The daily cap counts recipients, not messages, and there are per-message recipient limits as well. A notification that CCs five people burns five units of quota.
  • Transactional only. This is not a path for newsletters, marketing blasts or anything resembling bulk mail. Beyond violating Google’s policies, bulk patterns from a single mailbox are exactly what gets an account rate-limited or suspended.
  • No delivery analytics. There are no webhooks, no bounce API and no open or click tracking. Bounces arrive as emails in the inbox, and nothing tells your application a message failed. Dedicated ESPs exist largely because of this gap.
  • Credential fragility. App passwords are revoked on password change, and Google has been steadily tightening access for password-based protocols. The setup is stable today, but it rides on a legacy authentication mechanism rather than OAuth.

If you’re brushing against the 2,000-per-day cap, Google Workspace also offers an SMTP relay service (smtp-relay.google.com) with a 10,000-per-day limit and IP-based authentication, which is a reasonable intermediate step. Beyond that, it’s time for a real transactional provider like Amazon SES or Postmark.

The Bottom Line

For a typical business website sending password resets, form notifications and a handful of operational messages, a dedicated Google Workspace mailbox with an app password is a reliable, authenticated, zero-additional-cost delivery path with a built-in audit trail. Know the 2,000-message ceiling, name the mailbox after its function, treat the app password like a production secret, and it will quietly do its job for years.