Google Workspace SMTP Relay: Setup, Ports, Auth, and Safe Testing

If you are searching for , , or , the main risk is not getting the hostname wrong by one character. The real risk is choosing the wrong Google mail path for the workload, then discovering after rollout that devices, product notifications, or internal systems are sending through the wrong server with the wrong auth expectations.

The short answer is that Google Workspace SMTP relay usually means the relay service at , not the mailbox-authenticated Gmail SMTP server at .

That distinction matters. One path is for controlled relay through Google Workspace. The other is for mailbox-style authenticated sending. If you mix them up, troubleshooting becomes noisy and slow.

Quick answer

When teams mean , they usually mean:

Google documents the Workspace relay service on and notes that if you configure TLS on the on-premises server, use port . It also documents that non-TLS relay scenarios rely on IP-based auth rather than SMTP AUTH.

The point of this guide is to help you choose the right path, set it up cleanly, and validate it before mail flow changes hit real users.

What this guide covers

This page is for teams that need to answer questions like:

• should we use or ?
• which port should our device or service use?
• what changed after Google tightened old username/password-based patterns?
• how do we test relay changes without sending to customers?

If your issue is inbound routing instead of outbound relay, use Google Workspace MX records and MX lookup first.

Google Workspace SMTP relay vs Gmail SMTP server

This is the confusion that causes most misconfiguration.

Google also documents a restricted Gmail SMTP server path for apps or devices that only send to Gmail or Workspace users in the same organization. That is a narrower use case than full outbound relay.

If your team is sending product notifications, device mail, scanner mail, or app-originated transactional mail through Google Workspace, start by deciding whether you truly need relay or whether you are trying to make a mailbox-authenticated workflow behave like a relay.

When Google Workspace SMTP relay is the right choice

Google Workspace SMTP relay usually makes sense when:

• internal devices need to send mail through Google-managed infrastructure
• an app or service must relay outbound mail without acting like a normal mailbox client
• you want to control who can send and from which addresses
• you need Google Workspace to sit between your internal system and the public mail ecosystem

It is usually the wrong starting point when:

• you just need a user mailbox to send mail from a normal client or app
• the sending system cannot satisfy the modern auth and policy model you chose
• you are actually trying to solve deliverability or identity alignment problems that live elsewhere

The Google Workspace SMTP relay setup model

At a high level, the setup flow looks like this:

1. Decide who is allowed to send through the relay.
2. Decide how the sending systems will be trusted.
3. Point the sending system at .
4. Choose the correct port and TLS posture.
5. Validate sender identity and delivery behavior with controlled tests.

Inside Google Workspace, the real configuration work is in Gmail routing and relay policy, not only in the host and port fields on the device or application.

Allowed senders and auth choices

Google documents several sender-policy models for the SMTP relay service, including:

• only addresses in your registered domains
• only addresses in your verified domains and aliases
• any address

This is where teams often create silent risk.

If you allow broad sender behavior without clearly controlling which systems can use the relay, you make abuse, spoof-like behavior, or compliance drift much easier. If you lock the policy down too aggressively, legitimate devices or apps can suddenly fail with relay or sender authorization errors.

The right approach is usually:

• keep sender policy as narrow as possible
• segment production and non-production senders
• avoid using one broad relay policy for every workload
• document which domains and systems are allowed to send

Google also notes an important nuance: if you choose , you may need to authenticate as a Google Workspace user through SMTP AUTH or present a domain name in or . That is exactly the kind of implementation detail that breaks "it worked in staging" assumptions.

Modern auth reality for Google SMTP workflows

Google has tightened older auth patterns. Google Workspace accounts no longer support the old "less secure apps" username/password model for third-party apps and devices, and Google documents OAuth as the supported account-auth path where user authentication is required.

That does not mean Google Workspace relay stopped existing. It means you should stop assuming every device or application can keep using the old mailbox-style auth model forever.

The practical implication is simple:

• if your flow depends on user-account SMTP auth, confirm the client can support the current auth path
• if your flow is really relay, configure relay properly instead of forcing it through mailbox-authenticated SMTP

Port and TLS guidance

Google documents relay support on ports , , and . It specifically calls out port for TLS.

Treat that as an operational choice, not a random configuration detail:

• use TLS when the client supports it
• standardize the same relay port and security mode across the workload when possible
• do not let different devices drift into inconsistent port choices without documentation

When relay traffic spans multiple systems, inconsistency in port and TLS mode makes troubleshooting harder than it should be.

Common Google Workspace SMTP relay failures

Wrong server

The sending system is pointed at even though the workload was designed for Workspace relay on .

Wrong auth assumption

The app or device assumes plain mailbox username/password login will continue to work even though the supported auth path changed or the relay policy expects IP-based trust.

Relay denied

The relay policy is narrower than the actual sender address, domain, or source system.

Port and TLS mismatch

The device uses the wrong port, wrong encryption expectations, or a legacy mode that no longer matches the chosen relay model.

Messages send but still perform poorly

At that point, you may no longer have a relay problem. You may have a sender-auth, domain-alignment, or deliverability problem. Use SPF checker, DKIM checker, DMARC checker, and Email deliverability test to validate the full path.

Google Workspace SMTP relay troubleshooting workflow

Use this sequence when a relay rollout is failing:

1. Confirm whether the workload should use relay or mailbox-authenticated SMTP.
2. Verify the configured server is really .
3. Verify the selected port and TLS posture.
4. Review the Google Workspace relay policy for allowed senders.
5. Confirm the sending system matches the expected trust model.
6. Send one controlled message into a test inbox.
7. Inspect the resulting headers, sender identity, and auth results.

Do not debug this by only rotating credentials. That wastes time when the real problem is policy or route selection.

How to test Google Workspace SMTP relay safely

A safe release check looks like this:

1. validate connectivity with SMTP tester
2. send to a controlled inbox using Email Sandbox
3. inspect the live headers with Email header analyzer
4. confirm sender auth posture with DMARC, SPF, DKIM monitoring

This is better than sending to real users during the first live validation because it lets you confirm:

• the sender address is what you expected
• the headers reflect the correct relay path
• authentication and alignment still hold
• the message is not being silently rewritten in a risky way

Relay, DKIM, and DMARC belong in the same change review

Many teams treat Google Workspace SMTP relay as a transport-only change. That is too narrow.

A relay change can surface:

• weak SPF scope
• DKIM gaps for the sender domain
• DMARC alignment problems
• wrong return-path behavior
• non-production domains sending as production identities

That is why this page should usually be used together with:

• Google Workspace DKIM setup
• Google Workspace MX records
• What are DKIM records?
• SMTP relay guide

How MailSlurp helps

MailSlurp is especially useful when the Google Workspace relay change is part of a real release process with validation steps.

Use MailSlurp to:

• validate the SMTP path before rollout with SMTP tester
• capture the first real message safely in Email Sandbox
• inspect with Email header analyzer
• run post-change sender checks with DMARC, SPF, DKIM monitoring

That gives engineering, support, and deliverability owners the same evidence chain instead of three separate guesses.

FAQ

What is the Google Workspace SMTP relay server?

For Workspace relay service use cases, Google documents .

Is Google Workspace SMTP relay the same as Gmail SMTP?

No. is the Workspace relay service. is the Gmail SMTP server used for a different mailbox-authenticated sending model.

Which port should Google Workspace SMTP relay use?

Google documents relay support on ports , , and , and specifically calls out when configuring TLS.

Can old username/password app auth still be used for every Google SMTP workflow?

No. Google has retired the old "less secure apps" model for Google Workspace accounts. If your workflow depends on account-authenticated SMTP, confirm the client supports the current auth path that Google documents.

How should teams test Google Workspace SMTP relay changes?

Test the relay path in a controlled environment first, then inspect a real received message before using live recipients.

Final take

Google Workspace SMTP relay is straightforward when the team first chooses the correct Google mail path, then aligns relay policy, port, TLS, and sender rules to the real workload. The operational mistake is treating as one generic setting instead of a set of different Google-managed send paths with different trust models.