Gmail SMTP Server Settings: smtp.gmail.com, Ports, Auth, and Testing

The Gmail SMTP server is smtp.gmail.com. Use port 465 with implicit TLS, often labelled "SSL/TLS", or port 587 with STARTTLS. Authenticate using the full Gmail or Google Workspace email address and a supported sign-in method.

For an email client that offers "Sign in with Google", use that option. A device or application that only accepts an SMTP username and password may need an app password, which requires 2-Step Verification and is not available for every account. Do not put your regular Google Account password into an old SMTP setup or follow instructions to enable "less secure apps".

Quick Gmail SMTP settings

Setting	Value
Outgoing SMTP host	smtp.gmail.com
Implicit TLS option	Port 465, with TLS from connection start
STARTTLS option	Port 587, with a required TLS upgrade
Username	Your full Gmail or Google Workspace mailbox address
Authentication	OAuth through a supported client, or an app password when the account permits it
Certificate validation	Enabled, including hostname verification

Google documents the host and STARTTLS settings in its mail-client settings, and the 465/587 options in its printer, scanner, and app instructions. Work and school accounts may have additional administrator rules.

What if your settings say smtp.googlemail.com?

If you are repairing a configuration that contains smtp.googlemail.com, use the currently documented host, smtp.gmail.com, for the new setup. Older configuration text is not a reason to guess at a different port or turn off certificate validation.

Change the outgoing server hostname, check the port/TLS pair, and keep the username as the full address of the mailbox you actually sign in to. The server hostname and your account's email address are separate settings; updating the server does not mean renaming your account.

Then check authentication independently. A hostname change cannot repair a revoked app password, an unsupported sign-in method, or a Workspace policy restriction. Use the exact error from the new connection to identify which stage still fails.

Match the Gmail port to the encryption mode

On 465, the client starts TLS immediately and then begins SMTP. On 587, it starts an SMTP conversation and upgrades with STARTTLS before authentication. Both routes use TLS; "SSL port" is a common settings label, not a recommendation to use obsolete SSL protocols.

A client expecting a plaintext greeting on 465 can stall. A client starting an immediate TLS handshake on 587 can fail before it reaches login. Fix that pairing before replacing credentials, and require successful certificate verification in either mode. See the SMTP port comparison if your library's encryption options are unclear.

Choose the sign-in method your account supports

Google recommends Sign in with Google for compatible email clients. For custom software, Gmail SMTP supports the OAuth 2.0 XOAUTH2 mechanism. Use a library's supported OAuth integration; an OAuth access token is not simply a replacement password for every SMTP login method.

If an older app or device cannot use Google sign-in, check Google's app-password instructions. App passwords require 2-Step Verification. The option may be unavailable for an organization account, an account using only security keys for 2-Step Verification, or an account enrolled in Advanced Protection.

For an eligible account, create an app password for that app or device and store it in the device's protected credential field or your application's secret store. Google revokes app passwords when you change the Google Account password, so a previously working configuration can need a replacement. Keep credentials and OAuth tokens out of logs and SMTP transcripts you share.

If the option is unavailable, ask the Workspace administrator which supported method the application should use, or update the client to one that supports Google sign-in. Turning off account security is not a repair.

Configure the client, app, or device

Once you know the account's authentication method, put the settings together:

1. Choose Google sign-in in a compatible client. For manual SMTP configuration, enter smtp.gmail.com as the outgoing host, without https:// or a mailbox address appended to it.
2. Set 465 with implicit TLS or 587 with required STARTTLS. Keep certificate checks enabled.
3. Enter the full mailbox address and configure the supported OAuth flow or eligible app password.
4. Use the authenticated mailbox as the sender for the first test. Configure any additional sender alias through the account's approved process before using it.
5. Address one test message to an inbox you control and send it through the configured client or application. Record the error if submission fails; if it succeeds, confirm receipt and inspect the sender and reply address.

For application mail, repeating this check manually after every credential or library change is easy to miss. MailSlurp is an email testing platform that provides controlled inboxes and APIs for waiting for messages, inspecting their contents, and checking signup, password-reset, and notification flows.

Gmail SMTP vs Google Workspace SMTP relay

smtp.gmail.com submits mail as an authenticated mailbox. smtp-relay.gmail.com is the Google Workspace relay service, configured by an administrator for the organization's devices or services. They are different services with different authorization rules.

If your organization tells you to use Workspace relay, follow its allowed-sender, authentication, IP, and TLS requirements. Do not substitute the relay hostname to work around a Gmail login error. Conversely, credentials copied from a mailbox setup do not establish that a device is permitted by a relay policy.

Google's SMTP relay configuration describes those administrative controls. The Workspace relay guide explains that route in more detail.

Troubleshoot the error you receive

Failure	What to check
Connection timeout	Host, port, DNS, network egress, and the device's internet connection
TLS or certificate error	Port/TLS pairing, hostname, device clock, current software, and trusted certificate store
"Username and password not accepted"	Full mailbox address, supported auth method, token validity, or app-password revocation
"Application-specific password required"	Whether an app password is available for this account, or whether the client should use Google sign-in
"Must issue a STARTTLS command first"	Whether the client requires STARTTLS before login on port 587
Relay denied	Correct mailbox-versus-relay service, sender identity, and Workspace relay rules

A password error can be an authentication-method error, so repeatedly changing the regular account password may make troubleshooting worse by revoking existing app passwords. For an OAuth client, check its token refresh and account authorization instead of creating unrelated SMTP passwords.

Test from the environment that actually sends mail. A printer, laptop, and cloud application can have different network rules and trust stores. A successful test from another machine is useful comparison evidence, but does not confirm the failing machine's connection.

Check the message your application sends

For a repeatable application test, create a fresh MailSlurp inbox, use its address for a test user, and trigger the actual notification or password-reset action. Keep the configured Gmail SMTP path in place so the test exercises that connection. Wait for the expected message using MailSlurp's email wait methods.

Inspect the recipient, sender, reply address, subject, and required content. For a reset email, check that the link points to the expected application environment and that the flow works before the link expires. Keep tokens, message bodies, and private headers out of public test reports.

SMTP acceptance alone does not confirm receipt or inbox placement. A message arriving at your MailSlurp inbox confirms that tested destination; use the affected provider's delivery evidence when investigating a Gmail recipient's spam placement or a domain-specific delay.

Gmail SMTP vs Gmail API

SMTP fits clients and frameworks that already send through an SMTP transport. The Gmail API is another option when an application needs structured mailbox operations as well as sending. OAuth is available for Gmail SMTP too, so you do not need to switch protocols merely to avoid password-based authentication.

If SMTP is your existing integration, finish by checking the real message after the connection works. If you are building a mailbox integration with broader operations, review the Gmail API guide before choosing the transport.