Gmail SMTP Relay: Setup, Settings, and Troubleshooting

SMTP relay Gmail usually means one of two very different things: sending through a single Gmail mailbox with smtp.gmail.com, or routing app and device mail through Google Workspace’s managed relay at smtp-relay.gmail.com. Choosing the wrong one is the main reason printers, websites, CRMs, and server alerts fail with authentication or relay-denied errors.

This guide focuses on the Google Workspace SMTP relay service: the right option when a business application, copier, monitoring system, or on-premises mail server needs to send mail through Google without storing an individual employee’s mailbox password. It also explains when ordinary Gmail SMTP is the better fit, exactly what to enter in your sending application, how to secure the configuration, and how to test it before real customer messages depend on it.

What “SMTP relay Gmail” actually means

SMTP is the protocol applications use to hand an outbound message to a mail server. A relay accepts that message and delivers it onward to the recipient’s mail system. Google offers more than one SMTP route, and their similarly named hosts cause a lot of bad configurations.

For a Google Workspace organization, the managed relay host is:

smtp-relay.gmail.com

Google documents this service for devices and applications such as printers, scanners, and organizational apps. It can authenticate sending systems by their public IP address, then relay mail to internal or external recipients. Google recommends the SMTP relay option for this type of device and app workload. (support.google.com)

The mailbox-submission host is different:

smtp.gmail.com

That host is for an application or mail client sending as a particular Google account. It normally needs modern Google authentication, such as OAuth, or—in limited legacy-device scenarios where Google permits it—an app password rather than the account’s ordinary password. Google Account app passwords are 16-digit passcodes and require 2-Step Verification. (support.google.com)

The three Google SMTP paths compared

Google’s restricted Gmail SMTP option uses aspmx.l.google.com on port 25 and is intentionally limited to delivery within the organization. Do not select it for a website contact form, invoice system, or scanner that must email customers. (support.google.com)

Decide whether Gmail SMTP relay is the right tool

Use Google Workspace SMTP relay when all or most of the following are true:

• You administer a Google Workspace domain, not only a personal @gmail.com account.
• The sender is a shared device or service rather than a human mailbox.
• Your system has a stable public egress IP address that you can allowlist.
• You need messages to reach recipients outside your organization.
• You want Google Workspace controls, logs, filtering, and domain authentication to apply to the mail flow.

Typical examples include a multifunction copier sending scan-to-email, an ERP system sending invoices, an uptime monitor sending alerts, or an on-premises application server delivering account notices.

Use smtp.gmail.com instead when a desktop email application, a CRM plug-in, or a small internal utility genuinely needs to send as one specific mailbox. Prefer its built-in Sign in with Google or OAuth flow whenever the software supports it. Google states that Workspace no longer supports third-party apps or devices that ask for the Google username and password directly; applications should use OAuth. (support.google.com)

Do not treat either Google SMTP option as a full email-delivery platform for a product that sends large volumes of password resets, newsletters, receipts, or marketing automation. Shared mailbox credentials, daily limits, limited event webhooks, and lack of purpose-built suppression handling make that architecture fragile. A transactional email provider or an email API is usually easier to operate for a customer-facing application; compare the integration requirements with the available email API reference and setup guides before making Gmail part of your production sending stack.

Gmail SMTP relay settings: the quick reference

For a standard Google Workspace relay implementation, start with these values:

Google lists ports 25, 465, and 587 for the SMTP relay service. The correct TLS mode depends on the sending product: port 465 generally expects TLS from connection start, while port 587 generally uses STARTTLS after the initial SMTP connection. Do not enable both “SSL” and “STARTTLS” in software that treats them as mutually exclusive modes. (support.google.com)

TLS encrypts the connection between your application and Google’s SMTP endpoint. Google describes TLS as the current, more secure successor to SSL terminology, although software interfaces often continue to label the setting “SSL.” (support.google.com)

A note about port 25

Port 25 is valid for the relay service, but it is often blocked or throttled by cloud providers and internet service providers because it is traditionally used for server-to-server mail delivery. For a new application that supports STARTTLS, port 587 is usually the most practical configuration. Use port 25 only when the device and network design require it and you have tested the actual outbound path.

The public IP address is the important one

If your application runs on 10.0.2.15, that is not the address Google uses for IP authorization. Google sees the public IP used by your firewall, NAT gateway, VPN egress point, or cloud egress gateway. Before creating the relay rule, identify that public address from the same network path the application will use.

This detail matters especially for cloud workloads. A virtual machine can have a static private address while its outbound public address changes after a restart, instance replacement, or network redesign. If the public address changes, the relay policy no longer matches and mail can fail immediately.

Configure SMTP relay in Google Workspace

You need a Google Workspace administrator account with access to Gmail settings. The exact Admin console labels can evolve, but the relay configuration is managed in the Gmail routing/settings area rather than inside an individual user’s Gmail inbox.

1. Inventory the system before allowing it to relay

Collect these details first:

1. Application or device name: for example, warehouse-scanner-03 or billing-app-prod.
2. Public outbound IP address: the address Google will receive connections from.
3. Sender domains and From addresses: for example, alerts@example.com and invoices@example.com.
4. Recipient scope: internal only, external only, or both.
5. TLS capability: whether the sender supports STARTTLS on 587 or TLS-on-connect on 465.
6. Expected volume and message type: a scanner sending a few files per day is very different from a web app sending thousands of receipts.

A short inventory prevents a common failure mode: creating a broad relay rule for an unknown group of systems, then discovering later that a compromised server or misconfigured app can send through it.

2. Create a narrowly scoped SMTP relay service rule

In the Google Admin console, open the Gmail routing/settings section and add an SMTP relay service configuration. Give it an operational name that identifies both its source and purpose, such as:

prod-billing-app-us-east-egress

For the sender policy, choose the narrowest setting that meets the application’s needs. If the app sends as addresses in your Workspace domain, limit it to those organizational addresses rather than allowing arbitrary external sender identities. Then restrict connections to the specific public IP address or addresses used by the application.

Google’s documentation describes SMTP relay as IP-authenticated for apps and devices and identifies it as the recommended option for these workloads. A relay rule that accepts mail from any network without reliable sender controls defeats the security benefit of the service. (support.google.com)

3. Require TLS when your sender supports it

Enable the option to require TLS encryption in the relay policy if the device or application supports it. Then configure the sender to use a compatible port and TLS mode—most often port 587 with STARTTLS.

Do not turn off TLS simply to make an old device work without first checking whether its firmware supports an update or whether it can relay through a local, secured SMTP gateway. Plain SMTP can expose the message, recipient addresses, and potentially authentication data while traffic crosses a network.

4. Save and allow for configuration propagation

Save the relay setting, then wait for the Admin console change to become active before declaring the setup broken. Avoid changing multiple variables during that window. A clean test has one sender, one known source IP, one From address, one recipient, and one TLS mode.

5. Configure the sending system

Enter the following in the application, printer, or server SMTP settings:

SMTP server: smtp-relay.gmail.com
Port: 587
Security: STARTTLS / TLS
SMTP authentication: disabled if your Workspace relay rule uses IP authorization
From address: alerts@example.com

Whether the application should enable SMTP authentication is determined by the relay policy you created. Do not assume a username and password will work simply because the device presents those fields. In an IP-authorized relay design, the sender’s network identity is the authorization mechanism.

A worked example: relay mail from a Python application

Assume a company owns example.com, uses Google Workspace, and has an internal billing application on a server whose fixed outbound public IP is 203.0.113.42. The application must send invoices from billing@example.com to external customers.

The Workspace administrator creates a relay setting with these controls:

• Allowed sender addresses: addresses in example.com.
• Allowed connection source: 203.0.113.42.
• TLS: required.
• Relay host: Google’s smtp-relay.gmail.com.

The application uses port 587 and STARTTLS. This Python example uses the standard-library smtplib module, so it does not require a third-party SDK:

import os
import smtplib
import ssl
from email.message import EmailMessage

message = EmailMessage()
message["From"] = "Billing <billing@example.com>"
message["To"] = "test-recipient@example.net"
message["Subject"] = "SMTP relay test: invoice delivery"
message.set_content(
    "This is a controlled test sent through Google Workspace SMTP relay."
)

context = ssl.create_default_context()

with smtplib.SMTP("smtp-relay.gmail.com", 587, timeout=30) as smtp:
    smtp.ehlo()
    smtp.starttls(context=context)
    smtp.ehlo()
    smtp.send_message(message)

print("Message accepted by the relay")

This example intentionally contains no Gmail username, password, or app password because the example relay authorizes the source by IP. If your organization chooses a different relay authentication model, follow the policy requirements and avoid embedding long-lived secrets directly in source code.

A successful send_message() call means Google accepted the message from the application. It does not guarantee that the recipient has received it in the inbox. The next section explains how to verify the complete path.

Test SMTP relay before sending production mail

A test should establish four separate facts: the sender can connect, TLS is active, Google accepted the message, and the recipient system accepted or delivered it.

Use a dedicated test message

Send a message to an inbox you control with a recognizable subject, such as:

SMTP relay test — billing-app-prod — 2026-04-19T14:30Z

Include a harmless unique token in the message body, such as relay-test-7f91c2. That makes it easy to search logs and inboxes without confusing the test with a real invoice or alert.

Check the application-side result

Capture the SMTP conversation or application logs. You want to see a successful final response after the DATA command—typically a 250-class SMTP response. If the tool only says “queued,” find out whether that means it handed the message to Google or merely placed it in the application’s own retry queue.

Check message headers at the destination

Open the delivered test email and inspect the full headers. Look for a chain of Received: lines showing that the message passed through Google infrastructure. Also inspect the authentication results, often displayed as an Authentication-Results: header.

For a message sent from your domain, the useful results are typically:

spf=pass
dkim=pass
dmarc=pass

A message can still arrive with one of these failing, but failure is a warning that deliverability and anti-spoofing controls are incomplete. Google requires all senders to personal Gmail accounts to use SPF or DKIM, and requires bulk senders to use SPF, DKIM, and DMARC. (support.google.com)

Check the Workspace mail investigation or logs

Use the email log/search facilities available in the Admin console to search by recipient, sender, subject, or the unique test token. This is particularly helpful when the SMTP client says the relay accepted the message but the recipient reports no delivery.

If Google accepted the message but it was later rejected by the recipient’s server, the destination response and status code are more useful than repeatedly changing the SMTP hostname or port. Treat those as separate layers: submission, relay acceptance, destination acceptance, and inbox placement.

DNS authentication: make the relay’s mail believable

SMTP relay solves the submission problem: how your app hands a message to Google. It does not automatically solve the domain identity problem: why recipient systems should believe mail from billing@example.com is authorized.

SPF record

SPF is a DNS TXT record listing services allowed to send for a domain. For an organization that sends mail only through Google Workspace, Google provides this example:

v=spf1 include:_spf.google.com ~all

Publish only one SPF TXT record per domain. If you already have one because you use another sender—such as a help desk, ecommerce platform, or transactional email provider—merge its authorized mechanism into the existing record rather than adding a second v=spf1 record. Google specifically advises identifying every sender, including web servers, outbound gateways, and third-party services, before determining the SPF record. (support.google.com)

DKIM signing

Enable DKIM signing for your Workspace domain in the Admin console and publish the DNS record Google generates. DKIM lets recipient servers verify that message content has not been altered and that the sending domain authorized the signature.

DMARC policy

DMARC builds on SPF and DKIM alignment and tells recipient systems what to do when mail claiming to be from your domain fails authentication. Start with monitoring if you have not inventoried every legitimate sender. Move to a stricter policy only after DMARC reports show that your real services authenticate correctly.

For bulk senders to personal Gmail accounts, Google requires SPF, DKIM, and DMARC. Messages that do not meet authentication requirements can be marked as spam or rejected with a 5.7.26 error. (support.google.com)

Recipient quality still matters

Authentication cannot rescue a message sent to a nonexistent mailbox. Before a large import or automated campaign, validate lists and suppress known hard bounces; a practical first pass is an email address verification tool. For transactional mail, validate addresses at account creation and retain bounce outcomes so the same invalid recipient is not retried indefinitely.

Gmail SMTP relay limits and operational boundaries

Google Workspace’s SMTP relay service has a stated limit of up to 10,000 recipients per user per day. Google can filter or reject suspicious relay traffic, so this number is not a license to send unsolicited mail or to operate a bulk-marketing engine through an administrative relay. (support.google.com)

A recipient count is not necessarily the same as a message count. One message addressed to several people represents several recipients. Model your usage based on the actual number of recipients, especially if an application sends alerts to groups, CC lists, or distribution lists.

Personal Gmail accounts also have separate sending protections. Google’s Gmail help documentation notes a limit when a personal account sends more than 500 emails in a day or one message to more than 500 recipients. Those figures should not be used to plan Workspace relay capacity; the two sending paths have different purposes and policies. (support.google.com)

If your application sends sustained customer-facing volume, needs automatic bounce and complaint handling, requires event webhooks, or sends marketing messages, use a provider designed for that workload. The goal is not merely to get a 250 SMTP response—it is to preserve sender reputation, observe delivery outcomes, manage opt-outs, and isolate application mail from employee mail.

Common Gmail SMTP relay errors and how to fix them

“Relay access denied” or “not permitted to relay”

This usually means Google did not match the sender to your relay rule. Check the actual public egress IP, not the server’s local IP address. Then confirm that the relay policy permits the From address and that the setting applies to the organizational unit containing the relevant configuration.

If the sender is behind a load balancer, firewall cluster, VPN, or cloud NAT gateway, test each possible egress address. A configuration that works from one server and fails from another is often an IP-path mismatch.

“Connection timed out” or “connection refused”

This is usually a network issue before Google even evaluates your relay policy. Confirm the application can reach smtp-relay.gmail.com on the selected port. Check outbound firewall rules, cloud security groups, ISP port restrictions, DNS resolution, and whether the device supports the selected TLS mode.

Try port 587 with STARTTLS first for a modern application. If a legacy device only supports implicit TLS, test port 465 with its appropriate SSL/TLS-on-connect option. Do not change the Workspace sender policy until you know the network connection succeeds.

TLS handshake or certificate errors

The most common cause is a mode mismatch: the device is trying SSL-on-connect against port 587, or it tries STARTTLS against port 465. Match the device’s labels carefully. “SSL,” “TLS,” “STARTTLS,” “implicit TLS,” and “secure connection” are vendor-specific interface terms, not always equivalent settings.

If the device firmware is too old to negotiate modern TLS properly, update it or place a maintained internal relay in front of it. Reducing security requirements for the entire organization because of one legacy copier is rarely a good trade-off.

“Username and password not accepted”

First determine whether you intended to use smtp.gmail.com or smtp-relay.gmail.com. The Workspace relay service is commonly configured with IP authorization, while Gmail SMTP submission is associated with a specific account.

For mailbox-based sending, do not use an ordinary Google password in a legacy SMTP client. Google recommends OAuth for third-party app access. App passwords are available only under specific account conditions, including 2-Step Verification, and can be revoked when the Google Account password changes. (support.google.com)

Mail is accepted but lands in spam

A successful SMTP relay configuration does not override recipient spam filtering. Check SPF, DKIM, and DMARC results in the delivered headers; make sure the From domain aligns with the domain that authenticates; review message content, URLs, and recipient engagement; and verify the app is not sending unexpected volume or repetitive messages.

Google notes that messages can be filtered or rejected when relay traffic appears suspicious. The service is designed for legitimate organizational mail, not anonymous bulk delivery. (support.google.com)

Security checklist for a production relay

Before you rely on Gmail SMTP relay in production, verify this checklist:

• The relay rule is limited to known public egress IP addresses.
• The allowed sender policy is limited to your authorized domains or addresses.
• TLS is required where the application supports it.
• The application uses smtp-relay.gmail.com, not smtp.gmail.com, for the shared relay workload.
• No employee’s primary Google password is embedded in device configuration or source code.
• SPF includes every genuine sending service and exists as one consolidated DNS record.
• DKIM is enabled for the From domain.
• DMARC is deployed with reporting and a policy appropriate to your sender inventory.
• Test messages have been checked in both sending logs and recipient headers.
• The sending system has alerting for SMTP failures, retries, and unusual volume.

The biggest operational risk is an overly broad relay policy. Limit trusted sources, scope sender identities, review the configuration whenever a network egress address changes, and remove retired systems from the allowlist.

When to use an alternative instead

Gmail SMTP relay is excellent for operational mail from controlled infrastructure. It is less suitable when your use case needs application-level delivery analytics, customer opt-out management, message templates, API keys with scoped permissions, or high-volume sending isolated from the organization’s everyday email.

Choose Gmail SMTP submission when a real person’s mailbox is the correct identity and the software supports Google OAuth. Choose Workspace SMTP relay when a trusted shared system must send through your domain. Choose a dedicated transactional provider when email is a production feature of your application rather than an administrative side effect.

That distinction keeps a scanner working without turning your Google Workspace tenant into an unmonitored application-email dependency.

FAQ

What is the Gmail SMTP relay server name?

For Google Workspace SMTP relay, use smtp-relay.gmail.com. For a mailbox-authenticated Gmail or Workspace submission connection, use smtp.gmail.com. They are not interchangeable.

Which port should I use for Gmail SMTP relay?

Google supports ports 25, 465, and 587 for SMTP relay. For a modern application that supports STARTTLS, use port 587. Use port 465 only when the software expects TLS immediately upon connection, and use port 25 only when your network and device requirements justify it.

Can I use Gmail SMTP relay with a personal Gmail account?

The managed relay service is a Google Workspace administrative feature. A personal Gmail account can use Gmail SMTP submission for account-based sending, but it does not provide the same organization-level IP-authorized relay configuration.

Do I need an app password for smtp-relay.gmail.com?

Not necessarily. In a common Workspace relay design, Google authorizes the sending system by its public IP address, so the device does not use a Gmail username or password. If you instead use mailbox-based smtp.gmail.com, use OAuth where supported and follow Google’s current app-password eligibility rules only when needed.

How do I know Gmail SMTP relay is working?

Confirm four things: your app receives a successful SMTP acceptance response, Google’s admin logs show the message, the recipient receives it, and the message headers show expected authentication results such as SPF, DKIM, and DMARC passing. Inbox delivery alone is useful, but headers and logs reveal whether the configuration is secure and correctly authenticated.