Question: How do I configure SMTP Relay in Google Workspace?
Explanation: SMTP Relay is a Google Workspace service that allows servers, applications and devices to send email through Google's mail servers, without having to sign in with a username and password per user. The sender is authenticated based on IP address and TLS encryption, optionally combined with mailbox authentication. This makes SMTP Relay the recommended solution for situations where you want to send mail from an application, web server, CRM, ERP, multifunctional device or monitoring system on behalf of your domain.
Unlike the standard address smtp.gmail.com (which authenticates a single user per connection and is limited to 2,000 messages per day), smtp-relay.gmail.com is intended for organisation-wide sending up to 10,000 messages per user per day, and at the organisation level up to several million per 24 hours.
The difference between smtp.gmail.com and smtp-relay.gmail.com
- smtp.gmail.com is intended for a single user sending from a client or device. Authentication is done via OAuth or app password at the user level. Limit is 2,000 messages per day. Suitable for one email client or one small device.
- smtp-relay.gmail.com is intended for servers and applications that are managed centrally. Authentication can be via IP address, mailbox credentials, or both. Limit is 10,000 messages per user per day, plus higher organisation limits. Suitable for printers, scanners, websites, ERP systems and transactional mail.
Required since May 2025: modern TLS ciphers
Google ended support for the 3DES encryption cipher for incoming SMTP connections on 30 May 2025. Legacy systems that still use 3DES can no longer deliver mail to Gmail accounts since that date, including via SMTP Relay. Make sure the sending system supports a modern TLS cipher (TLS 1.2 or higher with AES-GCM or ChaCha20-Poly1305).
When do you choose SMTP Relay?
Solution:
Setting up SMTP Relay consists of three main stages: configuring it in the Google Admin Console, connecting the device or application to the SMTP Relay settings, and getting SPF, DKIM and DMARC aligned so that messages actually arrive.
1
Open the SMTP Relay setting in the Admin Console
Go to admin.google.com and sign in with an account that has the Gmail Settings administrator role. A regular user administrator is not sufficient.
Navigate to:
Scroll down until you see the SMTP relay service section. Hover over the setting and click Configure. Does a rule already exist? Click Edit or Add another when you want to create a second rule for a different device or application.
The SMTP Relay setting can only be added, edited or deleted at the top organisational level. At child Organizational Units you can view the setting but not change it. Plan ahead which rules you need rather than trying to configure per OU.
2
Give the rule a recognisable name
Enter a clear name for the rule, for example Printer office ground floor, WordPress contact form or Exchange Hub Transport. When you have multiple rules this name helps you quickly identify the right one during troubleshooting.
3
Set the allowed senders
Under Allowed senders choose from which type of address sending is allowed:
- Only registered Gmail or Google Workspace users in my domains. Sensible for most internal use cases. Prevents a compromised device from sending mail on behalf of any address.
- Only addresses in my domains. Slightly broader, also allows addresses that aren't registered users (such as noreply@yourdomain.com).
- Any address (even addresses outside your domains). Only use this in rare cases. This opens the relay to send on behalf of external domains and is almost always discouraged.
For printers and scanners you typically choose Only addresses in my domains combined with a dedicated sending address like scanner@yourdomain.com. For servers sending transactional mail (WordPress, ERP) Only registered users is the safest choice.
4
Configure authentication
Under Authentication you choose how the device or server identifies itself to Google. You have three options, which can also be combined:
- Only accept mail from the specified IP addresses. Enter the public IP address of the server, printer or application here. This is the most common option for on-premise devices with a fixed IP address.
- Require SMTP Authentication. The device must log in with the username and an app password (or OAuth for modern servers). Use this when the IP address is unpredictable, for example for cloud servers with rotating IPs.
- Both options. A combination of IP restriction and authentication, for maximum security.
IP addresses for cloud and SaaS platforms
Sending from a cloud provider like AWS, Azure, Google Cloud or a hosted WordPress environment? Request the range of outbound IP addresses from that provider. For many WordPress hosts, such as SiteGround, Kinsta and WP Engine, you can find these in their documentation. Add all relevant IPs, because under load a request can leave from any IP within the range.
5
Require TLS encryption
Under Encryption tick the option Require TLS encryption. This ensures traffic between your device and Google is always encrypted and rejects plain-text connections.
Ticking this is effectively required since 2025. Google's bulk sender requirements mandate TLS encryption for all email traffic, and without this checkbox an older device might accidentally send in plain text, leading to delivery problems and compliance issues.
Finally click Save. Changes are usually active within minutes, but Google officially lists up to 24 hours as the margin.
6
Configure the sending device or application
Use the following values on the server, device or in the application:
| Setting | Value |
|---|---|
| SMTP server | smtp-relay.gmail.com |
| Port | 587 (STARTTLS, recommended) or 465 (SSL) or 25 (only for on-premise mail servers behind a NAT) |
| Encryption | TLS / STARTTLS required |
| Authentication | None (with IP authentication), or username + app password (with SMTP authentication) |
| From address | An address within the scope chosen in step 3 |
Which port do you choose?
- Port 587 with STARTTLS is the modern standard and works from virtually every device and network. First choice.
- Port 465 with SSL works on older devices that don't support STARTTLS.
- Port 25 is only used from an on-premise mail server behind a NAT firewall, and only when port 25 outbound isn't blocked by your provider (many ISPs block outbound port 25 to combat spam).
7
Update your SPF record
Google signs outgoing mail via SMTP Relay with DKIM, but for SPF it remains the sending domain's responsibility to include Google in its SPF record.
Add this to your SPF record:
include:_spf.google.com
A typical combination looks like:
v=spf1 include:_spf.google.com include:spf.brevo.com ~all
Do you also have your own web servers that send directly (without SMTP Relay)? Add their IPs via ip4: or ip6:. Make sure not to exceed the maximum of 10 DNS lookups.
8
Verify DKIM is enabled
For SMTP Relay it's crucial that DKIM is active on your domain. Google signs every message sent via Relay with the DKIM signature of the envelope sender domain, but this only works when that domain has DKIM enabled in the Google Admin Console.
Check this:
The status must be Authenticating email for the correct domain. If it's set to Not started, virtually every recipient will mark Relay-sent mail as spam or reject it.
Since February 2024 (Google bulk sender requirements) and further tightened in 2026, DKIM is effectively required. Messages without a valid DKIM signature risk being rejected with the error code 5.7.26 (authentication required).
9
Test the relay
Test the connection from the device or server. Send a test message to at least three different recipients:
- A Gmail account, to check the DKIM, SPF and DMARC headers via Show original.
- An Outlook or Microsoft 365 account, to see how Microsoft scores your domain.
- Another mail platform like Yahoo or a business provider, to discover differences in spam filtering.
In the message headers of the Gmail message, under
Authentication-ResultsFor deeper diagnostics use the Admin Console:
This lets you track per message how it was processed by Google's system, including any error codes from the relay service.
Platform-specific configurations
Multifunctional devices (printers and scanners)
- Canon, HP, Lexmark: configure the SMTP server as smtp-relay.gmail.com, port 587 with TLS, no authentication when you added the IP address in step 4. Enter a from address like scanner-1@yourdomain.com.
- Ricoh, Savin, Lanier: these brands have limited OAuth support, so SMTP Relay without authentication is by far the best choice here.
- Xerox: doesn't support OAuth at the time of writing, use SMTP Relay with IP authentication or an app password on a dedicated sending account.
- Brother, Konica Minolta, Kyocera, Sharp, Toshiba: set the SMTP host to smtp-relay.gmail.com, port 587, enable TLS. For devices that insist on a username, use a dedicated account with an app password.
WordPress (with WP Mail SMTP, FluentSMTP or similar plugin)
- Hosted WordPress: request the IP address or IP range from your hosting provider and add it to the SMTP Relay allowed IPs.
- Plugin settings: SMTP host smtp-relay.gmail.com, port 587, encryption TLS, authentication on, username your Workspace address, password an app password.
- Set the From address in the plugin to match the signed-in Workspace account, otherwise you get a mismatch between From and envelope sender and possibly DMARC failures.
Microsoft Exchange (on-premise) as smart host
- Create a new Send Connector on a Hub Transport server.
- Address: smtp-relay.gmail.com on port 587.
- Configure Smart Host Authentication to None when using IP authentication, or specify the username and the app password.
- Require TLS via
.Set-SendConnector -RequireTLS $true - Don't change the default timeout settings in Exchange. Google's relay service is tuned for the default values of Exchange 2016/2019/SE.
Linux server with Postfix
Configure in
/etc/postfix/main.cf- relayhost set to
.[smtp-relay.gmail.com]:587 - smtp_use_tls set to
.yes - smtp_tls_security_level set to
to require TLS.encrypt
smtp_sasl_password_mapsLimits and sender requirements as of 2026
Bulk sender requirements and Postmaster Tools v2
Since February 2024 Google and Yahoo have enforced strict rules for senders, which have been further tightened in 2026:
- Does your organisation send fewer than 5,000 messages per day to Gmail accounts? Then you must have at least SPF or DKIM correctly configured. In practice it's strongly recommended to configure both.
- Does your organisation send 5,000 or more messages per day to Gmail accounts? Then SPF, DKIM and DMARC are all three required. Spam rate must stay below 0.3% (ideally below 0.1%) and TLS encryption is enforced.
- Since October 2025 Postmaster Tools v2 shows a binary Pass or Fail compliance status. A Fail status means your emails are at risk of rejection, check this tab weekly after setting up SMTP Relay.
Limits for SMTP Relay:
- Per user: 10,000 recipients per 24 hours via smtp-relay.gmail.com.
- Per organisation: up to 4.6 million recipients per 24 hours, provided connection caching is efficient.
- Messages exceeding the limit are deferred or rejected with a 421 or 550 error.
Common configuration mistakes and how to avoid them
- Using the wrong server. People often point smtp.gmail.com at an application where smtp-relay.gmail.com belongs, or vice versa. Does the device work per user account? Then smtp.gmail.com. Does it send centrally on behalf of the organisation? Then smtp-relay.gmail.com.
- Missing or changed IP address. When a server gets a dynamic IP address (for example after a cloud relocation) IP authentication fails. Update the IP list in the Admin Console immediately or switch to SMTP authentication.
- TLS not required. Without ticking Require TLS encryption an older device can send without TLS, which since 2025 leads to immediate rejection by Gmail.
- From address outside the allowed scope. When you chose Only registered users in step 3 but the device sends from noreply@yourdomain.com, sending fails because that address isn't a registered user.
- SPF not updated after rollout. Mail is rejected or lands in spam because the receiving system sees the Google server isn't listed in your SPF. This is the most common cause of delivery problems with new relay configurations.
- DKIM not enabled on the sending domain. Without DKIM, DMARC alignment fails, which since 2024 leads to a 5.7.26 error at Gmail.
- Too many senders on one rule. Better to create multiple SMTP Relay rules with specific scopes than one broad rule with many allowed IPs and all addresses open. This makes troubleshooting and revoking during incidents far easier.
