Google SMTP Relay: How to Set It Up and When Not To

Google SMTP relay is best used for controlled organizational systems such as printers, scanners, CRM notifications, and business applications that need to send through Google Workspace. Configure the narrowest sender scope, restrict access to known public IP addresses or authenticated Workspace accounts, and require TLS. We would not use it as the transport layer for an unsolicited cold-outbound program because Google's sender guidance says not to send to people who did not sign up.

Before You Configure Google SMTP Relay

List every device or application that will send through the relay. For each one, record its visible From address, public egress IP, TLS support, owner, and expected message type. Do not begin by creating a broad rule and promising to narrow it later. Broad relay access is easy to forget and expensive to discover after a device or credential is compromised.

Google's current SMTP relay administration guide says this setting is managed at the top-level organization. Child organizational units can view it, but they cannot add, edit, or delete the service. Use a Workspace administrator account with the required Gmail settings privileges before starting.

Choose the relay for internal business workloads whose identity and sending pattern you control. If the application needs campaign sequencing, consent records, suppression workflows, or separate reputation management, those requirements belong in the product decision before the Admin console is opened.

Our view: a relay rule should name one workload and one owner. Combining printers, product alerts, sales tools, and third-party applications under one broad rule makes an incident harder to contain because the same control has to remain open for unrelated systems.

Configure Google SMTP Relay in the Admin Console

Sign in to the Google Admin console, then follow this path:

1. In the Admin console, open Apps.
2. Select Google Workspace from the list.
3. Open the organization's Gmail settings.
4. Choose Routing from the available settings.
5. Scroll to SMTP relay service.
6. Select Configure to create the service. If a relay already exists, add another rule or edit the correct one rather than changing an unrelated workload.

Give the service a description that identifies the application and owner, such as Finance invoices - NetSuite - finance systems. The name should let another administrator understand the rule without opening a separate inventory.

Google provides three allowed-sender scopes. Its narrowest option allows only registered Workspace users in your domains. A second option allows any address in your domains, including application addresses that are not Workspace users and addresses in subdomains. The broadest allows any address, which Google marks as not recommended because it increases abuse exposure.

Choose registered users when every sender has a Workspace account. Choose addresses in your domains when a controlled application must send as a non-user address such as invoices@example.com. Avoid any address unless there is a documented need that the narrower choices cannot satisfy.

Choose IP Authentication, SMTP Authentication, or Both

Google lets you restrict relay access to specified public IP addresses, require SMTP authentication, or apply both controls. Base the choice on what the sending system can support.

Use IP authentication for a server or device fleet with stable, dedicated public egress addresses. Add only the public IP addresses Google will see, not private addresses such as 10.x.x.x or 192.168.x.x. Google recommends keeping allowed ranges as small as possible, so do not enter an entire provider range when one fixed address serves the workload.

Use SMTP authentication when the application can store and rotate credentials safely. Google requires TLS for SMTP authentication and validates a Workspace account address and password. Keep the account dedicated to the workload so a staff departure or password change does not silently stop a business system.

Selecting both controls gives you a narrower rule, but only if the application's egress address is stable and its credential handling is reliable. If either condition changes often, the result may be repeated outages rather than useful defense. Document who owns each dependency before turning both on.

Configure the Server and Require TLS

Point the sending system at smtp-relay.gmail.com. Google's guide directs TLS connections to port 587. It also documents ports 25, 465, or 587 without TLS, but SMTP authentication is unavailable without TLS and IP authentication must be used.

Select Require TLS encryption in the relay configuration when every system in scope supports it. Google says the relay will reject unencrypted connections when this option is enabled. Test old printers and line-of-business applications before enforcement because outdated firmware may claim SMTP support without offering a current TLS connection.

Do not lower the security of every sender to accommodate one old device. Put the incompatible device behind a controlled internal mail gateway, replace it, or keep it out of scope until there is a defined exception. A broad unencrypted path created for one scanner can become the default path for applications added months later.

Google says configuration changes can take up to 24 hours, although they usually apply sooner. Allow for that window before treating a failed test as proof that the hostname, port, or authentication choice is wrong.

Test the Relay and Keep the Evidence

Send a controlled message from the real application rather than from a laptop configured to imitate it. Confirm that the application records a successful submission, then inspect the destination mailbox and download the raw headers. The headers should identify the expected relay path and sender authentication results.

Run a negative test as well. Try a sender outside the allowed scope or a connection outside the approved IP range in a safe test window. The relay should reject it. A setup is not verified if the approved path works but the restriction has never been tested.

Record the Admin console rule name, sending host, public IP, sender scope, authentication method, TLS requirement, owner, test timestamp, and raw-message location. If delivery later fails, this record separates configuration drift from a receiving-provider decision.

Our guide to fixing email authentication failures covers the SPF, DKIM, and DMARC evidence to inspect in those headers. Google relay access only answers whether the application may submit. It does not establish final mailbox placement.

Know the Google SMTP Relay Limits

Google currently documents relay maxima of 10,000 messages per Workspace user in 24 hours, 10,000 unique recipients per user in 24 hours, and 100 recipients per SMTP transaction. It also lists 4.6 million non-unique recipients for the organization in a 24-hour period. Trial accounts can have lower limits, and Google may reduce limits based on sending practices.

These numbers are service ceilings, not recommended operating targets. A workload can remain below every ceiling and still create spam complaints, damage domain reputation, or trigger enforcement. Build your own lower controls around the application's legitimate transaction volume and alert on any sudden change.

Google's SMTP relay spam policy says it monitors relay traffic. Google can alert administrators and suspend an account that continues sending spam after an alert. The same policy warns that spam can harm domain reputation, push legitimate mail into spam or rejection, consume relay limits, and slow delivery.

When Not to Use Google Workspace SMTP Relay

Google's email sender guidelines tell senders not to purchase email addresses and not to send to people who did not sign up. They also require authentication, TLS, low spam rates, and unsubscribe support for the senders and message types covered by those rules.

We read that guidance as a clear product-fit warning. Google Workspace relay is a poor choice for unsolicited cold-outbound programs, particularly those built on purchased or non-opted-in addresses. This is our editorial conclusion from Google's guidance, not a claim that the relay technically rejects every cold email.

Use a provider whose current terms expressly permit your exact sending model and whose controls cover suppression, campaign pacing, reputation isolation, and message-level event history. Our SMTP relay selection test shows what to verify before moving a workload.

Also reconsider Google relay when your systems use unstable public IPs, cannot support TLS, need separate reputation from staff mail, or require campaign-grade reporting. For controlled printers, alerts, and organizational applications, the relay can be a clean fit when its rule stays narrow and owned.

Ready to Review Your Sending Layer Before It Goes Live?

We can review the relay rule, authentication path, sending identities, and ownership boundaries as part of the outbound system your team controls. Book your free discovery call →