Sending email through Google Workspace: relay options, limits, and where the line is

Q: What is the Google SMTP relay?

smtp-relay.gmail.com, the Workspace SMTP relay service: an admin-configured endpoint that accepts mail from your applications and devices, authenticated by registered IP or credentials, and delivers it as your domain through Google's infrastructure under documented per-user allowances.

2026-10-05

Google Workspace gives every domain three different doors out for application mail, and picking the wrong one is among the most common infrastructure mistakes small senders make. A CRM, a website contact form, a scanner, an invoicing system: each needs to send as your domain, each has an SMTP settings screen, and each will appear to work through whichever Google endpoint you point it at, right up until a limit or a filter says otherwise. This guide maps the three doors, the limits Google documents for each, the authentication that has to be true regardless, and the point at which the honest answer stops being Workspace at all.

Door one: the Gmail SMTP server

smtp.gmail.com, port 587 with STARTTLS, authenticated with a mailbox's credentials (in practice an app password or OAuth). Mail sent this way counts against the sending mailbox exactly as if a person had sent it, lands in the account's Sent folder, and inherits the per-user limits Google documents for Workspace: 2,000 messages per day on paid accounts and 500 on trial accounts. This door suits genuine per-user tooling, a mail client, a CRM sending as one salesperson, and little else, because one busy application can exhaust a human's sending allowance.

Door two: the SMTP relay service

smtp-relay.gmail.com, the door actually built for infrastructure, configured by an administrator in the Admin console. It authenticates by registered IP address or by account credentials, can be required to use TLS, and can be allowed to send only from addresses within your domain. This is Google operating as your SMTP relay in the full sense, and Google's Workspace documentation gives it a larger, but still bounded, allowance: 10,000 recipients per user in a 24-hour period, with a 100-recipient cap on each SMTP transaction. Google's relay documentation also describes spam and virus filtering on relayed mail and alerts super administrators when a user relays a significant amount of spam, so the bigger pipe comes with the same scrutiny.

Door three: the restricted relay

aspmx.l.google.com, Google's inbound MX endpoint, which will accept unauthenticated mail from your devices with one severe catch that its name states: restricted. It delivers only to Gmail and Workspace-hosted recipients, accepts connections on port 25 only, and runs under the standard Workspace per-user limits, per Google's device-sending documentation. It exists for the printer that must email scans to your own staff, and nothing else. Anything that mails customers through this door will bounce for every recipient hosted outside Google, a failure you can recognize by reading the bounce-back text.

The records that must be true for all three

Whichever door you use, receivers authenticate your domain, not Google's. Three records, one pass each. Your SPF record needs include:_spf.google.com, and if other services also send as the domain, watch the 10-lookup limit. DKIM must be finished in the Admin console: generate the key, publish the selector record at your DNS host, and activate signing, or your mail signs with a default identity that fails alignment. And a DMARC record ties the two to the visible From address; Google's own sender requirements expect it of every meaningful sender. Verify the triad from outside with the email authentication checker, and run the email DNS check after any change. The reasons this matters are not abstract: the failure pattern for Workspace domains that skip these steps is documented in Google Workspace emails going to spam.

What the relay is not for

Google positions Workspace as correspondence infrastructure, and the limits enforce the position. Newsletters, promotional campaigns, and any list measured in thousands do not belong on any of the three doors, for reasons beyond arithmetic. The relay has no bounce processing worth the name, no suppression list automation, no one-click unsubscribe machinery, and no complaint telemetry, all of which the bulk-sender rules effectively require of campaign mail. Pushing campaigns through it puts your whole domain's reputation behind mail that cannot meet those obligations, and every employee's ordinary correspondence shares the consequences.

When to move to an ESP, and how

The line is crossed when mail becomes bulk or promotional in nature, or when a transactional stream's volume approaches the documented ceilings. At that point the workload belongs with a sending platform built for it: campaign mail to a marketing platform, application mail to a transactional provider, both categories profiled neutrally in our services directory, with measured placement comparisons arriving via the deliverability benchmark as test cycles complete. Put the new stream on its own subdomain so its reputation is accounted separately from your Workspace correspondence, warm it up per IP warming discipline, and leave Workspace doing the one job it is excellent at: mail from people.

Two operational habits make the boundary durable. First, inventory: keep a list of every system pointed at any of the three doors, because the relay's failure mode is a forgotten device that starts misbehaving under a name nobody monitors, and your DMARC reports are the audit that finds it. Second, watch the limits from your side rather than Google's: a system that routinely approaches the documented ceilings is telling you its workload has outgrown correspondence infrastructure, and the graceful moment to migrate is before the first refused send, not the morning after a queue of stuck invoices. Limits are enforced at send time, so the first visible sign of a breached ceiling is usually mail that has already been refused.

Related guides

Sending email through Microsoft 365 — the same decision tree on the other office suite
SMTP relay — the general mechanics of relayed sending
Google Workspace emails going to spam — the failure mode when authentication is left unfinished
Gmail sender requirements — the rules Google applies to your domain's mail
Email subdomain — separating bulk streams before they can hurt correspondence
Email authentication checker — verify SPF, DKIM and DMARC end to end

About this guide

Written by InboxRatio Editorial. Endpoint names, configuration options, and sending allowances (2,000 messages per user per day, 500 on trial accounts; 10,000 recipients per user per 24 hours and 100 recipients per SMTP transaction on the relay) follow Google's published Workspace documentation, checked in September 2026, which governs if numbers change; filtering expectations follow Google's published sender guidelines. This guide covers legitimate application and correspondence mail, not filter-evasion or quota-evasion techniques. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on provider documentation rather than our measurements; the protocol is in how we test and our source rules in sources.

Last updated

5 October 2026. Google documentation and limits reviewed quarterly.

Frequently asked questions

What is the Google SMTP relay? smtp-relay.gmail.com, the Workspace SMTP relay service: an admin-configured endpoint that accepts mail from your applications and devices, authenticated by registered IP or credentials, and delivers it as your domain through Google's infrastructure under documented per-user allowances.

What are Google Workspace's sending limits? Google documents 2,000 messages per user per day through Gmail and the Gmail SMTP server (500 on trial accounts), and 10,000 recipients per user per 24 hours through the SMTP relay service, capped at 100 recipients per SMTP transaction. Google's current documentation is authoritative if these change.

What is the difference between smtp.gmail.com and smtp-relay.gmail.com? The first is the per-mailbox door: it authenticates as one user and spends that user's sending allowance. The second is the domain's infrastructure door: admin-configured, able to authenticate by IP, with a larger documented allowance and domain-level controls.

Can I send a newsletter through Google Workspace? Not at meaningful scale. The allowances are sized for correspondence, and the relay lacks the unsubscribe, bounce and complaint machinery bulk mail is required to have. Campaigns belong on a sending platform, on their own subdomain.

Why is my relayed mail still going to spam? Relaying through Google authenticates the transport, not your domain. If SPF lacks Google's include, Admin-console DKIM was never activated, or DMARC is absent, receivers treat the mail as unauthenticated. Verify all three records, then look at content and list quality.

Does the restricted Gmail relay work for external recipients? No. aspmx.l.google.com delivers only to Google-hosted mailboxes and is meant for internal device mail. Anything addressed outside Google bounces; use the SMTP relay service or an ESP for external mail.

Three doors, one rule: Workspace carries mail from people, and infrastructure mail rides the relay only until it starts looking like a campaign. Configure the right door, finish the records, and let the email DNS check confirm the domain side is done.