Table of Contents
- What Gmail SMTP Settings Should You Use
- Which fields belong together
- How should website administrators apply these settings
- How to verify it
- How Gmail SMTP Authentication Works
- When does OAuth make more sense
- Why might app passwords be unavailable
- How to verify it
- Which Port and Encryption Pair to Choose
- What do the client's encryption labels mean
- What should happen before authentication
- How to verify it
- How Personal Gmail Differs from Workspace Relay
- Which endpoint belongs to which sending path
- What is different about relay configuration
- How to verify it
- How to Set Up a Gmail App Password
- What is the setup sequence
- What can prevent creation or use
- How to verify it
- How to Verify a Gmail SMTP Connection
- How to verify it
- What does a failed result mean
- Common Gmail SMTP Mistakes to Fix
- Which mistake matches the symptom
- Which assumptions make troubleshooting slower
- How to verify it
- Gmail SMTP Questions People Still Ask
- Can port 25 replace the Gmail submission ports
- Should an app password be reused across devices
- Does OAuth replace the Gmail SMTP hostname
- Does successful authentication guarantee later messages will be accepted
Do not index
Do not index
Gmail SMTP settings are smtp.gmail.com, port 587 with STARTTLS or port 465 with SSL, and the full Gmail or Google Workspace address as the username. For password-based clients, use a 16-digit app password that requires 2-Step Verification, not the normal Google account password.
The correct server address alone isn't enough. The port, encryption mode, and credential type must work together, and a mismatch can stop an application before Google evaluates its login.
Table of Contents
What Gmail SMTP Settings Should You UseWhich fields belong togetherHow should website administrators apply these settingsHow to verify itHow Gmail SMTP Authentication WorksWhen does OAuth make more senseWhy might app passwords be unavailableHow to verify itWhich Port and Encryption Pair to ChooseWhat do the client's encryption labels meanWhat should happen before authenticationHow to verify itHow Personal Gmail Differs from Workspace RelayWhich endpoint belongs to which sending pathWhat is different about relay configurationHow to verify itHow to Set Up a Gmail App PasswordWhat is the setup sequenceWhat can prevent creation or useHow to verify itHow to Verify a Gmail SMTP ConnectionHow to verify itWhat does a failed result meanCommon Gmail SMTP Mistakes to FixWhich mistake matches the symptomWhich assumptions make troubleshooting slowerHow to verify itGmail SMTP Questions People Still AskCan port 25 replace the Gmail submission portsShould an app password be reused across devicesDoes OAuth replace the Gmail SMTP hostnameDoes successful authentication guarantee later messages will be accepted
What Gmail SMTP Settings Should You Use
The following settings apply to authenticated mailbox submission. An application, script, scanner, or other device connects to Google and signs in as a particular mailbox.
Google's Gmail IMAP and SMTP documentation specifies
smtp.gmail.com with 465 for SSL-protected connections or 587 for STARTTLS. Product behavior and client interfaces can change, so Google's current documentation remains the reference when an application's labels are unclear.Which fields belong together
A client's outgoing server settings should be reviewed as a single configuration, rather than copied independently from different guides. Selecting a host from a mailbox guide and an authentication method from an organizational relay guide produces a configuration that doesn't describe either sending path correctly.
The username should identify the complete mailbox, not just the portion before the at sign. A display name, website administrator login, or sender label isn't a substitute for that mailbox identity.
For an unfamiliar configuration, the mailX SMTP finder helps identify the outgoing server before credentials are entered. Server discovery establishes which endpoint belongs in the configuration; it doesn't establish that a particular mailbox is authorized to use it.
How should website administrators apply these settings
Website administrators should enter these values in the application's outgoing email configuration, rather than treating a successful website login as email authorization. The website account and the Google mailbox are separate identities, even when the same person manages both.
For a website-specific walkthrough, UpTime Web Hosting explains how to set up authenticated WordPress email. The same distinction matters for scripts and devices: the software needs an outgoing mail connection and a supported Google credential.
Check Google's current limits before relying on the connection for an ongoing sending workload. A working SMTP configuration doesn't remove account restrictions.
How to verify it
Use the mailX SMTP test after configuration. A good result establishes a connection, negotiates the selected encryption mode, and accepts authentication; a failure should be investigated at the specific stage that failed.
How Gmail SMTP Authentication Works
Authentication establishes which mailbox an application is allowed to use. Encryption protects the connection carrying that authentication attempt. Personal Gmail and Google Workspace mailbox submission need both, but a successful encrypted connection doesn't mean Google has accepted the supplied credential.
A normal Google account password, an app password, and an OAuth access token aren't interchangeable. The application must support the mechanism associated with the credential.
When does OAuth make more sense
Google documents SASL XOAUTH2 authentication for Gmail, which lets an SMTP application present an OAuth 2.0 access token rather than a password. Production applications should favor this architecture when supported because tokens can be scoped, rotated, and revoked independently of a person's primary password.
OAuth also separates application authorization from the user's ordinary sign-in secret. Developers still need to implement token handling correctly; pasting an access token into an arbitrary password field doesn't automatically make a client OAuth-capable.
A scanner or older client may lack the ability to complete an OAuth consent flow. An app password can be appropriate in that situation, provided Google makes the option available for the account and the organization permits its use.
Why might app passwords be unavailable
Google Workspace administrators can restrict which authentication mechanisms an organization allows. An absent app-password option shouldn't be treated as an SMTP server problem or solved by weakening unrelated security controls.
For the broader account-security context, CloudOrbis guidance on stronger account security is a useful companion resource. Account protection and application authorization serve related purposes, but enabling stronger sign-in protection doesn't automatically authorize every older device.
The practical decision is straightforward:
- OAuth-capable application: Use its supported Google authorization flow and token-based SMTP authentication.
- Password-only device: Check whether app passwords are available and approved.
- Restricted organizational account: Ask the Google Workspace administrator which sending method is permitted.
How to verify it
The mailX SMTP test can separate an accepted encrypted connection from a rejected mailbox login. For OAuth, verification must also occur in an OAuth-capable client using its configured authorization flow; an app-password test doesn't validate the application's token handling.
Which Port and Encryption Pair to Choose
The difference between the supported ports is when encryption begins, not whether encryption matters. Both valid configurations protect the connection, but the client and server must agree on the sequence.
The comparison below shows the supported connection patterns.
What do the client's encryption labels mean
STARTTLS means the client opens an SMTP session and upgrades the connection to TLS before transmitting credentials or message content. Implicit SSL/TLS means the encrypted connection is established before SMTP commands begin.
Some clients label the choices clearly. Others use a generic TLS label, so the administrator must confirm whether that label means an upgrade or encryption from the start.
The protocol settings documented earlier don't describe a third recommended pair for direct Gmail mailbox submission. Selecting an unencrypted mode isn't a workaround for a failed TLS negotiation.
What should happen before authentication
On a STARTTLS connection, the initial protocol exchange enables the upgrade. The client shouldn't transmit passwords or message content over that initial unencrypted connection.
With implicit SSL/TLS, a client expecting a plaintext SMTP greeting can stall because the server expects the encrypted handshake first. Conversely, a client starting an implicit handshake against the STARTTLS endpoint follows the wrong sequence.
Administrators should enforce TLS and retain certificate validation. Disabling certificate checks may hide the immediate failure while removing an important check on the server's identity.
Applications should also configure separate connection and read timeouts. This helps distinguish an endpoint that can't be reached from a session that opens but stops progressing.
How to verify it
The mailX SMTP test checks whether the selected connection mode completes its TLS negotiation. A good result reaches authentication through an encrypted session; a bad result at the handshake stage points back to connection mode, certificate handling, or client compatibility.
Further guidance on checking TLS configuration with mailX helps interpret encryption-specific failures without treating them as password problems.
How Personal Gmail Differs from Workspace Relay
Mailbox submission and organizational relay are different Google sending paths. A personal Gmail account uses mailbox authentication, and an ordinary Google Workspace mailbox can use the same submission model.
Google Workspace SMTP relay is an administrator-configured organizational service. Choosing that endpoint requires the organization's relay policy, not merely a different spelling of the Gmail server.
The diagram separates these paths. For either mailbox-submission branch, the supported credentials are an app password where permitted or OAuth, not the normal account password.
Which endpoint belongs to which sending path
A business email address doesn't automatically mean the application should use relay. The deciding question is whether the application signs in as a mailbox or sends through an approved organizational route.
For mailbox submission, the authentication and encryption choices described earlier remain applicable. Changing to the relay hostname doesn't bypass an unavailable app password or create permission to send.
What is different about relay configuration
Google's Workspace application and device sending guidance distinguishes the relay endpoint and directs administrators toward port 587 with TLS. Non-TLS relay configurations can use 25, 465, or 587, but SMTP authentication is unavailable in that mode and the sending server must be authenticated by IP address.
Those relay options shouldn't be copied into a personal Gmail configuration. Their availability describes an organizational service with its own administrative controls.
Relay can serve controlled sending from approved applications, printers, and internal tools. Administrators evaluating that route should use the dedicated SMTP Relay guide rather than combining relay settings with the mailbox table.
- Mailbox sending: The application authenticates as a specific Google mailbox.
- Organizational relay: An administrator establishes the allowed sending route and its authorization conditions.
- Unclear ownership: The application owner should confirm the intended path with the Google Workspace administrator before changing endpoints.
For either path, check Google's current limits in the official documentation. Account type and the selected service affect which restrictions apply.
How to verify it
The mailX SMTP test can establish whether the configured mailbox-submission connection and login work. A successful mailbox test doesn't validate a separate organizational relay policy; relay must be evaluated against the administrator's approved configuration.
How to Set Up a Gmail App Password
2-Step Verification must be enabled before an app password can be created. That requirement doesn't guarantee that the option will appear: Google Workspace policy and other account-security conditions can affect availability.
Google describes an app password as a 16-digit passcode in its application and device account guidance. The account's current security interface should be checked for the available app-password controls because menu names and locations can change.
What is the setup sequence
An account owner should complete the account-security prerequisites before editing the application's SMTP password field. Otherwise, the client may retain an ordinary password while the administrator assumes an app-specific credential is already in use.
- Confirm the account identity. Open the security settings for the exact Google account the application will use.
- Enable 2-Step Verification. Complete the account's supported verification setup before looking for app-password controls.
- Check availability. If app passwords aren't offered, review account restrictions or ask the Google Workspace administrator.
- Generate an app password. Identify the intended application or device so the credential's purpose remains clear.
- Copy the generated credential. Paste it into the client's SMTP password field, using the complete mailbox address as the username.
- Replace the saved password. Save the revised configuration and ensure the application isn't still using an older stored credential.
Spaces shown in a displayed app password are formatting, not additional characters to preserve in the client's password field. The generated credential should be treated as a secret, not included in screenshots, support tickets, or application logs.
What can prevent creation or use
An app password may be unavailable because the account doesn't meet the security prerequisites or organizational policy blocks it. An existing credential may also fail after revocation, or because the application never replaced its previously saved normal password.
The old less secure apps option has been removed. Searching for that switch or following a legacy tutorial that depends on it isn't a current fix.
For organizations rolling out stronger sign-in protection across staff accounts, IT Cloud Global, LLC provides MFA adoption strategies for small businesses. Application compatibility should be considered alongside that rollout so approved devices have a supported authorization method.
An application capable of OAuth should generally use XOAUTH2 instead of introducing a long-lived app password. Password-only devices need an explicitly permitted alternative when the option isn't available.
How to verify it
After saving the credential, use the mailX SMTP test described below. Accepted authentication confirms that the supplied mailbox identity and credential work together; rejection calls for a credential or policy review, not an automatic port change.
How to Verify a Gmail SMTP Connection
A useful SMTP check separates network connectivity, encryption, and authentication. An application's generic failure message may combine those stages, making a credential rejection look like a connection problem.
The mailX test uses credentials supplied for a mailbox the user controls and doesn't store them. Credentials should still be handled as secrets and kept out of shared diagnostic screenshots.
The test interface provides a place to check the configured connection.
How to verify it
Use the tool to verify SMTP login and TLS against the Gmail submission host. Enter the same port, encryption choice, full mailbox address, and app password saved in the application.
For an OAuth-based application, check token authentication in its OAuth-capable client as well. An independent password-based check can help isolate connection behavior, but it doesn't prove the application has implemented XOAUTH2 correctly.
A good mailbox test establishes:
- TCP connectivity: The test reaches the intended SMTP endpoint.
- Encrypted communication: TLS or STARTTLS completes using the configured connection mode.
- Accepted authentication: Google accepts the submitted mailbox identity and supported credential.
A test that establishes only the first stage isn't a complete SMTP login check. Likewise, accepted authentication should be distinguished from acceptance of a subsequent message.
What does a failed result mean
A timeout suggests where investigation should begin; it doesn't prove a local firewall is responsible. Testing from the application's own environment remains important because a remote diagnostic test doesn't traverse the same local network.
The SMTP finder is appropriate when the hostname itself is unknown. Once the Google sending path is established, repeatedly rediscovering the host won't resolve a rejected credential.
A successful authenticated submission test confirms that the mailbox can use the tested submission path. It doesn't establish Google Workspace relay permission or guarantee that every later message will be accepted.
Common Gmail SMTP Mistakes to Fix
A reachable server can still reject a login. Administrators should correct the failed stage rather than changing every setting after a generic application error.
The patterns below describe configuration failures, not a client transcript or an invented error log. The visual highlights common fields to inspect.
Which mistake matches the symptom
The mailX SMTP test distinguishes an authentication rejection from a connection or encryption failure. The mailX SMTP finder helps identify the intended endpoint when an administrator has copied the wrong Google hostname.
Neither tool can explain every account-policy decision from network behavior alone. If the encrypted connection works but a known credential remains rejected, the account's security settings and Google Workspace policy need review.
Which assumptions make troubleshooting slower
A common assumption is that any SMTP failure means the network path is down. An explicit authentication rejection instead shows that communication progressed far enough for the server to evaluate a login attempt.
Another assumption is that a successful browser sign-in validates an SMTP password. Browser access and application authorization aren't the same check, so repeating an interactive login doesn't establish that the client has the right credential.
- Don't rotate credentials for a handshake failure. First correct the connection mode or certificate problem.
- Don't change ports for an authentication rejection. First review the complete username and supported credential.
- Don't switch to relay without authorization. A different endpoint doesn't supply organizational permission.
Duplicate SPF records, excessive SPF lookups, wrong DKIM selectors, and CNAME-versus-TXT mistakes concern domain authentication rather than this mailbox-login configuration. Those issues shouldn't be used to explain a failure that occurs before SMTP authentication completes.
How to verify it
Repeat the same SMTP check after changing the field associated with the failed stage. A good result progresses past that stage; a failure in the same category indicates that the underlying cause remains unresolved.
Gmail SMTP Questions People Still Ask
Can port 25 replace the Gmail submission ports
Google's documented mailbox-submission configuration uses the encrypted pairs listed earlier. Port 25 shouldn't be substituted just because another SMTP service supports it. Google Workspace relay is a separate service with separate configuration rules, so its available ports don't expand the recommended settings for a personal Gmail mailbox.
Should an app password be reused across devices
A separate app password for each permitted application or device is easier to manage. If a device is retired or a credential needs revocation, the account owner can address that integration without deliberately sharing its replacement across unrelated clients. Organizational security policy should determine whether app passwords are allowed at all.
Does OAuth replace the Gmail SMTP hostname
OAuth changes the authentication mechanism, not the destination of a direct Gmail SMTP connection. The application still connects to the mailbox-submission endpoint and establishes encryption before authenticating. Developers should keep connection setup and token handling separate so a token problem isn't mistaken for a hostname or TLS configuration error.
Does successful authentication guarantee later messages will be accepted
Successful authentication establishes that Google accepted the credential for the tested session. It doesn't authorize unlimited sending or guarantee acceptance of every later message. For volume-related questions, check Google's current limits. Applications should also retain the actual SMTP response when a subsequent submission fails instead of assuming the login stopped working.
mailX provides free SMTP diagnostics with no signup, including checks for connectivity, TLS, and mailbox login. Visit mailX and run the SMTP test with the configured Gmail connection to identify whether a failure concerns the network, encryption, or authentication.