# Constrain Google Workspace SMTP relay for device alerts

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

- Canonical URL: https://update.dsesecurity.com/updates/google-workspace-device-smtp-relay-boundaries/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T00:43:30+00:00
- Modified: 2026-10-15T00:44:33+00:00
- Last reviewed by DSE: 2026-10-14
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

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

## Potentially affected

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.

## Article

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](https://knowledge.workspace.google.com/admin/gmail/advanced/route-outgoing-smtp-relay-messages-through-google?hl=en).

## 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](https://knowledge.workspace.google.com/admin/gmail/advanced/route-outgoing-smtp-relay-messages-through-google?hl=en). Reviewed October 14, 2026.

## Primary reference

- Name: Google Workspace Admin Help — Route outgoing SMTP relay messages through Google
- Authority: knowledge.workspace.google.com
- URL: https://knowledge.workspace.google.com/admin/gmail/advanced/route-outgoing-smtp-relay-messages-through-google?hl=en
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Constrain Google Workspace SMTP relay for device alerts,” DSE Security, https://update.dsesecurity.com/updates/google-workspace-device-smtp-relay-boundaries/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.