Two different services
The distinction matters because the names are similar and the capabilities are not.
Google's two SMTP endpoints
easy to conflate, different capabilitiesThe SMTP relay service, at smtp-relay.gmail.com, is a Workspace administrative feature. It accepts mail from configured senders, can authenticate by IP address rather than credentials, and can send as any address in the organisation's domains. Google documents it under SMTP relay service.
Ordinary Gmail submission, at smtp.gmail.com, authenticates as one mailbox and sends as that user. It is available to personal accounts and Workspace accounts alike.
Choosing between them comes down to whether the sender is a person or a system. A printer, a monitoring service or an internal application belongs on the relay. A mail client belongs on standard submission.
The Google question is not hypothetical for us. George, our CEO, pulled all 443 brands (439 users) from our production database and scanned the 252 with a resolvable website, 233 of them fully, homepage, pricing and checkout probe, and DNS MX and SPF. 78% of our users live in a Google mailbox, counting 52% plain gmail.com signups and 110 custom domains on Workspace MX, and Microsoft 365 is around 5%. Most senders deciding between these two endpoints are already inside Google infrastructure.
Server settings
The relay accepts connections on port 587 with STARTTLS, port 465 with implicit TLS, or port 25. Of those, 587 is the recommended configuration.
Port 25 is available on this service and is not a good default. Most networks and hosting providers block outbound 25, and it is the option to use only when a legacy device supports nothing else.
Authentication is either SMTP credentials or a registered static IP address. The IP-based option exists for devices that cannot hold credentials, and it requires the address to be static and not shared with anyone outside the organisation.
Configuration
Setup happens in the Google Admin console rather than on the device. Under Apps, Google Workspace, Gmail, Routing, the SMTP relay service entry defines who may send through it.
Three settings define the policy. Allowed senders determines whether mail may come only from registered Workspace users or from any address in the organisation's domains. Authentication selects credentials, IP allowlisting, or both. TLS encryption can be required, which rejects any connection that does not negotiate it.
Configure the device only after the Admin console entry exists. A device pointed at the relay before the policy is in place is rejected in a way that reads as a credential problem.
Limits and suitability
The relay carries per-user and per-organisation sending caps published by Google, and they are sized for internal business mail rather than for bulk sending.
Exceeding them results in temporary blocking rather than a clear error, which presents as intermittent failures that are difficult to attribute to a quota.
Mail sent through the relay is still subject to Google's requirements as a receiver when it reaches Gmail addresses. Bulk senders must authenticate with SPF, DKIM and DMARC, keep the user-reported spam rate below 0.10% and never reach 0.30%, and support one-click unsubscribe, per the sender guidelines.
George's Email Marketing Bible, built from 908 sources and the six billion emails SmartrMail sent, adds the reputation detail Google's own page does not. For Gmail, domain reputation matters more than IP reputation, and that memory runs about 120 days. A dedicated IP only earns its keep past one million emails a month, which is a scale no Workspace relay sender should be at anyway.
For application mail at scale the relay is the wrong tool. It is designed to let an organisation's own devices send through infrastructure it already pays for, not to provide delivery events, bounce classification or suppression handling, none of which it reports back.