Gmail SMTP Server Settings That Still Work in 2026
Half the gmail smtp server guides on the internet were written before Google turned off password login for third-party apps, and they still rank. Follow one and you get authentication errors that no amount of retyping your password will fix - because your account password stopped being valid for SMTP in 2022, permanently, for everyone.
Here is the current state of smtp.gmail.com: the settings that work, the credentials Google actually accepts now, and the ceilings you inherit the moment you connect.
The settings block, current
| Setting | Value |
|---|---|
| Host | smtp.gmail.com |
| Port | 587 (STARTTLS) or 465 (implicit TLS) |
| Username | your full address, you@gmail.com or you@yourdomain.com |
| Password | a 16-character app password - never your account password |
| Encryption | required; plaintext connections are refused |
Both ports work identically once the TLS handshake completes. 587 starts plain and upgrades with STARTTLS; 465 is encrypted from the first byte. Modern libraries handle either - pick 587 unless your library documentation says otherwise, and never configure 587 with TLS disabled, because Gmail will refuse the login rather than accept it insecurely.
Port 25 is not in the table on purpose: Gmail accepts it in principle for the same submission flow, but residential ISPs and every major cloud block outbound 25 so widely that building anything on it is planning your own outage.
The credential question: what Google accepts now
Three credential types exist, and only two of them work.
- Your account password: refused. Since Google retired what it called less secure app access, the password you type into the Gmail login page is not accepted by the SMTP server under any setting. The error is 535 5.7.8, and it reads exactly like a typo, which is the cruel part.
- An app password: works. A 16-character code Google generates once you have 2-step verification enabled. It goes in your SMTP config in place of the password. Treat it like a key, because it is one - anyone holding it can send as you until you revoke it.
- OAuth 2.0 (XOAUTH2): works, for software that speaks it. The application obtains a token with the mail scope and presents it instead of any password. Better security properties, meaningful integration work. Mail clients like Thunderbird do this invisibly; your homegrown script probably will not.
For a founder wiring up a tool, the app password is the practical path: account, then Security, then 2-Step Verification, then App passwords. If that page refuses to appear, your account has one of a handful of states that hide it - advanced protection, a workspace policy, passkey-only configurations - each with its own unlock.
The ceilings you just signed up for
Connecting to the gmail smtp server puts you under the mailbox's own sending limits, and they are stricter than people assume:
- Free Gmail accounts: up to 500 recipients per rolling 24 hours across everything the account sends.
- Workspace accounts: up to 2,000 recipients per rolling 24 hours, shared between the human's own mail and anything scripts send as them.
- Per message: recipients across To, Cc, and Bcc count individually against the daily number - one message to 50 people spends 50.
The sharing is the trap. A script that sends 1,900 notification emails overnight leaves its human owner 100 recipients for the entire workday, and the lockout error arrives mid-morning with no obvious connection to last night's job. If software needs volume, it should not borrow a person's mailbox to get it - that is what relays and sending platforms are for.
Errors the gmail smtp server actually returns
- 535 5.7.8 Username and Password not accepted - the credential class is wrong: account password instead of app password, an app password that was revoked, or 2FA never enabled. Not a typo, a category error.
- 534 5.7.9 Application-specific password required - Google telling you outright: this account has 2FA, so only app passwords or OAuth work.
- 454 4.7.0 Too many login attempts - back off; repeated failed logins triggered a temporary lock that clears on its own.
- 550 5.4.5 Daily user sending quota exceeded - the mailbox ceiling above; nothing resets until the rolling window rolls.
Each of these names its cause honestly once you know the vocabulary - none of them is fixed by re-entering the same secret harder. When a login fails twice with the same credential, stop and classify the error instead of looping: two identical failures mean the third attempt is wasted, and five of them can escalate a credential problem into a temporary lock that costs you an extra hour of not sending anything at all.
When smtp.gmail.com is the wrong answer
The mailbox door is built for mail that is genuinely from a person: their follow-ups, their small automations, mail that should sit in their Sent folder and thread under their name. The moment the sending is really an application's - receipts, alerts, campaigns, anything measured in hundreds - borrowing a human mailbox couples your software to one person's quota, one person's credentials, and one person's vacation. Workspace domains have the SMTP relay for operational volume, and sending that grows with the business belongs on infrastructure with its own reputation, warmup, and unsubscribe machinery rather than on any single inbox.
The test is one question: if this account's owner left the company tomorrow, should this mail stop? If no, it should not be sending through their mailbox today.
Frequently asked questions
What are the Gmail SMTP server settings?
Host smtp.gmail.com, port 587 with STARTTLS or 465 with implicit TLS, your full email address as the username, and a 16-character app password as the password. TLS is mandatory and your normal account password will not work.
Why does Gmail SMTP reject my password?
Google no longer accepts account passwords for SMTP from any third-party app. You need either an app password (requires 2-step verification) or OAuth 2.0. The 535 5.7.8 error you see is a credential-class problem, not a typo.
Should I use port 465 or 587 for smtp.gmail.com?
Either works: 587 upgrades to TLS via STARTTLS, 465 is encrypted from the start. Pick 587 as the modern default unless your library specifically prefers 465, and avoid port 25 entirely since most networks block it outbound.
How many emails can I send through the Gmail SMTP server?
The mailbox's own limit applies: roughly 500 recipients per rolling 24 hours on free Gmail and 2,000 on Google Workspace, shared with everything else the account sends. Sustained application volume belongs on a relay or a dedicated sending platform instead.