Why this matters
SMTP relay is often the right way to let business systems send mail through Google Workspace, but an overly broad relay rule can create abuse risk while an overly restrictive rule can block legitimate devices.
Before you begin
- A Google Workspace administrator account with Gmail settings privileges.
- The public IP address or authentication method used by the sending system.
- The sender addresses or domains the device/application will use.
- A maintenance window if the relay is already in production.
Step-by-step instructions
Step 1: Inventory the sender
Record the system name, sender address, public source IP, expected recipients, and whether TLS is supported.
Why this step mattersThis prevents creating a relay rule broader than the actual business requirement.
What to look forYou should be able to identify exactly which system is allowed to send and from where.
Step 2: Open the SMTP relay setting
In the Google Admin console, go to Apps > Google Workspace > Gmail > Routing, then locate SMTP relay service.
Why this step mattersGoogle controls SMTP relay centrally in Gmail routing. The setting is created at the top-level organization.
What to look forYou should see the SMTP relay service configuration area.
Step 3: Choose allowed senders carefully
Prefer registered users or addresses in your domains unless the application has a documented reason to send from other addresses.
Why this step mattersRestricting senders reduces spoofing and relay abuse.
What to look forThe selected sender scope should match the system's real From/envelope-sender behavior.
Step 4: Choose an authentication method
Use IP-based authentication for systems with a stable public IP, or SMTP authentication where appropriate. Require TLS when the device supports it.
Why this step mattersAuthentication is what prevents your relay from behaving like an open relay.
What to look forThe source IP or authenticated identity should be explicitly authorized.
Step 5: Configure the sending system
Point the device or application to smtp-relay.gmail.com. Use a supported port such as 587 with TLS when possible, or another Google-supported port that matches the device capability.
Why this step mattersThe application and the Admin console must agree on transport and authentication.
What to look forA connection test should reach Google without authentication or relay-denied errors.
Step 6: Send controlled test messages
Test to an internal mailbox and an external mailbox. Verify sender, delivery, spam placement, and message headers.
Why this step mattersTesting both destinations catches routing and policy differences.
What to look forBoth messages should arrive with the expected sender identity and without relay errors.
Step 7: Document and monitor the configuration
Record the business owner, source IP, sender restrictions, TLS settings, and review date.
Why this step mattersRelay configurations are security-sensitive and should not become forgotten permanent exceptions.
What to look forThe configuration can be reviewed later without reverse-engineering why it exists.
What to look for when you are finished
A successful result should match the business purpose described above, use the smallest necessary access or configuration scope, and leave enough documentation that another authorized administrator can understand what was changed and why.
When to stop and contact IT
Secondary search questions this article answers
- Google Workspace SMTP relay
- smtp-relay.gmail.com
- Google SMTP relay service
- route outgoing mail through Google
Authoritative references
Vendor interfaces and licensing can change. Verify current platform behavior against the primary documentation below before making high-impact production changes.
Need help applying this safely?
J3 Systems Group helps small businesses and nonprofits organize, secure, document, and improve Microsoft 365, Google Workspace, devices, access, and business technology operations.
Contact J3 Systems Group