Gmail SMTP Server: Settings, Limits, and Why It Is the Wrong Tool for Apps

The settings are smtp.gmail.com on port 587 with STARTTLS, or port 465 with implicit TLS, authenticating with your full address and an app password rather than your account password.

That covers the configuration, and the configuration is not usually where people get stuck. They get stuck on authentication, because ordinary account passwords stopped working for SMTP some time ago, and then on limits, because a personal mailbox has a daily send cap that an application will find quickly.

So this is the working setup, followed by an honest account of when it is the wrong choice, which is most application sending.

Table of contents

• The settings that work
• App passwords, and why your normal password fails
• The limits that will find you
• Deliverability, which is the deeper problem
• When to use what
• How this fits the rest of the stack
• FAQ

The settings that work

Two valid port choices, and the difference is when encryption starts.

Server:    smtp.gmail.com
Port:      587          (STARTTLS - upgrade an unencrypted connection)
  or       465          (SSL/TLS - encrypted from the first byte)
Username:  [email protected]          (the full address, including the domain)
Password:  an app password        (not your account password)
Auth:      required

Port 587 with STARTTLS is the modern default and the one to use unless a client only supports implicit TLS, in which case 465 is fine and equally secure. Port 25 exists in the documentation and is blocked outbound by most residential and many cloud providers, so treat it as unavailable.

Two configuration mistakes account for most failures. The username must be the complete address, not the part before the at sign. And the connection must be encrypted; a client configured for no encryption will be refused.

Test it before wiring it into anything:

# Does the port answer, and does it advertise STARTTLS?
openssl s_client -starttls smtp -connect smtp.gmail.com:587 -crlf </dev/null 2>/dev/null | head -20

App passwords, and why your normal password fails

This is where most people stop. Your account password will not authenticate for SMTP, and the error message does not explain why.

SMTP has no way to complete a two-factor challenge. Since two-factor authentication became standard, the resolution is an app password: a separately generated credential scoped to one application, revocable independently, that satisfies authentication without a second factor.

Which means the sequence is fixed. Enable two-factor authentication on the account first; the app password option does not exist until you have. Then generate one, and it appears once, so store it immediately.

Treat it as the credential it is. It grants the ability to send as you, so it belongs in an environment variable or a secret store, never in a repository, and it should be revoked the moment it is no longer used. Generating a separate one per application is the point of the feature, since revoking one then does not break the others.

On RunxBuild that means setting it as an environment variable on the service rather than committing it, which also makes rotation a form field rather than a code change.

The limits that will find you

This is the section that matters if you are considering this for an application.

A personal account has a daily send cap in the low hundreds of messages, counted per recipient rather than per message, so one email to fifty people consumes fifty. A workspace account’s cap is higher but still finite, and both are well below what a modest application generates.

Exceeding it does not produce a clear error. The account is temporarily blocked from sending, usually for around 24 hours, and during that window every send fails. If your application does not surface send failures, you discover this from a customer asking why they never received a password reset.

There are also rate limits below the daily cap, and connection limits on simultaneous SMTP sessions, both of which a worker pool sending in parallel will hit before the daily cap becomes relevant.

The practical read: this is fine for a contact form on a small site sending a handful of messages a day. It is not a transactional email system, and the failure mode when you outgrow it is silent and total rather than gradual.

Deliverability, which is the deeper problem

Even within the limits, sending application email through a personal mailbox has a structural deliverability problem.

Receiving servers judge mail on the alignment between the sending domain, the authentication records for that domain, and the reputation attached to it. When your application sends from a personal address, it is borrowing a shared reputation you neither control nor can repair.

Three specific consequences:

• You cannot fix a reputation problem. If deliverability degrades, there is no configuration you own that changes it.
• Sending as your own domain requires proper setup. If you set the From header to your domain while sending through a mailbox that is not authorised for it, SPF alignment fails and DMARC will reject or quarantine the message.
• You get no visibility. No bounce handling, no delivery events, no complaint feedback. A transactional email system tells you what happened to each message; a mailbox does not.

The records that govern this are worth knowing whichever route you take:

; Which servers may send as your domain.
example.com.  IN TXT  "v=spf1 include:_spf.provider.example -all"

; What receivers should do with failures, and where to send reports.
_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Start DMARC at p=none and read the reports for a few weeks before tightening to reject, or you will silently drop mail from a system nobody remembered.

When to use what

Three situations with clear answers.

A personal script, a home automation alert, a form on a hobby site. Gmail SMTP with an app password is entirely appropriate. Low volume, no deliverability stakes, and nothing to configure beyond the credential.

A business sending genuine mail from its own domain. Use a workspace account properly configured with SPF, DKIM and DMARC for that domain. Higher limits, and the reputation is yours to manage.

An application sending transactional email. Use a dedicated sending service. You need bounce and complaint webhooks, delivery events, a sending domain you control, sensible throughput, and an API rather than an SMTP session held open by a worker.

The signal that you have outgrown the mailbox approach is usually one of: you have started thinking about retry logic for failed sends, you cannot tell whether a message arrived, or you have hit the daily cap once. Any of those means the requirement has changed shape.

One implementation note whichever you use: send email from a background job, never inline in a web request. SMTP connections are slow and fail in ways that should not turn into a 500 for the user, and a queued job gives you retries for free.

How this fits the rest of the stack

Email is one of the pieces that is free until it is a dependency, and then it is a service with its own bill sitting beside the compute and the database. Sizing the whole picture is easier when the pieces are visible together, and the RunxBuild hosting calculator covers the hosting half, with the background worker that should be sending your mail being a service like any other on the ladder.

Useful related references:

• Port 587: The SMTP Submission Port, and Why Your App Should Use It
• SMTP Ports Explained: 25, 465, 587, and Which One You Should Use
• Grafana SMTP Settings: Getting Alert Emails to Actually Send
• Services on RunxBuild

FAQ

What are the Gmail SMTP settings?

The server is smtp.gmail.com, on port 587 with STARTTLS or port 465 with implicit TLS. Authenticate with your full email address as the username and an app password rather than your account password. Port 25 is documented but blocked outbound by most providers.

Why does my Gmail password not work for SMTP?

SMTP cannot complete a two-factor challenge, so account passwords are no longer accepted. You need an app password: a separate credential generated for one application, which requires two-factor authentication to be enabled on the account first. The app password option does not appear until it is.

How many emails can I send through Gmail SMTP?

A personal account is capped in the low hundreds per day, counted per recipient rather than per message. Workspace accounts are higher but still finite. Exceeding the cap blocks sending for around 24 hours, and there are also rate and connection limits below the daily figure.

Can I use Gmail SMTP for my application?

For very low volume with no deliverability stakes, yes. For transactional email, no. You lack bounce and complaint handling, delivery visibility, adequate throughput, and control over sending reputation, and the failure mode when you exceed the limit is silent and total rather than gradual.

Why do my emails go to spam?

Usually authentication alignment. If your From header claims your own domain while the message is sent through a mailbox not authorised for it, SPF alignment fails and DMARC policy may reject or quarantine it. Publish SPF and DMARC for your sending domain and start DMARC at p=none while reading the reports.