Guide
Google Workspace offers three different ways to send mail from an application or device, and the one called "SMTP relay service" is the only one built for it. This guide covers the settings, the authentication choice that trips people up, and the limits Google publishes.
Last reviewed July 2026
Google documents three ways for a printer, scanner or application to send mail. Two are named after Gmail, which is where the confusion usually starts.
The SMTP relay service (smtp-relay.gmail.com) is the one intended for this job. It is configured by an administrator in the Admin console, sends to external recipients, and allows each user in the organization to relay up to 10,000 recipients per day.
The Gmail SMTP server (smtp.gmail.com) authenticates as an individual user with an app password and is capped at 2,000 messages per day. It needs no Admin console configuration, so applications often start here and outgrow it without an obvious error.
The restricted Gmail SMTP server (aspmx.l.google.com) needs no authentication at all but delivers only to Gmail and Google Workspace addresses, which rules it out for customer-facing mail.
For transactional email to customers, the SMTP relay service is the only one of the three to configure. The sections below cover it.
The three options
Values are from Google's Workspace administrator documentation. The restricted server cannot send to external recipients, which rules it out for anything customer-facing.
| SMTP relay service | Gmail SMTP server | Restricted Gmail SMTP | |
|---|---|---|---|
| Hostname | smtp-relay.gmail.com | smtp.gmail.com | aspmx.l.google.com |
| Ports | 25, 465 or 587 (587 for TLS) | 465 (SSL) or 587 (TLS) | 25 |
| TLS | Recommended; required if using SMTP AUTH | Required | Not required |
| Authentication | IP allowlist, SMTP AUTH, or both | User address plus app password | None |
| Can send to external recipients | Yes | Yes | No - Gmail and Workspace addresses only |
| Admin console setup required | Yes | No | No |
| Sending limit | 10,000 recipients per user per 24 hours; 100 recipients per SMTP transaction | 2,000 messages per day | Per-user limits apply |
| Organization-wide ceiling | 4.6 million non-unique recipients per 24 hours; 319,444 per 10 minutes | Not published | Not published |
Source: Google Workspace administrator documentation, "Send email from a printer, scanner, or app" and "Route outgoing SMTP relay messages through Google". Trial accounts have lower limits than the figures above. Verify against Google's current documentation before relying on a limit.
Setup
Two halves: a setting in the Admin console that decides who is allowed to relay, and a hostname and port on the sending device.
In the Google Admin console, go to Apps, then Google Workspace, then Gmail, then Routing, and find the SMTP relay service setting. It is an organization-level setting, so decide which organizational unit it should apply to before you save.
Three options, narrowest first: registered Google Workspace users only; any address in your own domains; or any address at all. Choose the narrowest that works. The widest option rewrites the envelope sender to postmaster@your_domain whenever the address is on a domain you do not own, which changes what recipients and receivers see.
You must enable at least one of "Only accept mail from the specified IP addresses" (an IP allowlist) or "Require SMTP Authentication". Enabling both is the safer configuration. Requiring SMTP authentication also requires a TLS connection, so it is incompatible with a device that cannot do TLS.
Use port 587 if you are using TLS, which you should be. Ports 25 and 465 are also accepted. If you chose IP allowlisting rather than SMTP AUTH, the device needs a static public IP address that you have entered in the allowlist.
smtp-relay.gmail.com accepts a maximum of 100 recipients per SMTP transaction. An application that batches a large recipient list into one message will fail on this even though it is far below the daily ceiling. Split into separate transactions.
Google's sending infrastructure needs to be authorised in SPF for your domain. Then send a test message to an external address, not just an internal one, to confirm the sender-allowance setting is doing what you expect.
The organization-wide ceiling of 4.6 million non-unique recipients per 24 hours suggests volume is not a concern. Three details determine whether that holds for your application.
Each user may relay up to 10,000 recipients per day. An application sending through a single service account counts as one user, so its ceiling is 10,000 recipients per day, not the organization-wide figure. Spreading the load across several accounts raises the ceiling but leaves you maintaining accounts that exist only to work around a limit.
An application well inside its daily allowance is still rejected if it puts more than 100 recipients into one transaction. This constrains the shape of each send rather than the volume, and it has to be handled in the sending code.
Google states that trial accounts have lower limits, which rise once outstanding bills are paid. Load-testing on a trial tenant will not show you what production allows.
The Google Workspace relay routes mail your organization sends. It is not a transactional email platform, so it does not provide per-recipient bounce classification, engagement data with automated security-scanner activity separated from human opens and clicks, webhooks your application can subscribe to, per-message TLS enforcement, or suppression handling that distinguishes transactional mail from marketing.
Application mail relayed through Google Workspace also sends under the same organizational identity as your staff's correspondence, so a runaway loop or a bad recipient list on the application side affects the reputation your colleagues rely on.
Keep it for internal or low-volume operational mail: scanners, monitoring alerts, a reporting job that emails a handful of colleagues. It is already configured and costs nothing extra, and adding a vendor for that would be over-engineering.
Move the traffic when any of these is true:
Most organizations run both permanently. Human mailboxes stay in Google Workspace, and application traffic goes somewhere built for it. Moving one sending host is not a migration.
The alternative
The change on the sending side is the same shape as the Google configuration: a hostname, a port and a credential. Google Workspace keeps handling your mailboxes.
Omnivery vets every sending domain before it can send, typically one to three working days. Vetting is what keeps the shared sending pool clean, and it means the relay has to be set up in advance rather than during an incident.
Under the Credentials menu, SMTP users tab. The username is in email-address format and does not need to be a functional mailbox, though a domain you control is recommended.
Host smtp.omnivery.net, port 587, STARTTLS, and the new credential. The MAIL FROM and From addresses must belong to your configured sending domain. No SDK, no library swap, no code deployment.
If your application was splitting recipients to stay under Google's 100-per-transaction limit, that constraint is specific to smtp-relay.gmail.com. Check what your code is doing before you assume it still needs to.
These are separate from the records Google Workspace uses for your mailboxes, which is what decouples application sending reputation from staff email.
X-OV-Require-TLS refuses delivery to a receiver that will not encrypt. X-OV-Callback-URL gives your application a webhook stream. X-OV-Tag separates traffic types in reporting. All optional as SMTP headers, with full parity to the REST API.
At a glance
Questions
Server smtp-relay.gmail.com, on port 587 if you are using TLS, or port 25 or 465. Authentication is either an IP address allowlist or SMTP authentication, and you must enable at least one of them in the Google Admin console under Apps, Google Workspace, Gmail, Routing, SMTP relay service. Requiring SMTP authentication also requires a TLS connection.
smtp-relay.gmail.com is the Google Workspace SMTP relay service. It is configured by an administrator, allows 10,000 recipients per user per day, and can send from any address in your domains rather than only from one user. smtp.gmail.com is the Gmail SMTP server: it authenticates as a single user with an app password, needs no Admin console setup, and is limited to 2,000 messages per day. Applications tend to start on smtp.gmail.com because it is easier and then hit the 2,000-message ceiling without a clear error explaining why.
10,000 recipients per user per 24 hours, and a maximum of 100 recipients per SMTP transaction. Organization-wide, Google publishes ceilings of 4.6 million non-unique recipients per 24 hours and 319,444 recipients per 10-minute window. The per-user figure is the one that usually binds, because an application sending through a single service account counts as one user. Trial accounts have lower limits.
Three common causes. The 100-recipient-per-transaction limit, which fails messages that are well inside the daily allowance but batch too many recipients into one send. An authentication mismatch, where SMTP authentication is required but the connection is not using TLS, or the sending IP address is not in the allowlist. Or the sender-allowance setting being narrower than the From address you are using - if it is set to registered Workspace users only, an application sending as a non-mailbox address will be refused.
Within its limits, yes, and for low-volume operational mail it is a reasonable choice. What it does not provide is per-recipient bounce classification, engagement data with automated scanner activity separated out, webhooks your application can subscribe to, per-message TLS enforcement, or suppression handling that treats transactional mail differently from marketing. It also means application sending shares reputation with your staff correspondence. Those gaps, rather than the volume ceiling, are usually what moves a sender to a dedicated relay.
Point the application at smtp.omnivery.net on port 587 with STARTTLS and an Omnivery SMTP credential. Three configuration values and no code change, because SMTP is a protocol your stack already speaks. The sending domain has to be vetted first, typically one to three working days. Google Workspace continues to handle your mailboxes; only the application traffic moves.
Google Workspace stays where it is. Only the sending host changes, and the SMTP relay page covers what you get on the other side of it.