Constrain Google Workspace SMTP relay for device alerts

Scope senders, public egress addresses, and TLS requirements before routing device notifications through Google Workspace.

Source facts

Google’s SMTP relay documentation offers separate controls for allowed senders, authentication, and TLS. Administrators can restrict sending to specified public IP addresses and can require TLS, rejecting connections that do not use it. Sender choices include registered users or addresses in the organization’s domains; Google does not recommend allowing any address indiscriminately. The relevant IP range is the sending system’s public egress, not simply its private LAN address.

Source: Google Workspace Admin Help — Route outgoing SMTP relay messages through Google.

Applicability

Use this for an approved Google Workspace relay design for on-premises devices or applications. Verify account eligibility, the selected authentication method, and each device’s supported TLS behavior.

DSE recommendation

DSE recommends listing the devices, approved sender addresses, public egress paths, relay owner, and alert recipients before configuration. Use the smallest justified source range and an allowed-sender policy that matches the actual workflow. Plan for an ISP or firewall change that alters egress addressing. Keep notification tests separate from production alarms so a troubleshooting exercise cannot be mistaken for a real incident. Record how delivery failures reach the administrator responsible for the device.

Verification

Send a labeled test notification and confirm receipt and relay logs. Under controlled conditions, verify rejection from an unauthorized source or sender and validate the required TLS behavior. Retain sanitized delivery evidence; a successful test does not guarantee future delivery of every alert.

Official reference

Google Workspace Admin Help — Route outgoing SMTP relay messages through Google. Reviewed October 14, 2026.