Gmail SMTP Settings (2026): Host, Port, App Passwords, and Limits

Gmail SMTP settings

Here are the values you came for. Point your app or client at these to send through a Gmail or Google Workspace account:

• SMTP server: smtp.gmail.com
• Port (TLS): 587 (recommended)
• Port (SSL): 465 (legacy, still works)
• Encryption: STARTTLS on 587, SSL on 465
• Authentication: required
• Username: your full Gmail address, e.g. [email protected]
• Password: a Google App Password, not your normal login password

You almost certainly need an App Password

This is the part that breaks setups. As of May 2025, Google removed "less secure app" access. If your account has 2-Step Verification turned on, and Google turns it on for most accounts now, your regular password will be rejected by the SMTP server.

To get an app password:

1. Turn on 2-Step Verification if it isn't already.
2. Go to your Google Account security settings and open App Passwords.
3. Generate a new 16-character password for "Mail".
4. Use that string as the SMTP password. Drop the spaces.

Store it somewhere safe. Google will only show it once, and if the account owner changes their main password or revokes it, the app password dies with it.

The limits nobody mentions until they hit them

Gmail SMTP is a personal-mailbox path wearing a sending-server costume. It carries the limits of a mailbox:

• Consumer Gmail: roughly 500 recipients per day.
• Workspace: around 2,000 per day.
• Reputation you don't own: you're sending on Google's shared infrastructure under your own address, which isn't authenticated for a domain you control.

For a contact form, a cron that emails you, or a script that pings a handful of people, that's plenty. For a product sending receipts, password resets, or confirmations to customers, you'll hit the ceiling and the deliverability wall at the same time.

When Gmail SMTP stops being enough

I've watched this happen to a lot of teams, and to us. Gmail SMTP works right up until it doesn't, and the failure is quiet: sends start landing in spam, or the daily cap silences your app mid-flow, and you find out from a customer, not a log.

The move at that point is your own authenticated sending domain with SPF, DKIM, and DMARC, on infrastructure built to send. That's not a Gmail setting. That's a different category of tool.

We took a strong position on this at Nitrosend: we deprecated Gmail sending entirely. Not because it can't send a test email, but because building a product on a mailbox's reputation is a trap. Google enforces a 0.30% spam-complaint block threshold on bulk senders, and once you cross it you're not tuning settings anymore, you're locked out. We'd rather grade your domain against that threshold and give you headroom than let you learn it the hard way.

The honest version: Gmail SMTP is a great way to send your first email and a bad way to send your ten-thousandth.

The faster path

If the reason you're wiring up Gmail SMTP is "I need my app or agent to send email," you can skip the mailbox entirely. Connect an account from inside Claude, Codex, or Cursor, send your first 8,000 emails from a shared sandbox, then verify your own domain when you're ready to scale. No host, no port, no app password to regenerate.

The settings above still work if you want them. But if the endgame is reliable sending, starting on Gmail SMTP just means migrating off it later.

FAQ

What are the Gmail SMTP settings?

Server smtp.gmail.com, port 587 with TLS (or 465 with SSL), authentication on, username is your full Gmail address, and the password is a Google App Password.

Why does Gmail reject my password over SMTP?

Because 2-Step Verification is on and Google no longer accepts your normal password for SMTP. Generate a 16-character App Password in your Google security settings and use that.

What is the Gmail SMTP sending limit?

Roughly 500 recipients per day on consumer Gmail and about 2,000 per day on Google Workspace. Cross it and sending is paused for the rest of the day.

Should I use Gmail SMTP for my application?

For very low volume, it's fine. For a product sending to customers, no. You'll hit daily caps and deliverability limits on a reputation you don't control. Use an authenticated sending domain on a dedicated service instead.