Gmail SMTP settings: ports, app passwords and real sending limits

For almost every client and script, the answer is: host smtp.gmail.com, port 587, STARTTLS, username is your full email address, password is a 16-character app password — not your account password. Port 465 with implicit TLS works just as well if your library prefers it. Everything else on this page is the part that goes wrong.

The settings, in one table

Port 25 is not a Gmail submission port and most hosting providers and consumer ISPs block outbound 25 anyway. If a tutorial tells you to use port 25 with Gmail, it is years out of date.

Why you need an app password, and how to get one

Google turned off password-based access for third-party apps on personal accounts in 2022. Your normal account password will be rejected with 535-5.7.8 Username and Password not accepted. The two supported options are OAuth 2.0 (what a proper integration uses) and an app password (what a script or legacy client uses).

App passwords require 2-step verification on the account. The order is:

1. Turn on 2-step verification in your Google Account security settings.
2. Open the app passwords page from that same security section.
3. Name the password after the thing that will use it — "warm-up tool", "CRM", "cron job".
4. Copy the 16 characters. Google shows them once. Paste them without the spaces.
5. Store them as a secret, never in a repo or a client-side bundle.

If the app passwords option is missing, it is almost always because 2-step verification is off, the account is managed and an administrator has disabled app passwords, or the account uses Advanced Protection.

Testing before you blame the code

Prove the transport works independently of your application:

openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:587

You should see a 250 capability list including STARTTLS and AUTH LOGIN PLAIN XOAUTH2. If that handshake succeeds and your app still fails, the problem is credentials or library configuration, not the network. Useful failures to recognise:

• 535-5.7.8 Username and Password not accepted — account password used instead of an app password, or spaces left in the app password.
• 534-5.7.9 Application-specific password required — same cause, stated more helpfully.
• 550-5.7.1 Daily user sending limit exceeded — you hit the cap; see below.
• 555 5.5.2 Syntax error — your library is sending a malformed envelope address.

Google Workspace SMTP relay is a different service

smtp.gmail.com authenticates one mailbox and is meant for that mailbox's own mail. smtp-relay.gmail.com (ports 587, 465 or 25 inside Google's network) is the Workspace relay, configured by an administrator under the Gmail routing settings. It exists for application mail — invoices, notifications, alerts — and it can be locked to a list of sending IP addresses instead of per-mailbox credentials. It also allows sending as any address on your verified domains, which the per-mailbox server does not.

Choose the relay when an application sends on behalf of the whole domain. Choose smtp.gmail.com when a person's mailbox sends.

From-address rewriting will surprise you

Gmail will not let you send as an arbitrary address. If the From header is not the authenticated mailbox or a verified alias added under *Send mail as*, Gmail rewrites or rejects it. A whole class of "why does my app's mail show the wrong sender" tickets is this rule, and the fix is to verify the alias first, or to use the Workspace relay.

Authentication of what you send

Mail leaving through Google is DKIM-signed, but by which domain matters for DMARC. On Google Workspace you must generate a DKIM key in the Admin console (the default selector is google) and publish it as google._domainkey.yourdomain.com; until you do, Google signs with gmail.com and your domain gets no aligned DKIM. Your SPF record needs include:_spf.google.com, inside a single TXT record:

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

Remember SPF's hard ceiling of 10 DNS lookups per evaluation — include:_spf.google.com consumes several of them on its own, so do not stack five ESP includes on top of it.

The limits

Google publishes per-account caps and enforces them without warning. Treat the headline numbers as ceilings, not targets: a free gmail.com account is limited to a few hundred recipients a day, a Workspace mailbox to a few thousand, and the Workspace relay to a higher per-domain figure. Hitting the cap returns a 550 and locks sending for roughly 24 hours. Two practical consequences:

• Never spread one campaign across the full daily cap of a brand-new mailbox. New mailboxes get filtered harder than old ones regardless of what the cap allows.
• Build retry logic that recognises the daily-limit 550 and stops, rather than hammering the server and compounding the reputation damage.

What not to do

• Do not use Gmail SMTP as a bulk mail transport. It is a mailbox, not an ESP, and Google's filters treat high-volume mailbox sending as exactly what it looks like.
• Do not disable certificate verification to "fix" a TLS error. Fix the trust store.
• Do not reuse one app password across six tools; you lose the ability to revoke one of them.
• Do not use POP3 if anything else touches the mailbox. POP's default behaviour of downloading and removing mail makes multi-client setups lose messages. IMAP is the correct choice unless you have a specific archival reason.

MailPilot connects Gmail and Google Workspace mailboxes over OAuth, so there is no app password to rotate, and it checks SPF, DKIM and DMARC on the sending domain before warm-up starts — including whether Google is signing with your domain or with gmail.com.