SMTP Relay Gmail Setup: smtp-relay.gmail.com, Three Ways

There are three different ways to authenticate to Google's relay, and most smtp relay gmail problems trace back to configuring one mode while the Admin console expects another. The server is always smtp-relay.gmail.com, the port is almost always 587, and everything that matters happens in one Admin console setting most people find after their first 550.

Set it up deliberately and the relay is the most boring infrastructure you own. Set it up by copying a random config block and you get intermittent 5.7.1s that appear only from some machines, only sometimes - the signature of an IP allowlist that matches your office but not your server.

Where the setting lives

Everything about the relay is controlled from one place: Admin console, then Apps, then Google Workspace, then Gmail, then Routing, under the SMTP relay service section. Each entry there is a rule with three decisions:

1. Allowed senders - registered Workspace users only, or any address in your domain.
2. Authentication - accept mail from registered IP addresses, require SMTP AUTH, or both.
3. Encryption - whether to require TLS.

Those three decisions produce the three working modes below. Changes propagate in minutes usually, but Google documents up to 24 hours - budget for that before declaring a test a failure.

Mode one: registered IP address

You list your server's public IPs in the relay setting; anything connecting from those IPs may relay. No username, no password in your application config.

• Best for: appliances, printers, legacy software that cannot store credentials safely, servers with stable egress IPs.
• Breaks when: your egress IP changes - a new NAT gateway, a cloud migration, a failover to a second region. The bounce is 550 5.7.1 Invalid credentials for relay, which sends everyone hunting for a password that was never the problem.
• One rule: register the IP the internet sees, not the machine's private address. If your server sits behind NAT, that is the NAT gateway's address.

Mode two: SMTP AUTH with an app password

Your application logs in with a real Workspace address and a 16-character app password generated for that account. Works from any IP.

• Best for: applications on dynamic infrastructure, containers, anything whose egress address you cannot promise.
• Requires: 2-step verification enabled on the sending account before Google will mint an app password at all, and an admin policy that has not disabled app passwords domain-wide.
• Breaks when: someone rotates or revokes the app password, or security policy turns app passwords off. The failure is 535 5.7.8, not 550 - a genuinely different error class, which is diagnostic gold.

Mode three: both at once

Require SMTP AUTH and restrict to registered IPs. Strictest posture: a leaked app password is useless from outside your network, and a compromised machine inside your network still needs credentials.

• Best for: regulated environments and anyone who has been burned once.
• The cost: two things can now break instead of one, and the bounce text does not tell you which check failed. Keep a note of both facts - registered IPs and which account owns the app password - next to the service that sends.

The settings block that works

For mode two, the config every library understands:

• Host: smtp-relay.gmail.com
• Port: 587 with STARTTLS (or 465 with TLS from the start; both work - pick 587 unless something forces otherwise)
• Username: the full Workspace address, sender@yourdomain.com
• Password: the 16-character app password, spaces optional
• From: an address in your domain - the relay refuses to impersonate domains you do not own

For mode one, the same block minus username and password - and make sure your library does not "helpfully" attempt AUTH with empty credentials, which some servers treat as a failed login rather than no login.

The five mistakes behind most relay tickets

1. Wrong host. smtp.gmail.com is a different service with a 2,000-recipient user limit and different auth rules. The relay is smtp-relay.gmail.com, nothing else.
2. Private IP registered. The console accepted 10.0.0.5 without complaint; the relay never saw a connection from it, because the internet saw your NAT address.
3. From-domain mismatch. The relay only carries mail from your own domains. A vendor tool defaulting its From to noreply@vendortool.com gets refused, correctly.
4. Port 25 upstream block. Cloud providers routinely block outbound 25. The relay listens on 587 and 465; use them and the block is irrelevant.
5. Testing from the office, deploying to the cloud. Mode one passes every desk test and fails in production, because only the office IP was registered. Register the production egress, or use mode two for anything that moves.

When smtp relay gmail is the right door

The relay is the right door when the mail belongs to your domain's own operations - alerts, receipts for a small product, internal tools - and your daily volume fits comfortably inside the per-user relay allowance. It is the wrong door for sustained bulk external sending: the allowance never grows, deliverability management is entirely yours, and Google's bulk-sender rules (authentication, one-click unsubscribe, spam-rate ceilings) apply to you with none of the tooling a sending platform provides. If the send is a campaign rather than a byproduct, put it on infrastructure built for campaigns.

A last sanity habit: after any relay change, send one test message and read its full headers end to end. The first Received line proves which door the mail actually used, and thirty seconds of reading beats an afternoon of guessing which mode you are really in.

Frequently asked questions

What is the difference between smtp.gmail.com and smtp-relay.gmail.com?

smtp.gmail.com is the personal-mailbox door: it authenticates one user and enforces the 2,000-recipient daily user limit. smtp-relay.gmail.com is the Workspace relay service with its own Admin console configuration, IP-based or AUTH-based access, and the larger 10,000-per-user relay allowance.

Does Gmail SMTP relay require an app password?

Only in the SMTP AUTH modes. If your relay setting accepts registered IP addresses, no credentials are needed at all - the connection's source IP is the authentication. If you require SMTP AUTH, the sending account needs 2-step verification enabled and an app password generated for it.

Which port should I use for smtp-relay.gmail.com?

Use 587 with STARTTLS as the default; 465 with implicit TLS also works. Port 25 is accepted by Google but so commonly blocked by cloud providers on the outbound side that building on it invites outages.

Why does the relay reject my From address?

The relay only sends mail for domains your Workspace organization owns. If the envelope or header From is an address outside your verified domains, Google refuses the message - fix the sending application's From address rather than the relay settings.