Gmail SMTP Settings: Two Google Endpoints, and Which One You Actually Want

An app asks for four things: server, port, username, password. You type smtp.gmail.com, port 587, your work address and your password, and the app either sends or returns an authentication failure that names nothing useful. That is the entire visible surface of Gmail SMTP configuration, and it hides a fork that decides whether the setup survives contact with real volume.

Google runs two SMTP services on two different hostnames. One is mailbox submission. The other is an organisation relay. They accept similar-looking settings, they authenticate differently, they allow very different amounts of mail, and the most common failure on this topic is configuring the wrong one for the job. Someone working out how to configure Gmail SMTP for a web app, or how to set up SMTP in Gmail so a form sends notifications, is almost always looking at the first. Someone with a scanner in a warehouse, a monitoring box, or a legacy on-premise mail server is usually looking at the second, whether or not they know it yet. Both get filed by people under Google Workspace SMTP, which is why the two keep getting confused.

Here are the real settings for both, and then the part that almost nothing on this subject says out loud: an SMTP connection is a connection to exactly one mailbox, so choosing the endpoint is a decision about mailbox architecture rather than a decision about configuration.

The two hostnames

Google's Workspace admin documentation for sending mail from a printer, scanner or app describes both options on the same page (https://knowledge.workspace.google.com/admin/gmail/send-email-from-a-printer-scanner-or-app). For the first, it states that "the fully qualified domain name of the SMTP service is smtp.gmail.com". For the second, on the same page, "the fully qualified domain name of the SMTP service is smtp-relay.gmail.com".

The names are close enough that people copy the wrong one out of a forum post and spend an afternoon on it. The difference underneath is not cosmetic.

smtp.gmail.comMailbox submission

• You authenticate as one mailbox
• Every message carries that mailbox's identity
• Ports 25, 465 or 587; 465 for SSL, 587 for TLS
• Google's admin page states a sending limit of 2,000 messages per day for this option
• Set up by one person, for one account

smtp-relay.gmail.comOrganisation relay

• Set up in the Google Admin console by an administrator
• Same port choices: 25, 465 or 587
• Supports IP address authentication as well as SMTP authentication
• Much larger allowances, published on a separate Google support page
• Built for on-premise servers, devices and internal apps

The submission endpoint, settings first

For an app that should send as one specific person or one specific shared mailbox, smtp.gmail.com is the correct target.

The port question is where most guides go vague, and Google is specific about it. The same admin page gives the options as "Port 25, 465, or 587" and then resolves them: "For SSL, enter 465. For TLS, enter 587." Google's developer documentation for IMAP and SMTP access says the same thing from the client's side (https://developers.google.com/workspace/gmail/imap/imap-smtp): "The outgoing SMTP server, smtp.gmail.com, supports TLS. If your client begins with plain text, before issuing the STARTTLS command, use port 465 (for SSL), or port 587 (for TLS)."

So the choice between 465 and 587 is decided by what your client does rather than by which port is better. A client that opens an encrypted connection immediately wants 465. A client that opens in plain text and upgrades with STARTTLS wants 587. If the app's own field is labelled "TLS" or "STARTTLS", 587 is the setting it is asking for. Port 25 exists in Google's list and is still worth avoiding, because outbound 25 is routinely blocked at the network or hosting level, and the resulting failure presents as a timeout rather than as a configuration error.

The username is the full email address, including the domain. Not the local part, not a display name. This one detail causes a surprising share of authentication failures, because a lot of setup screens label the field "username" and people fill it in like a username.

Authentication, and the thing that changed

This is where documentation written before 2025 becomes actively misleading.

Google's admin page still describes the older shape plainly. It says the option "requires you to authenticate with your Gmail or Google Workspace account and password when you set it up", and it also instructs, "For authentication, enter your complete Google Workspace email address ... and an app password". An app password is a credential generated for one application, so the application never holds the account password itself.

The same page carries the change that overrides all of it: "Starting May 1, 2025, Google Workspace accounts no longer support less secure apps, third-party apps, or devices that ask you to sign in to your Google Account with your username and password. You must use OAuth".

The mechanism for that is named in the developer documentation: "The SASL XOAUTH2 mechanism enables clients to provide OAuth 2.0 credentials for authentication." An app that supports XOAUTH2 will send you through a Google consent screen and hold a token afterwards. An app that only offers a password box does not support it, and no amount of correct host and port settings changes that.

Now the trap, which is worth naming because bouncing between the two pages is the actual experience of anyone researching this. The Workspace admin page above tells administrators to authenticate with an app password. Google's consumer help page on app passwords states that "App passwords aren't recommended and are unnecessary in most cases" (https://support.google.com/accounts/answer/185833). Both pages are official, both are current, and they are written for different audiences: one for an administrator wiring a device into a managed Workspace domain, the other for an individual with a personal Google account. If you are on Workspace, read the admin page and the May 2025 line together, and treat OAuth as the path rather than the upgrade.

Before you change the host and port again

• ✓Yes: Confirm whether the app supports OAuth, since Workspace accounts have required it since May 1, 2025 per Google's admin page
• ✓Yes: Use the complete email address as the username, domain included
• ✓Yes: Match the port to the client's behaviour: 465 if it opens encrypted, 587 if it starts plain and issues STARTTLS
• ✓Yes: Check whether your network or host blocks outbound port 25 before blaming credentials
• ✓Yes: Confirm which mailbox the connection authenticates as, because that is the identity every message inherits
• ✕No: Copying a password into a field the app will send in plain text on an unencrypted connection
• ✕No: Assuming a relay hostname is a faster version of the submission hostname

The relay endpoint, and who it is genuinely for

smtp-relay.gmail.com exists so an organisation can route mail from its own servers, devices and internal applications through Google. It is configured by an administrator in the Workspace admin console, and it authorises senders differently.

Google's admin documentation on routing outgoing SMTP relay messages (https://knowledge.workspace.google.com/admin/gmail/advanced/route-outgoing-smtp-relay-messages-through-google) gives the standard configuration directly: "If you're using TLS encryption, configure your on-premise mail server to point to smtp-relay.gmail.com on port 587." It also states the constraint that shapes the whole feature: "Without TLS encryption, you can't use SMTP authentication and must use IP address authentication."

That second sentence is the real difference between the two services. Submission always ties a connection to a set of credentials for one mailbox. The relay can instead trust a registered IP range, which is exactly what a copier or an unattended application server needs, because neither has a person to hold credentials on its behalf.

The relay is infrastructure for an organisation's own systems, and it gives a campaign tool no extra headroom and no faster lane to the same place. If what you actually want is a general-purpose relay for outbound campaigns, our guide to free SMTP relay servers works through what those tiers give you and why the shelf is the wrong one for cold outreach; the concept itself is defined in our SMTP relay entry.

What each path allows

The allowances differ by an order of magnitude, and they are published separately.

For the submission option, Google's admin page states plainly: "The sending limit is 2,000 messages per day."

For the relay, Google's support documentation on SMTP relay limits (https://support.google.com/a/answer/2956491) states that "each user can send up to 10,000 messages in a 24-hour period", and adds a shape that catches people out: "There is a 100-recipient limit per SMTP transaction for smtp-relay.gmail.com." A system that batches 500 recipients into one transaction fails against that limit no matter how much daily headroom it has.

Those two figures are the ones that decide the endpoint. For the full picture across providers, including how the per-day, per-minute and per-recipient limits interact, our email sending limits by provider breakdown holds the tables so this page does not have to repeat them.

One connection, one mailbox

Here is the part that turns a configuration question into an architecture question.

When an application authenticates to smtp.gmail.com, it is not connecting to Google in the abstract. It is connecting to one mailbox, and every message it sends inherits that mailbox's address, that mailbox's domain, and that mailbox's accumulated standing with every receiving system. Change the From header in your app and the underlying account is still the account; Google's own SMTP server mechanics do not care what your code prints in a header.

So the questions that look like configuration are really these: which mailbox should this traffic belong to, which domain should it be seen coming from, and what else is riding on that domain's reputation. A form-notification script and an invoicing system can share one mailbox happily. Anything that sends at volume to people who did not ask for it is a different animal, and pointing it at the mailbox your contracts go out from puts one asset behind two very different jobs.

1. Step 1Pick the service

   Mailbox submission on smtp.gmail.com, or the organisation relay on smtp-relay.gmail.com if an administrator is wiring up servers and devices.

2. Step 2Pick the mailbox

   The connection authenticates as one account, and that account's address and domain go on every message.

3. Step 3Pick the authentication

   OAuth via XOAUTH2 where the app supports it, which Workspace accounts have required since May 1, 2025.

4. Step 4Pick the port to match the client

   465 when the client opens an encrypted connection, 587 when it starts in plain text and issues STARTTLS.

If the app on the other end is an outreach tool

A campaign tool asking for SMTP settings is asking to send as one of your mailboxes. That is a legitimate thing to do, and the constraint worth respecting is narrow: do not point it at your primary or personal mailbox and its domain. The asset at risk is the domain your invoices, contracts and support threads travel on, and reputation damage there is expensive in a way that has nothing to do with campaign performance.

Google's own bulk sender guidance shows why the domain is the unit rather than the mailbox. Its requirements page for bulk senders (https://support.google.com/mail/answer/14229414) defines a bulk sender as "any email sender that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period", and then states the aggregation rule: "Messages sent from the same primary domain count toward the 5,000 limit." The same page notes that "bulk sender status doesn't have an expiration date", and that "starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic". Sending from separate mailboxes on the same primary domain does not separate the traffic, because Google is counting the domain.

The working shape is separate mailboxes on separate sending domains, kept distinct from the domain the business runs on, with authentication configured per domain. That is the same conclusion the rest of the stack points at, and our cold email infrastructure guide walks the layers in the order they break. If your app is on the Microsoft side of the fence instead, the tenant behaviours there are different enough to need their own page, and our Office 365 SMTP settings guide covers them.

RevenueFlow runs cold email and LinkedIn outreach for B2B companies on separate sending infrastructure, so this layer is our problem rather than the client's. If you would rather not build and maintain it, prepay a single qualified meeting and see the output before committing to anything larger.

Pricing and features verified as of August 2026. Verify current terms with the vendor before relying on them.