What should a product team evaluate when choosing Google SMTP relay service?

Start with workload and administrative fit

Google's SMTP relay service is a Google Workspace administrative route for applications, devices, and mail servers that send through smtp-relay.gmail.com. Evaluate it as part of the organization's Workspace and mail-security boundary, not as a generic anonymous SMTP endpoint. Identify the Workspace super-admin owner, domains in the account, source systems, public egress IPs, sender addresses, message classes, peak and daily recipient volume, attachment profile, and incident contact. Decide whether the workload is transactional, internal operational, user-composed, bulk subscribed, or device-generated. Keep those classes separate because authorization, consent, suppression, audit, and reputation needs differ. Confirm lower environments cannot use production routes or customer addresses. A relay can transport an authorized message; it does not decide whether the business event is legitimate, whether a recipient consented, or whether downstream application state should advance.

Compare IP authorization with SMTP authentication

Google's current setup permits administrators to restrict relay intake to specified public IP addresses, require SMTP authentication over TLS, or combine policy choices according to the documented setting. Stable IP authorization can suit controlled data centers or fixed egress gateways, but it becomes brittle behind changing cloud NAT, multiple regions, failover services, or third-party networks. SMTP authentication identifies a Workspace account and sending domain but introduces credential lifecycle, user status, multi-factor and policy interactions, and a hard requirement for TLS. Never use one broad credential across tenants or unrelated applications. For each option, document who can add an IP or account, how changes are reviewed, how compromise is detected, how access is revoked, and what failover does. Keep allowed IP ranges as small as practical and verify the public egress address from the actual runtime rather than copying an internal address.

Define allowed senders and domain identity

The Admin console relay setting controls which senders are allowed. Google documents options tied to registered Apps users and addresses in owned domains, as well as a broader any-address option that increases abuse exposure. Choose the narrowest option the workload can satisfy. Inventory the SMTP envelope sender independently from the visible From and Reply-To fields. Google notes that when a sender is outside account domains, SMTP AUTH or a domain presented in HELO or EHLO can affect how the envelope sender is identified or rewritten. Do not rely on rewriting as a substitute for an owned sender model. Require an approved mapping from application, tenant, message class, envelope sender, visible From domain, and return path. Block arbitrary user-provided headers, newline injection, and cross-tenant From addresses before connecting to Google. Test bounce routing and out-of-office messages, including an empty envelope sender, without weakening the entire setting.

Require transport security deliberately

Google's current relay guide directs TLS-enabled on-premise systems to smtp-relay.gmail.com on port 587 and explains that SMTP authentication requires TLS. The Admin setting can also require TLS for connections from the sending server. Enable required TLS for production unless a documented legacy constraint has a time-bounded exception. Validate the server name, certificate chain, supported protocol and cipher policy, STARTTLS negotiation, and failure behavior. The client must fail closed if required TLS cannot be established; silently falling back to plaintext defeats the policy. Protect SMTP credentials in a managed secret store and keep them out of command lines, URLs, source, logs, analytics, crash reports, and tickets. Transport TLS protects the hop to Google, not the entire message lifecycle or mailbox. Sensitive content may need application-level controls, data minimization, retention, and separate end-to-end encryption decisions.

Model current quotas before choosing the relay

Google's current SMTP relay setup documentation states that each user can send up to 10,000 messages and to no more than 10,000 unique recipients in a 24-hour period, with potentially lower trial limits. It also documents a 100-recipient limit per SMTP transaction and additional customer, peak, and daily controls. Treat these as current documented ceilings, not a capacity target or permanent contract. Recheck the official page for the account and workload before launch. Calculate recipients, not only messages, across To, Cc, Bcc, retries, and fan-out. Place application-level rate, concurrency, queue-age, and tenant fairness controls below Google limits. Alert on acceleration and remaining headroom. Do not respond to a limit by sharding traffic across unauthorized accounts, rotating envelope senders, or opening uncontrolled connections. A workload that regularly approaches a shared Workspace boundary may need a purpose-built transport evaluation.

Build a durable submission workflow

Put the SMTP client behind an authorized server worker or queue. Persist one outbound job with a stable business-event key, tenant, message class, template revision, approved sender and recipients, consent or necessity basis, suppression decision, and attempt history. Claim that job once, render and validate content, then connect to the configured Google endpoint. Bound recipients per transaction and message size according to current limits and product policy. Record the full SMTP reply, enhanced status code, remote host, timestamp, and attempt identifier without logging credentials or unnecessary content. If the relay accepts the DATA transaction, mark only the provider or relay acceptance stage. If the client times out after sending data but before observing the final reply, keep the attempt unknown and reconcile it before resending. SMTP does not provide an application idempotency key, so duplicate control belongs to the product queue and event model.

Classify relay errors instead of retrying everything

Google's SMTP relay error page documents distinct conditions including mail relay denied, invalid relay credentials or domain identification, daily limit exceeded, temporary peak-limit deferral, and too many recipients in one transaction. Capture the exact reply and map it to a narrow internal class. Fix configuration, sender-domain, credential, IP, and per-transaction recipient errors before replay. Pause or reschedule work after daily-limit exhaustion. Retry eligible temporary peak or transport errors with exponential backoff, jitter, attempt caps, and queue-age limits. Never retry a permanent response indefinitely. If an error names an unregistered IP, confirm the runtime's real public egress and the correct Workspace setting rather than widening the allowlist. Preserve privacy-minimized aggregate counts by source system, configuration revision, sender domain, status class, and time. Alert on novel replies and authentication spikes, because they may indicate policy drift, credential revocation, NAT change, or abuse.

Authenticate the sender beyond relay access

Permission to use Google's relay is not the same as recipient-facing sender authentication. Publish an SPF policy that authorizes the actual sending path for the envelope identity, configure DKIM signing with an organizationally controlled and DMARC-aligned domain, and publish a reviewed DMARC policy for the visible From domain. Verify the raw received message from controlled external mailboxes. Record SPF result and domain, DKIM result, d= domain and selector, visible From domain, alignment, and DMARC result. A technically valid provider or Workspace signature can remain unaligned with a custom From domain. Forwarding can also change SPF evidence. Do not add a second SPF record or weaken DMARC across the organization just to make one test pass. Coordinate DNS and mail administrators, preserve prior records, test authoritative and recursive answers, and roll out one identity change at a time.

Demand observability and a tested exit path

Use Google Admin email log search and relay-side logs where available, but keep the product-owned outbound ledger as the system of decision. Monitor queue age, acceptance, temporary and permanent responses, limit usage, bounce and complaint signals, authentication, and latency by message class and sender domain. Restrict access and avoid full addresses or content in routine metrics. Test source IP changes, credential rotation, TLS failure, Admin setting disablement, user suspension, limit exhaustion, recipient fan-out, DNS changes, and provider outage. Define a rollback that can pause the affected cohort without dropping durable jobs. For migration, isolate provider-specific SMTP fields in one adapter and preserve business event keys, suppression state, sender authorization, and attempt history. A second relay must not become an automatic bypass for permanent policy or recipient rejections. Compatibility requires field-level and error-level tests, not merely changing a hostname.

How SendHQ fits

SendHQ is a workspace-scoped email API for expected product communication, with verified-domain sending, inbound email, hosted templates, delivery events, suppressions, and a web dashboard. Compare it with Google Workspace SMTP relay through its current documentation and controlled tests for account and tenant boundaries, credentials and rotation, allowed-sender enforcement, envelope and visible identities, TLS failure, recipient limits, temporary and permanent replies, ambiguous outcomes, suppressions, event readback, and migration.

Frequently asked questions

Sources

• Route outgoing SMTP relay messages through Google — Google Workspace
• SMTP relay service error messages — Google Workspace
• RFC 3207: SMTP Service Extension for Secure SMTP over TLS — RFC Editor
• RFC 7208: Sender Policy Framework — RFC Editor
• RFC 6376: DomainKeys Identified Mail Signatures — RFC Editor
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance — RFC Editor
• RFC 5321: Simple Mail Transfer Protocol — RFC Editor