Gmail SMTP Setup Guide: Settings, App Passwords, Limits and Fixes

Gmail SMTP settings

Here are the values you need. Everything else in this guide explains how to make them work.

Server:      smtp.gmail.com
Port:        587  (STARTTLS)   or   465  (SSL/implicit TLS)
Username:    your full email address, e.g. you@gmail.com
Password:    a 16-character app password (not your account password)
Encryption:  required
Auth:        LOGIN / PLAIN over TLS, or XOAUTH2

Both ports work identically well. Use 587 unless your library handles implicit TLS more cleanly.

Why your normal password will not work

Google stopped accepting account passwords for SMTP when it retired "Less secure app access" in 2022. Every SMTP client now needs either an app password or an OAuth 2.0 token. If you are seeing 535-5.7.8 Username and Password not accepted, this is almost certainly why.

Creating an app password

App passwords require 2-Step Verification on the account. If the option is missing from your Google Account settings, 2-Step Verification is not enabled yet — turn it on first.

1. Go to your Google Account → Security.
2. Enable 2-Step Verification if it is not already on.
3. Open App passwords (search for it in the account settings search bar; the link moves periodically).
4. Enter a name that identifies the application, for example "Billing service".
5. Google displays a 16-character password in four groups of four.
6. Copy it and remove the spaces — they are display formatting only.
7. Store it in your secret manager. Google will never show it again.

Create one app password per application. When you rotate or revoke one, nothing else breaks.

Google Workspace considerations

Workspace accounts add an administrative layer that personal Gmail does not have.

• App passwords can be disabled tenant-wide. An admin controls this under *Security → Access and data control → Less secure apps*. If app passwords are blocked, OAuth is the only path.
• SMTP relay is available for high-volume sending under *Apps → Google Workspace → Gmail → Routing → SMTP relay service*. It supports IP-based authentication and much higher limits than user submission.
• IP allow-lists can be configured so only your servers can relay.
• Restricted delivery settings may prevent sending to external domains — check this if internal mail works and external mail does not.

For Workspace, using smtp-relay.gmail.com on port 587 with an IP allow-list is the supported production pattern. It avoids per-user credentials entirely.

OAuth 2.0 with XOAUTH2

For production systems that send on behalf of users, OAuth is the right approach: tokens are scoped, expire naturally, and can be revoked per user without touching a password.

The flow:

1. Create a project in Google Cloud Console and enable the Gmail API.
2. Configure the OAuth consent screen and request the https://mail.google.com/ scope.
3. Create OAuth client credentials and complete the authorisation flow to obtain a refresh token.
4. Exchange the refresh token for an access token before each sending batch.
5. Authenticate with the XOAUTH2 mechanism.

The XOAUTH2 payload is a Base64-encoded string of the form:

user=you@example.com^Aauth=Bearer <access_token>^A^A

where ^A is the \x01 control character. Most mature libraries construct this for you — you supply the address and token.

Access tokens last about an hour. Refresh proactively rather than waiting for a 535, and cache the token so you are not calling the token endpoint on every message.

Sending limits you need to plan around

Additional constraints:

• The daily counter is a rolling 24-hour window, not a midnight reset.
• Each recipient on a message counts individually toward the limit.
• Exceeding the limit locks sending for up to 24 hours and returns 550 5.4.5 Daily sending quota exceeded.
• Maximum message size is 25 MB including attachments and encoding overhead. Base64 encoding adds roughly 33 percent, so a 20 MB file will not fit.

Gmail is not a bulk email platform. If you are sending marketing campaigns or more than a couple of thousand transactional messages a day, use a dedicated provider. Gmail's limits and abuse controls are not designed for that workload, and hitting them repeatedly can suspend the account.

Fixing the common errors

### 535-5.7.8 Username and Password not accepted

• Using the account password instead of an app password. Generate one.
• Spaces left in the 16-character app password. Remove them.
• Username missing the domain. Use the full address.
• App passwords disabled by a Workspace admin.
• Account newly created — Google sometimes blocks SMTP for the first 24 hours.

### 534-5.7.14 Please log in via your web browser

Google flagged the sign-in as suspicious, usually because the server is in a different country from your normal activity. Sign in from a browser once, complete any verification prompt, then retry. For a headless server, switch to OAuth — this error does not occur with tokens.

### 550-5.7.1 Daily sending quota exceeded

You hit the limit. Wait for the rolling window to clear and move volume to a transactional provider.

### 421-4.7.0 Try again later

Temporary rate limiting from too many connections or too rapid a send rate. Reduce concurrency to two or three connections, add exponential backoff, and reuse connections instead of reconnecting per message.

### 550-5.7.26 Unauthenticated email is not accepted

You are sending as a custom domain without proper SPF/DKIM alignment. Configure authentication for that domain, or send as the Gmail address itself.

### Connection times out

Port 587 or 465 is blocked by your network. Cloud providers and corporate firewalls commonly filter outbound mail ports. Test from the same environment your application runs in.

Sending as a custom domain

Gmail lets you send as you@yourcompany.com through the "Send mail as" feature. Two important caveats:

First, you must verify ownership of the address. Second, and more importantly, if that domain has a DMARC policy of quarantine or reject, mail sent this way may fail alignment unless the domain's SPF record includes Google. Add:

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

and configure DKIM signing for the domain in the Workspace admin console. Without both, your own DMARC policy will reject your own mail — a genuinely confusing failure mode.

Security practices

• One app password per application, named clearly, revoked when the application is retired.
• Never commit credentials. Use a secret manager and inject at runtime.
• Prefer OAuth for anything long-lived or multi-user.
• Audit the app password list quarterly and remove anything you no longer recognise.
• Enable security alerts so you are notified of unusual sign-in activity.
• Never disable certificate verification to work around a TLS error.

When to move off Gmail SMTP

Gmail SMTP is excellent for low-volume, internal, or development use. Move to a transactional provider when you need any of the following:

• More than about 500–2,000 messages per day.
• Delivery, bounce and complaint webhooks.
• Per-message tracking and analytics.
• Dedicated IPs and reputation isolation.
• Template management and scheduling.
• A support channel when deliverability drops.

Providers like SendGrid, Postmark, Mailgun and Amazon SES all offer SMTP relays, so the migration is a configuration change rather than a rewrite.

Verify before you deploy

Configuration errors with Gmail are easy to make and produce error messages that point in the wrong direction. Before shipping, run smtp.gmail.com on your chosen port through SMTPTester with the exact credentials your application will use. In a few seconds you will know whether the port is reachable, TLS negotiates, and the app password is accepted — and if it is not, you will see the raw server reply rather than your framework's paraphrase of it.