Google SMTP Relay: Setup, Ports, Security, and Testing Guide

Google SMTP relay is the Google Workspace feature for sending application, server, printer, and device email through Google’s mail infrastructure without putting a person’s Gmail password into every system. The hard part is not entering an SMTP hostname: it is choosing the right Google sending option, locking down the relay, and proving that messages authenticate and arrive reliably.

What people usually mean by “Google SMTP relay”

The phrase Google SMTP relay is used for three different Google mail-sending methods. They have different hostnames, authentication models, sending limits, and appropriate use cases. Choosing the wrong one is the most common reason a configuration works in a quick test but fails in production.

Google’s Workspace documentation recommends the SMTP relay service for organization-owned devices and applications. It uses IP-based authentication, supports ports 25, 465, and 587, and can send to internal and external recipients. Google also documents a limit of up to 10,000 relayed recipients per user per day for this service. (knowledge.workspace.google.com)

The practical rule is simple:

• Use smtp-relay.gmail.com when your organization controls the sending application or network and needs mail to originate from addresses at your Workspace domain.
• Use smtp.gmail.com when a single user authorizes a modern client to send as that user.
• Do not treat either service as a high-volume marketing-email platform or an anonymous open relay.

An SMTP relay is not a magic deliverability switch. It gets a message accepted by Google for outbound delivery. Inbox placement still depends on authentication, recipient engagement, content, complaint rates, and compliance with receiver requirements.

Google SMTP relay vs. Gmail SMTP: choose the right service

Use smtp-relay.gmail.com for shared infrastructure

Google Workspace SMTP relay is designed for systems such as:

• A web application sending password resets, receipts, or account alerts
• A CRM, ERP, monitoring platform, or help desk sending notifications
• A printer or scanner that emails scanned documents
• An on-premises Exchange server or mail gateway routing outbound mail through Google
• Security appliances that send operational alerts

The key distinction is that the application is identified as a trusted organization sender, normally by its public outbound IP address. The app does not need to store one employee’s Google password. That reduces the risk of a password change, employee departure, or revoked user account taking down business-critical mail.

For a standard IP-authenticated setup, the application connects to smtp-relay.gmail.com, usually with TLS on port 587, and sends without a username or password. Google decides whether to accept the connection by comparing the public IP it sees with the IP ranges configured in your Admin console.

Use smtp.gmail.com for a single account

The Gmail SMTP submission server is different. It is for mail clients and apps that authenticate as a Google account. Google supports OAuth 2.0 for SMTP authentication through the SASL XOAUTH2 mechanism; the IMAP, POP, and SMTP scope is https://mail.google.com/. (developers.google.com)

For manual client configurations, Google documentation and support materials commonly identify smtp.gmail.com with implicit TLS on port 465 or STARTTLS on port 587. The account’s full email address is the username. OAuth is the durable choice when an application supports it. (support.google.com)

This option can be appropriate for a personal automation, a small script owned by one person, or a modern email client. It is a weak fit for a production service because the service becomes tied to an individual mailbox and its authorization lifecycle.

Do not build around legacy username-and-password sign-in

Google Workspace accounts stopped supporting less secure apps, third-party apps, and devices that sign in using only a Google username and password on May 1, 2025. Google directs administrators toward OAuth, SMTP relay, or other supported configurations instead. (knowledge.workspace.google.com)

App passwords still exist for some Google Account scenarios, but Google describes them as a less secure fallback and recommends “Sign in with Google” where available. App passwords require 2-Step Verification, may not be available for every account or organization policy, and are revoked when the main Google Account password changes. (support.google.com)

For an unattended business application, an IP-restricted Workspace relay rule is generally easier to operate safely than embedding an app password in configuration files.

What you need before configuring Google SMTP relay

A relay configuration is only as secure as the information and controls around it. Gather these details before opening the Google Admin console.

1. A Google Workspace admin role

Google SMTP relay is a Google Workspace administration feature. A consumer @gmail.com account cannot create a domain-level SMTP relay rule for smtp-relay.gmail.com.

You need access to the Google Admin console and permission to manage Gmail routing settings. In many organizations, the setting path is:

Apps > Google Workspace > Gmail > Routing > SMTP relay service

Google can change Admin console labels and navigation over time, so search the Admin console for SMTP relay service if the route differs in your edition or interface.

2. A stable public egress IP address

Google validates the public address that reaches its relay, not necessarily the private address configured on your app server. If your application server uses 10.0.5.18, but traffic exits through a NAT gateway at 198.51.100.24, then 198.51.100.24 is the address that belongs in the relay allowlist.

This point matters for cloud systems. A virtual machine may have a private IP, a changing public IP, a shared NAT gateway, or a separate egress firewall. Determine the actual outbound IP with your cloud or network team before creating the rule.

If the egress IP is dynamic, stabilize it first. Examples include assigning a static public IP, using a cloud NAT gateway with reserved addresses, or routing application mail through a central relay host with a fixed IP. Repeatedly adding changing home-office, ISP, or ephemeral cloud IPs to an SMTP relay allowlist is both fragile and risky.

3. A verified sending domain and clear sender policy

Decide which addresses the system will use before configuring the relay. For example:

• alerts@example.com for monitoring notifications
• receipts@example.com for payment confirmations
• support@example.com for support-system mail
• no-reply@example.com for non-conversational alerts

For most business setups, restrict the relay to addresses in your domains. Do not select an “any addresses” option merely to make an integration test pass. A broad sender policy combined with an overly broad IP range can enable spoofing from your own trusted infrastructure.

4. DNS control for SPF, DKIM, and DMARC

SMTP connectivity is separate from email authentication. You need access to DNS for the sending domain so recipient servers can verify that messages are authorized and authentic.

Google requires senders to personal Gmail accounts to use SPF or DKIM. Senders that send more than 5,000 messages per day to personal Gmail accounts must use SPF, DKIM, and DMARC, along with TLS and other requirements. (support.google.com)

Even when you send far below that threshold, configuring all three mechanisms is the practical baseline for a business domain.

How to configure Google SMTP relay in Google Workspace

The following setup uses the safest common pattern for an application or device with a fixed public IP: domain-restricted senders, IP allowlisting, and required TLS.

Step 1: Create an SMTP relay service rule

In the Google Admin console, open Gmail routing settings and locate SMTP relay service. Create a new rule and give it an operational name, such as:

Production app relay – us-east NAT

A descriptive name becomes valuable later when you need to rotate infrastructure, audit access, or troubleshoot a rejected connection.

Step 2: Restrict allowed senders

Choose the narrowest sender option that fits the application.

For an internal notification system that sends as alerts@example.com, choose the option equivalent to:

Only addresses in my domains

This prevents a trusted application connection from claiming arbitrary external sender domains. If a vendor integration requires another model, understand why before expanding the rule. A third party that sends mail from your domain should still authenticate as an approved sender and be included in your domain’s authentication plan.

Step 3: Allow only the application’s public IP address or range

Under authentication, enable the option equivalent to:

Only accept mail from the specified IP addresses

Add the public outbound IP address or CIDR range that Google will see. Use the smallest possible range. A single static address should be entered as a single host address rather than a large network block.

For example:

The addresses above are documentation-only examples from reserved ranges. Substitute your actual routable egress addresses.

Do not add:

• 127.0.0.1
• Private RFC 1918 addresses such as 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16
• The application server’s internal IP when a firewall or NAT gateway changes the source address
• 0.0.0.0/0
• A broad cloud-provider address range you do not exclusively control

An IP mismatch is a common source of relay errors. Google’s SMTP troubleshooting guidance includes relay-limit and temporary SMTP errors, while Admin-console diagnostic messages can identify a connecting IP that is not in the allowed relay list. (support.google.com)

Step 4: Require TLS encryption

Enable the setting equivalent to:

Require TLS encryption

TLS protects the SMTP session between the application and Google’s relay. It is particularly important when application messages may include reset links, internal URLs, purchase information, or attachments.

Use port 587 with STARTTLS when your software supports it. This is the most broadly compatible modern submission pattern. Port 465 is appropriate for software that specifically expects implicit TLS from connection start. Port 25 is available for the relay service but is frequently blocked or filtered by networks and cloud providers; it should not be your first choice for a new application.

Step 5: Decide whether SMTP authentication is necessary

For the standard IP-authenticated relay pattern, leave SMTP authentication disabled and do not put a Gmail username and password in the application. Google validates the source IP instead.

Google Workspace can also support configurations that require SMTP authentication, but that model needs TLS and a compatible authentication method. Use it only when you have a specific design requirement and understand the credentials or OAuth lifecycle involved. For a server-to-server operational relay, combining a fixed egress IP, domain-restricted senders, and TLS is usually simpler to audit.

Step 6: Save, then allow configuration time to propagate

Save the rule. Google’s Gmail settings can take time to propagate across an organization, and some Workspace settings can take up to 24 hours to update. Do not immediately create several overlapping rules because the first test fails in the first few minutes. (support.google.com)

Record the rule name, approved IPs, sending application, sender addresses, owner, and date in your infrastructure documentation. This is a small task that avoids a major outage when a NAT gateway is replaced months later.

Application settings: host, port, TLS, and credentials

For the common IP-authenticated Google SMTP relay setup, use these values.

Google lists smtp-relay.gmail.com as the relay hostname and supports ports 25, 465, and 587. (knowledge.workspace.google.com)

The exact names in your vendor interface vary. “Use TLS,” “STARTTLS,” “TLS if available,” and “SSL/TLS” are not always equivalent settings:

• STARTTLS on 587: establish SMTP, then upgrade to TLS. This is the usual setting for new deployments.
• Implicit TLS on 465: encrypt immediately on connection. Use only if the app expects this mode.
• TLS if available: avoid this if your Google rule requires TLS, because the app might try to continue without encryption.
• SSL: older interfaces may label TLS options as SSL. Check the vendor documentation for whether it means implicit TLS or STARTTLS.

A port-and-encryption mismatch produces confusing errors. For example, setting “SSL” or “implicit TLS” while using port 587 can fail because the client expects encryption before the server is ready for it. Conversely, setting plain SMTP on port 465 fails because the server expects an encrypted handshake first.

Worked example: relay mail from a web application

Assume you operate example.com in Google Workspace. Your production application runs behind a NAT gateway with public egress address 198.51.100.24. It needs to send account-verification and password-reset messages from notifications@example.com.

Configure the Workspace relay rule

1. In Gmail routing settings, create a rule named Production notifications relay.
2. Set allowed senders to only addresses in my domains.
3. Enable acceptance only from specified IP addresses.
4. Add 198.51.100.24 as Production NAT gateway.
5. Require TLS encryption.
6. Leave SMTP authentication off because this is an IP-based relay design.
7. Save the rule.

Configure the application

Set the mail transport configuration to:

SMTP_HOST=smtp-relay.gmail.com
SMTP_PORT=587
SMTP_SECURE=starttls
SMTP_AUTH=false
MAIL_FROM=notifications@example.com
MAIL_FROM_NAME=Example Notifications

Your framework’s exact environment-variable names will differ. In a Node.js, Python, PHP, Ruby, Java, or .NET library, the essential choices are the same: host, port 587, STARTTLS, no credential fields for this IP-authenticated configuration, and a From address at example.com.

Send a controlled test

Use a real external recipient that you control, such as a personal Gmail account and a mailbox at another provider. Test with a unique subject line:

Subject: SMTP relay test – example.com – 001

For a Linux or macOS command-line test, the swaks SMTP test utility can make the SMTP behavior explicit:

swaks \
  --server smtp-relay.gmail.com \
  --port 587 \
  --tls \
  --from notifications@example.com \
  --to your-test-address@example.net \
  --header "Subject: SMTP relay test – example.com – 001" \
  --body "This is a controlled SMTP relay test."

Run this command only from the host or network whose public IP you added to the Google relay rule. If you run it from your laptop while only the production NAT IP is allowlisted, rejection is expected and confirms that the allowlist is doing its job.

What success looks like

A successful test has four parts:

1. The SMTP client receives a successful acceptance response after sending the message data.
2. The recipient receives the message, ideally in the inbox rather than spam.
3. The visible From address is notifications@example.com.
4. The received message headers show passing authentication for the domain.

In Gmail, open the received message, use Show original, and look for an Authentication-Results header. A healthy outcome commonly includes results resembling:

spf=pass
 dkim=pass
 dmarc=pass

The exact formatting and domains in headers differ by recipient and sending path. The important result is that at least one aligned identifier supports DMARC, and that your intended sender domain—not an unexpected vendor domain—is being authenticated.

Configure SPF, DKIM, and DMARC for relay mail

SPF: authorize Google Workspace sending

SPF is a DNS TXT record that lists services authorized to send mail for a domain. Google’s standard example for a domain that sends only through Google Workspace is:

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

Google explicitly cautions that you must identify all systems that send for your domain before creating the SPF record. That includes web servers, on-premises mail servers, outbound gateways, contact forms, and third-party email providers. (support.google.com)

Do not publish multiple SPF TXT records at the root domain. SPF evaluation expects one SPF policy record; combine authorized mechanisms into one record. If you also use an email API provider, CRM, or support platform, incorporate that provider’s documented SPF mechanism into the same record after checking DNS-lookup limits and syntax.

DKIM: publish Google’s signing key

DKIM lets receiving servers validate a cryptographic signature attached to outgoing email. In Google Workspace, generate a DKIM key for your domain in the Admin console, publish the provided TXT record at your DNS host, then return to Google and start authentication.

Google explains that the public key lives in DNS and the private key signs outgoing messages; recipient servers retrieve the public key to authenticate the signature. (support.google.com)

Use the key length offered and supported by your DNS provider and Google Workspace configuration. If an outbound gateway modifies message content after signing—for example, by appending a disclaimer—it can interfere with DKIM validation. Test messages after every gateway or footer change.

DMARC: start with visibility, then enforce

DMARC tells receiving servers what to do when mail claiming to be from your domain fails authentication. A cautious initial record can collect reports while allowing delivery:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100

After you verify every legitimate mail stream in reports, move gradually toward enforcement, for example p=quarantine and later p=reject if appropriate. Google’s example shows the same fundamental syntax and explains that DMARC policies can deliver, quarantine, or reject unauthenticated mail. (support.google.com)

Do not jump to p=reject before accounting for every sender. A forgotten billing system, form plugin, or SaaS platform can become unable to deliver mail from your domain.

Common Google SMTP relay failures and how to fix them

“Connection timed out” or “Could not connect”

This is usually a network path issue, not a Google authentication issue. Confirm that the application host can make outbound TCP connections to port 587. Corporate firewalls, hosting providers, containers, and cloud security groups may restrict SMTP egress.

Try a TCP and TLS test from the application environment, not from a developer laptop. If port 587 is blocked, fix the firewall policy rather than switching casually to port 25. Port 25 has a higher chance of network-level filtering.

“Not authorized,” “relay access denied,” or an IP-related rejection

Check the IP Google sees. The approved address must be the public source IP after NAT, load balancers, egress proxies, and cloud gateways. Compare it with the relay rule’s allowlist.

Also verify that the active relay rule applies to the correct organizational unit. In a large Workspace organization, Gmail configuration can vary by organizational unit, and a rule configured in the wrong scope may not apply to the intended sending service.

Authentication failures after entering a Gmail password

Do not respond by enabling “less secure apps”; that path is not supported for Workspace accounts. If you chose the IP-authenticated relay design, remove the username and password from the app and turn SMTP auth off in the client.

If you are using smtp.gmail.com rather than smtp-relay.gmail.com, use OAuth 2.0 where supported. An app password can be a limited fallback for eligible accounts and devices, but it is not a general substitute for an organization-wide relay architecture. (knowledge.workspace.google.com)

TLS handshake or certificate errors

Match port and TLS mode exactly. Start with port 587 and STARTTLS. Update the application, operating system certificate store, and mail library if it cannot negotiate modern TLS.

Do not disable certificate validation to make a test pass. That hides a security problem and leaves credentials or message content vulnerable in configurations that use authentication.

The message is accepted but lands in spam

SMTP acceptance is not inbox placement. Inspect the received headers first:

• Does SPF pass for the envelope-sender domain?
• Does DKIM pass for your visible From domain?
• Does DMARC pass and align with the From domain?
• Is the message using a legitimate From address at your domain?
• Does the message contain a valid plain-text alternative, functional links, and a truthful subject?

For larger Gmail-bound sending, Google requires SPF, DKIM, and DMARC, TLS, valid forward and reverse DNS, RFC 5322-compliant formatting, and a spam rate below 0.30% in Postmaster Tools. (support.google.com)

Google Postmaster Tools can show authentication, spam-rate, reputation, and delivery-error information for qualified sending domains. It is useful for diagnosing trends that a single test email cannot reveal. (support.google.com)

The relay suddenly stops after a network migration

This almost always means the outbound IP changed. Common triggers include moving a workload to another region, replacing a firewall, enabling a new NAT gateway, changing a Kubernetes egress design, or failing over to a disaster-recovery environment.

Treat relay IPs as infrastructure dependencies. Include them in change-management checklists, alert when they change, and maintain a controlled secondary IP for disaster recovery where appropriate.

Security and operational practices that keep relay reliable

A Google SMTP relay should be managed like a production access control, not like a one-time email setting.

Use least privilege

Limit the relay to:

• The minimum set of public source IPs
• Only the sender domains your organization owns
• TLS-required connections
• The smallest organizational-unit scope that serves the application

Avoid broad IP ranges, all-domain sender permission, and copied credentials. These shortcuts create an abuse path that can harm domain reputation and trigger Google filtering or rejection.

Separate transactional, operational, and promotional streams

Use distinct sender addresses or subdomains where your organization’s mail volume and workflows justify it. For example, alerts@example.com, receipts@example.com, and news@example.com communicate different purposes to recipients and make authentication reports easier to interpret.

This does not eliminate the need for good consent practices or relevant content. It does, however, limit the operational blast radius when one stream has a complaint or deliverability problem.

For application-generated email that needs event logs, webhooks, dedicated sending controls, and an API-first workflow, compare the relay approach with a purpose-built provider and its transactional email pricing. SMTP relay is convenient when Google Workspace is already central to your organization, but it is not automatically the best architecture for every sending workload.

Monitor the whole delivery chain

A green checkmark in an application log means only that the app handed the message to an SMTP server. Monitor at several layers:

1. Application — queue depth, failed jobs, retry count, and SMTP response codes.
2. Network — outbound port access and stable egress IPs.
3. Google Workspace — relay configuration, Gmail logs, and policy rejections.
4. Recipient headers — SPF, DKIM, DMARC, and TLS results.
5. Postmaster and feedback signals — spam rates, delivery errors, and reputation where available.

If you are building a product instead of configuring a single appliance, an email API reference and setup guide can be easier to integrate and observe than maintaining SMTP-specific behavior across application environments.

When Google SMTP relay is the wrong choice

Google SMTP relay is a strong option for low-to-moderate-volume operational mail from systems that already belong to a Google Workspace organization. It is less suitable when your requirements include:

• High-volume product, lifecycle, or marketing campaigns
• Dedicated IP reputation management
• Detailed delivery-event webhooks
• Bounce, complaint, and suppression-list automation
• Per-customer sending domains in a SaaS product
• Fine-grained sending analytics and API controls
• A workload that cannot use a stable outbound IP

In these cases, use a transactional email service designed for application mail. Keep the domain authentication work: SPF, DKIM, and DMARC remain necessary regardless of which provider sends the message.

Also avoid using a personal Gmail mailbox as the production identity for a company application. It creates ownership ambiguity, weak operational continuity, and an unnecessary dependency on one person’s account security.

Google SMTP relay deployment checklist

Before declaring the integration complete, verify every item below.

• The application uses smtp-relay.gmail.com, not smtp.gmail.com, unless a user-authenticated submission design is intentional.
• The Google Workspace relay rule is enabled in the correct organizational unit.
• Allowed senders are restricted to your domain addresses where possible.
• The allowlist contains the actual public egress IP or the narrowest required CIDR range.
• TLS is required in the relay rule.
• The client uses port 587 with STARTTLS, or an explicitly compatible 465 implicit-TLS configuration.
• The client does not store a Gmail password when the relay is IP-authenticated.
• SPF authorizes every legitimate sender, in one DNS SPF record.
• DKIM is enabled and passes on test messages.
• DMARC is published and reports are reviewed before moving to enforcement.
• Test mail reaches at least two external providers.
• Received headers show the expected From address and passing authentication.
• The relay rule, IPs, application owner, and rotation procedure are documented.

Conclusion

The reliable way to set up Google SMTP relay is to use smtp-relay.gmail.com for organization-controlled systems, authenticate the source by a stable public IP, require TLS, restrict sender domains, and validate SPF, DKIM, and DMARC with real received-message headers.

Do not confuse Google Workspace SMTP relay with Gmail’s user-authenticated SMTP server. The former is infrastructure for trusted business systems; the latter is account-based submission. Once you make that distinction, the remaining work becomes a controlled configuration exercise rather than an endless cycle of password errors, relay denials, and spam-folder surprises.

FAQ

What is the Google SMTP relay server address?

For Google Workspace SMTP relay, the server address is smtp-relay.gmail.com. Google supports ports 25, 465, and 587; port 587 with STARTTLS is the practical default for new application integrations. (knowledge.workspace.google.com)

What port should I use for Google SMTP relay?

Use port 587 with STARTTLS unless your application specifically requires implicit TLS on port 465. Avoid starting with port 25 because many networks and hosting providers filter outbound SMTP on that port.

Does Google SMTP relay need a username and password?

Not in the common IP-authenticated Workspace configuration. Configure the relay to accept mail only from your application’s public IP address, require TLS, and leave SMTP credentials blank in the app. Use SMTP authentication only when your specific architecture requires it.

Can I use Google SMTP relay with a free Gmail account?

No. Google SMTP relay is a Google Workspace administration feature. A free Gmail account can use Gmail SMTP submission through smtp.gmail.com, typically with OAuth 2.0 or, for eligible legacy-device cases, an app password.

How do I know Google SMTP relay is working?

Confirm that the SMTP client receives a success response, the message arrives at an external mailbox, the From address is correct, and the recipient’s headers show passing SPF, DKIM, and DMARC results. For ongoing Gmail delivery monitoring, use Postmaster Tools where available. (support.google.com)