Google SMTP settings, Gmail server, ports, and auth guide

The Gmail SMTP server is the outbound submission endpoint used when an email client, app, or script sends mail through a Gmail or Google Workspace account. Searchers looking for , , , or usually need one thing: the exact settings plus the real reasons login and send attempts fail.

This guide is written for that practical setup intent. It covers the Gmail SMTP settings table, which port to use, how app-password authentication changes the setup, and how to test the send path before you trust it in production.

Executive summary

Use as the SMTP host.
Start with port and unless your client explicitly expects implicit TLS on .
Use the full Gmail or Workspace email address as the username.
Expect account-security policy or app-password requirements to cause more failures than the hostname itself.
Validate the send path with SMTP and inbox tests before using Gmail SMTP for reset, OTP, billing, or notification workflows.

Quick answer

The Gmail SMTP settings most teams need are:

hostname:
username: full Gmail or Workspace email address
common ports: with , or with implicit TLS
TLS or SSL required
SMTP authentication required

The two mistakes that cause the most Gmail SMTP failures are:

mismatching the port and TLS mode
assuming a normal mailbox password will always work without app-password or account-policy review

Gmail SMTP settings overview

Setting	Typical value	Notes
SMTP server		Use the same hostname for Gmail and most Google Workspace SMTP client setups.
Username	Full email address	Use the entire mailbox address, not only the local part.
Port	or	is usually the safest starting point for authenticated submission.
TLS mode	on , implicit TLS on	Do not mix these. Port/TLS mismatch often looks like a login problem.
Password	App password or policy-approved credential	The usable credential depends on the account security model.
Authentication	SMTP auth required	Client, account, and organization policy can affect what is allowed.

Those values are necessary, but not sufficient. Most Gmail SMTP issues come from account policy, credential type, or client-side TLS assumptions rather than the hostname alone.

Which Gmail SMTP port should you use?

Port

Use port when your client supports authenticated SMTP submission with .

This is usually the best default for app and client configuration because it matches how most SMTP submission guides are written today and works cleanly with modern TLS upgrade behavior.

Port

Use port only when the client expects an encrypted connection from the start.

This is commonly described as implicit TLS or SMTPS. If your client tries to use behavior on , the handshake will usually fail.

Which one should teams start with?

Use first unless:

the provider or client specifically requires
a legacy client only supports the implicit-TLS pattern well
you have already validated a known-good configuration for that environment

If you are uncertain, review the broader port behavior in SMTP, IMAP, and POP3 ports and STARTTLS vs SSL/TLS.

Gmail SMTP authentication realities

Most outdated Gmail SMTP tutorials fail because they treat authentication as if it were still a simple username-and-password field with no account-security context.

Common realities:

legacy "less secure app" guidance is obsolete
app-password workflows may be required depending on the account setup
account-level or organization-level security settings can block SMTP logins that look correct on paper
Google Workspace policy can differ from a personal Gmail account, especially in managed environments

When app passwords matter

In many Gmail SMTP setups, the usable SMTP credential is not the same as the normal mailbox password. Teams often need an app password or a policy-approved credential path, especially when the account has stronger security controls.

This is where many "username and password are correct but login still fails" incidents come from.

Gmail vs Google Workspace

The SMTP hostname may stay the same, but the account policy may not.

With Google Workspace, admins may enforce different requirements around:

SMTP auth
allowed client types
app-password usage
relay or API-based alternatives

Treat Gmail SMTP setup as protocol plus policy, not only a copy-paste field set.

Example Gmail SMTP client configuration

Most clients or libraries will ask for:

SMTP host:
SMTP port: or
encryption mode: or implicit TLS
username: full mailbox address
password: app password or approved SMTP credential
sender address: usually the same Gmail or Workspace mailbox unless the account is configured otherwise

If any one of those is wrong, the failure message is usually more generic than the actual root cause.

Gmail SMTP configuration checklist

Use this checklist before testing in a client or app:

confirm the mailbox is the correct Gmail or Google Workspace account
set as the SMTP host
choose with first, or only when the client expects implicit TLS
use the full email address as the username
confirm the account's allowed credential path before assuming the mailbox password will work
test the configuration in isolation before rolling it into production code
validate the resulting message in a safe inbox instead of stopping at "SMTP login succeeded"

Common Gmail SMTP failures

Authentication failure

Usually caused by:

using the wrong credential type
missing app-password setup where it is required
blocked login policy or account-security rule
using an alias or short username instead of the full mailbox address

Connection failure

Usually caused by:

wrong port
wrong TLS mode
blocked outbound network path
local firewall or client restrictions

TLS negotiation failure

Usually caused by:

using implicit TLS expectations on port
trying behavior on port
stale client defaults that do not match Gmail's submission requirements

Message accepted but workflow still weak

Even if Gmail SMTP accepts a message, the workflow may still be fragile if you do not validate headers, delivery, and receive-side behavior.

Gmail SMTP error table

Symptom	Likely cause	First check
Auth failed	Wrong credential type or account-policy issue	Review whether app password or another approved auth path is required
Could not connect	Wrong port or TLS mode	Compare + vs + implicit TLS
TLS handshake error	Client encryption mode does not match the chosen port	Fix the port/TLS pairing first
Works in one client, not another	Client defaults differ	Compare username format, TLS mode, and auth assumptions
Mail sends but product workflow is still weak	SMTP login succeeded but operational validation is missing	Inspect headers, inbox receipt, and failure evidence

Gmail SMTP vs Gmail API

Gmail SMTP is useful when:

you need standard SMTP client compatibility
the stack already expects SMTP
you want simple client configuration

Gmail API is often better when:

you need stronger application-level control
you want structured integration behavior
you are automating message creation or mailbox operations

Relevant pages:

Gmail SMTP in testing workflows

If you are validating application mail, do not stop at "SMTP login works."

Also verify:

the message was actually sent
headers look correct
auth results are healthy
links and OTP codes are usable

Useful related pages:

Troubleshooting checklist

confirm is the configured host
confirm the client uses with or with implicit TLS, not a mixed combination
verify the username is the full mailbox address
confirm which credential type the account is allowed to use
test with a clean client or isolated environment to remove cached assumptions
inspect the resulting headers and delivery behavior, not only the login result
decide whether Gmail SMTP is still the right path for the workload

When Gmail SMTP needs a broader workflow

Gmail SMTP can work well for mailbox-oriented sending and basic client compatibility, but teams usually add more around it when they need:

release-gate testing for signup, OTP, reset, billing, or notification flows
higher-volume operational sending
clearer delivery evidence and observability
reusable infrastructure across environments

If the goal is application mail, not just mailbox sending, pair the SMTP path with stronger testing, inbox validation, and sender-health checks so the workflow is safe to ship.

Use MailSlurp for Gmail SMTP testing

MailSlurp helps teams validate SMTP behavior with SMTP tester, inspect auth and route details using Email header analyzer, and run broader workflow checks in Email sandbox. Create a free account at app.mailslurp.com if you need Gmail-related send paths tested before release.

FAQ

What is the Gmail SMTP server?

It is Google's SMTP submission endpoint used for sending mail from Gmail or Google Workspace accounts.

What port does Gmail SMTP use?

Usually with or with implicit TLS.

Because account security policy, app-password requirements, username format, or port/TLS mismatch are often the real cause instead of the hostname itself.

Should teams use Gmail SMTP for production product mail?

They can, but product teams usually pair Gmail SMTP with stronger testing, observability, and inbox verification so release-critical workflows stay predictable.

What are Google's SMTP settings?

Most teams start with , port with , full email address as the username, and the account-approved credential path.

Does Gmail SMTP use app passwords?

Often yes, depending on the account-security model and environment. Treat the credential requirement as a policy question, not just a client field.

What is the Gmail SMTP server address?

Use .

Final take

Google SMTP is straightforward only when the settings, TLS mode, and credential policy all match. Use it with a clear configuration checklist, test it before release, and surround it with controlled inbox validation when the workflow matters to customers.

Google SMTP Settings: Gmail Server, Ports, Auth, and Common Failures

Executive summary

Quick answer

Gmail SMTP settings overview

Which Gmail SMTP port should you use?

Port