Google Workspace SMTP Relay or smtp.gmail.com? Pick Right
Workspace gives a domain three separate roads out for machine-generated mail, and choosing by copying whichever config a blog post showed first is how teams end up with the wrong limits, the wrong failure modes, and a migration later. The google workspace smtp relay is only one of the three - the right one often, the wrong one surprisingly often too.
Here is the decision made properly: what each route is, what it costs you in setup and ceilings, and the table that picks for you.
The three routes in one table
| Route | Host | Auth | Daily ceiling | External recipients |
|---|---|---|---|---|
| Gmail SMTP | smtp.gmail.com | Account + app password | 2,000 recipients/user | Yes |
| SMTP relay service | smtp-relay.gmail.com | IP allowlist and/or SMTP AUTH | 10,000 recipients/user | Yes |
| Restricted gateway | aspmx.l.google.com | None | Effectively unlimited for what it does | No - your own Google-hosted users only |
Three details the table cannot hold. The Gmail SMTP route sends as a mailbox and lands in that mailbox's Sent folder, which is sometimes exactly what you want and sometimes a compliance problem. The relay is configured domain-wide by an admin, not per account. And the restricted gateway needs no authentication precisely because it refuses to deliver anywhere except inboxes your own organization hosts - spam to yourself is your problem, Google figures.
Route one: smtp.gmail.com, the mailbox door
This is a user's own sending pipe exposed to software. It needs the account's address plus an app password (2-step verification required first), and everything it sends is that user, fully: their quota, their Sent folder, their reputation.
Pick it when a human identity should own the mail - a founder's follow-ups, a small tool sending a handful of messages that ought to look and thread like personal mail. Avoid it the moment volume matters: the 2,000-recipient rolling limit includes the human's own correspondence, and one enthusiastic script can lock the actual person out of sending until tomorrow. That shared-bucket problem is the route's defining risk.
Route two: the google workspace smtp relay
The relay exists for exactly the gap the other two leave: real volume, external recipients, no mailbox identity required. An admin configures allowed senders, authentication (registered IPs, SMTP AUTH, or both), and TLS policy in the Gmail routing settings; applications then send through smtp-relay.gmail.com with a 10,000-recipient allowance per sending user.
Its failure modes are administrative, not technical: an egress IP that changed after the allowlist was written, an app password revoked by a security sweep, a From address outside the domain. Its genuine limitation is that the allowance is fixed - growth does not negotiate with it.
Route three: the restricted gateway nobody remembers
aspmx.l.google.com on port 25, no authentication, and one iron rule: recipients must be addresses your Google organization hosts. It exists for devices and legacy systems that need to email your own people - a scanner mailing scans to staff, a monitoring box alerting an internal list - without being trusted with credentials or the open internet.
Because it cannot reach external addresses, it is useless for anything customer-facing, and harmless in the way the other routes are not: a compromised device on this route can annoy your employees and nobody else. Remember port 25 must be open outbound from wherever the device sits, which on cloud networks it frequently is not.
What each route asks of your DNS and your admin
The routes also differ in what they demand before the first message flows, and the differences decide how long setup takes. smtp.gmail.com needs nothing from an admin beyond app passwords being permitted - a user can wire it up alone in five minutes, which is both its convenience and its shadow-IT risk. The relay needs an admin in the Gmail routing settings once, and it needs your SPF record to include Google if recipients are to trust what comes out; domains that skip the SPF step get delivery that works but authenticates poorly, which surfaces months later as spam-folder drift. The restricted gateway needs no configuration at all inside Workspace, but the sending network must reach port 25, and the device's From address should still be a real internal one so replies and bounces have somewhere sane to land. None of the three will carry a From domain you do not own.
The decision, asked as four questions
- External recipients? No: restricted gateway, done. Yes: continue.
- Should a person's identity own the mail? Yes, and volume is small: smtp.gmail.com. No: continue.
- Under 10,000 recipients a day per sender, operational in nature? Yes: the relay. It is built for this.
- Bulk, growing, or campaign-shaped? None of the three. Workspace routes all share one property: the ceiling is a constant while your list is a curve. Sustained bulk belongs on dedicated sending infrastructure with reputation tooling, warmup, unsubscribe handling, and headroom that scales.
Mixing routes without confusing yourself
Most real domains run two routes at once - the relay for application mail, smtp.gmail.com for one or two human-identity automations - and confusion arrives at debugging time, not setup time. Two habits prevent it. Give every workload its own envelope sender, so bounces name the culprit. And when a limit trips, read the bounce class before touching config: mailbox-limit language means the Gmail route, relay language means the relay, and user not found in this organization means someone pointed external mail at the restricted gateway.
The routes fail with different vocabulary on purpose. Learn the vocabulary once and every future incident starts half-solved.
Frequently asked questions
What is the difference between Google Workspace SMTP relay and smtp.gmail.com?
smtp.gmail.com sends as one authenticated mailbox with a 2,000-recipient daily limit and lands in the account's Sent folder. The relay (smtp-relay.gmail.com) is a domain-wide service configured by an admin, authenticates by IP or SMTP AUTH, and carries a 10,000-recipient allowance per sending user.
When should I use aspmx.l.google.com instead of the relay?
Only for mail whose recipients are all inside your own Google-hosted organization - scanners, appliances, and internal alerts. It needs no credentials, but it refuses external delivery entirely, so anything customer-facing cannot use it.
Does the Google Workspace SMTP relay work for bulk marketing email?
It can physically send it up to the allowance, but it is the wrong tool: the ceiling never grows, and Google's bulk-sender requirements (authentication, one-click unsubscribe, spam-rate thresholds) apply with no platform tooling to help you meet them. Sustained campaigns belong on dedicated sending infrastructure.
Can I use all three Workspace SMTP routes at the same time?
Yes, and mature domains usually do. Keep a distinct envelope sender per workload and note which route each service uses, so a tripped limit or a bounce can be matched to the right system in seconds.