Google Workspace can send application mail. It is still not a transactional sending API. Gmail SMTP relay and the Gmail API accept messages; they do not give you managed retries, bounce and complaint events, per-message delivery history, or a support-facing send log. Teams discover the gap when a password reset is “accepted” and nobody can prove what happened next.
The incident that exposes the wrong abstraction
A user cannot reset a password. Engineering says the SMTP client returned 250. Support searches the shared mailbox and finds nothing. There is no message id the ticket can follow, no bounce timestamp, and no complaint event. The mail may be delayed, in spam, or rejected after acceptance. Acceptance is not delivery.
That is the difference between a mailbox product and transactional email infrastructure. Workspace is excellent at human inbox access. Application mail needs a different job: submit, observe, retry, and explain.
Three jobs that get collapsed into one Workspace account
Teams usually wire the app to whatever mailbox they already pay for. That mixes three jobs:
- Human mailbox access. People read and reply in Gmail or a client.
- Authenticated relay. A device or app submits through smtp-relay.gmail.com or smtp.gmail.com.
- Application delivery infrastructure. The product needs idempotent sends, event capture, suppression, and a log support can open without asking engineering.
Google Workspace does the first job well. It can do the second. It does not sell the third as a managed platform.
Can Google Workspace send transactional email?
Yes. Password resets, receipts, and invoices can leave a Workspace identity. Google documents SMTP relay for printers, scanners, and apps, and the Gmail API can call messages.send. The question is not “can it emit SMTP.” The question is whether your team owns everything after the 250.
If volume is low, the sender is a real user mailbox, and you can tolerate mailbox-search as the only observability, relay can be acceptable. The moment support must answer “did order 1042 send?”, relay is the wrong abstraction.
Google Workspace SMTP vs Gmail UI vs Gmail API
These paths do not share one quota table. Google’s admin help (reviewed 10 Sep 2026) treats Gmail UI sending and SMTP relay as independent counters.
| Path | What it is | Documented caps to re-check live | What you still own |
|---|---|---|---|
| Gmail UI (paid Workspace) | Human compose and some delegated send | Commonly 2,000 messages per user per rolling 24 hours (1,500 mail merge; 500 trial) | No application event model |
SMTP relay (smtp-relay.gmail.com) | Org-authenticated relay for apps and devices | Up to 10,000 messages and 10,000 unique recipients per user per 24 hours; 100 recipients per SMTP transaction; org-wide 4.6 million recipients / 24 hours and 319,444 / 10-minute window | Retries, idempotency, bounce parsing, complaint handling |
| Gmail SMTP via mailbox credentials | Client or app using a user identity | Gmail UI-class daily caps apply on this path; Google no longer treats less-secure password login as the supported client model | OAuth token lifecycle and user-seat coupling |
Gmail API messages.send | HTTP send into a user’s mailbox context | 100 quota units per send; 1,200,000 units/minute per project; 6,000 units/minute per user; 80,000,000 units/day per-project threshold. Recipients per Gmail API message: 500 | Quota math, OAuth scopes, and still no provider-style delivery webhooks |
Google states sending limits can change without notice. Quote the live Gmail sending limits and SMTP relay pages before you freeze an architecture review.
What changes when password auth goes away
Workspace no longer supports less-secure username/password sign-in for third-party mail clients. Current Google guidance expects OAuth for supported client access. That is correct for humans. It is operationally expensive for a cron job that sends receipts.
OAuth means token storage, refresh, revoked grants when an employee is offboarded, and a send path tied to a user seat. If the “application sender” is noreply@ sitting on one engineer’s Workspace user, offboarding that engineer can stall product mail. That is a mailbox identity problem, not an API problem. See employee email offboarding.
When SMTP relay is acceptable — and when it is not
Relay is a reasonable fit for:
- A scanner that emails a PDF to a known internal address.
- A low-volume internal alert that nobody has to audit later.
- A stopgap while you authenticate a proper sending domain.
Relay is the wrong abstraction when:
- You send password resets, OTPs, or receipts that customers will dispute.
- You need retries that are idempotent across worker crashes.
- Support must see a timeline without IMAP search.
- Marketing and transactional mail share one Workspace identity (they should not; see separate subdomains).
- You assume SMTP acceptance equals inbox placement. It does not. See why emails go to spam.
Port choice on relay is a separate, smaller issue. Google documents ports 25, 465, and 587 for smtp-relay.gmail.com. For protocol behavior, use the existing guide on SMTP ports 25, 465, and 587.
How you observe bounces, delays, and complaints on Workspace
Mailbox products return mail to the envelope sender or a catch-all. They do not give you a first-class activity log keyed by your application’s message id.
Typical Workspace-era workflows:
- Search Sent Mail and hope the app used that mailbox.
- Watch the postmaster mailbox for DSNs written in free text.
- Open Admin console after a user reports “nothing arrived.”
- Treat Gmail spam classification as invisible unless the recipient forwards a screenshot.
That is why teams later add Amazon SES, Postmark, Resend, or another sending API. They are buying events and a support surface, not “the ability to speak SMTP.” If support should not page engineering to reconstruct a send, read support should see the transactional email log.
Arawa Mail documents outgoing webhooks for incoming mailbox messages (helpdesk and automation), plus HTTP send via a Resend-compatible Send Email API and a Mailgun-compatible path. Enable Sending requires receiving first. The HTTP from domain must be registered, allowed by the API key, and sending-active. Do not treat mailbox webhooks as a substitute for delivery event subscriptions unless the product documents those events.
Gmail API transactional email: usable, not a sending platform
The Gmail API is a mailbox API. messages.send costs 100 quota units. Google’s developer quota page (reviewed Sep 2026) lists 1,200,000 units per minute per project, 6,000 per user per project per minute, and an 80,000,000 unit per-day per-project threshold. Google plans to share billing details later in 2026 with at least 90 days’ notice if usage above quota request limits will be charged. You cannot treat it as a free unlimited pipe.
The API also stays inside a user’s Gmail context. That is useful for agents that need a real mailbox (see agents need a mailbox). It is a poor fit for blast receipts from a shared product identity with provider-grade suppression.
Comparison: mailbox, relay, API, events, retries, support
| Capability | Workspace mailbox | Workspace SMTP relay | Gmail API send | Transactional sending API |
|---|---|---|---|---|
| Human inbox and reply | Yes | No (submit only) | Via the user’s mailbox | Only if the vendor also hosts mailboxes |
| App can submit mail | Indirect | Yes | Yes | Yes |
| Per-message delivery timeline for support | Mailbox search | DSN / admin guesswork | Mailbox + quota errors | Designed for this |
| Bounce / complaint as structured events | Not a product feature | Not a product feature | Not a product feature | Expected |
| Retries and idempotency | You build them | You build them | You build them | You still design them; the platform gives message ids |
| Auth model | User session | IP / domain relay rules | OAuth user scopes | Restricted API keys on a sending-active domain |
Common mistakes
- Using one shared Workspace mailbox as the application sender with no retry or event model.
- Assuming SMTP 250 means the message reached the inbox.
- Sending password resets, receipts, and marketing from one Workspace identity.
- Building support around mailbox search because there is no provider-native delivery timeline.
- Pointing Next.js or Laravel at smtp.gmail.com and calling it an email platform. Use a sending API when the product mail is load-bearing; see send transactional email from Next.js and transactional email webhooks.
How we analyzed this
On 17 Sep 2026 we re-read Google Workspace Help for Gmail sending limits and SMTP relay, plus Google’s Gmail API quota reference. We compared those jobs to Arawa Mail’s documented Enable Sending rules (receiving first; from domain registered, key-allowed, sending-active) and to the live outgoing-webhook docs, which describe inbound mailbox notifications rather than provider bounce payloads. Limits cited above are Google’s published figures that day and can change without notice.
If you are leaving Workspace as the company inbox, that is a different project: how to move business email off Google Workspace and the custom-domain migration checklist. A later comparison page will cover buyer fit and total cost versus Workspace; this article only separates mailbox, relay, and sending API.
FAQ
Is Google Workspace SMTP a sending API?
No. SMTP relay is an authenticated submission path into Gmail’s outbound servers. A sending API is an application contract: authenticated HTTP, message ids, and (on a transactional platform) delivery visibility.
Can I use the Gmail API for transactional email?
You can call messages.send. You still operate inside a user’s mailbox quota and OAuth model, and you still lack a managed delivery event bus. Use it for mailbox-centric agents, not as a substitute for product-mail infrastructure.
What are current Google Workspace sending limits?
Paid Gmail UI sending is commonly 2,000 messages per user per 24 hours. SMTP relay is commonly 10,000 messages and 10,000 unique recipients per user per 24 hours, with org-wide recipient caps and a 100-recipient cap per smtp-relay.gmail.com transaction. Recheck Google’s live tables; they change.
Why do teams add SES or another provider later?
Volume, events, and support. Relay hits caps or produces undiagnosable customer tickets. A sending API makes the send a first-class object.