Gmail SMTP settings: server, port and app password, and what breaks when an agent uses them

The settings, from Google

The Gmail SMTP server is smtp.gmail.com. Use port 587 with STARTTLS, or port 465 with SSL. Authentication is required: the username is your full Gmail or Google Workspace address, and the password is a Google app password, not the password you sign in with. When an AI agent wires this into code, the app password ends up in a repo or a log, and the agent hits Google's sending ceilings before anyone notices. Google publishes a sending limit of 2,000 messages a day on Workspace and around 500 on a personal Gmail account. The table below gives each value with Google's own wording beside it, so it can be checked against the source.

These values are a published constant. For anyone who only needed the settings, that is the whole answer. Before leaving, look at the title of the Google page they come from. Google files the Gmail SMTP server under Send email from a printer, scanner, or app, in a section that opens by warning that “Older scanners or printers might not support OAuth”. Google documents this path as the one to reach for when the sender cannot do anything better.

An AI agent writing the integration falls into the same category as that scanner. It configures exactly what it is asked to, and nobody is sitting beside it. For the general version of this setup on any provider, how to set up SMTP walks through it, and Hotmail SMTP settings has the Microsoft equivalent of this table.

Gmail SMTP password: use a Google app password

If the account has 2-Step Verification enabled, Google's instructions for this exact situation say that “an authentication error appears” and that the fix is to “configure an app password” (Google Workspace Admin Help, Send email from a printer, scanner, or app). So the credential in the SMTP client is not the one used to sign in.

1. Turn on 2-Step Verification. Google is explicit that app passwords “can only be used with accounts that have 2-Step Verification turned on” (Google Account Help, Sign in with app passwords).
2. Open App Passwords in your Google Account security settings and generate one for mail.
3. Use the 16 characters as the SMTP password. Drop the spaces.

Two properties of that credential matter more than the generation steps, and both are in Google's own words. “Every app password can only be checked once”, so there is no way to read it back later. And “we revoke your app passwords when you change your Google Account password”, so the credential dies on a routine security action taken somewhere else entirely, by somebody who was not thinking about the integration.

The longer walkthrough, including what to do when the App Passwords option is missing from the account, is on Gmail app password for SMTP. If the failure is an authentication error rather than a missing password, SMTP authentication covers what the server is actually asking for.

What an AI agent does differently with Gmail SMTP

Three moments in this setup need a person, and an AI agent writing the integration does none of them:

• Generating the app password.
• Granting consent or an Admin console allowlist in its place.
• Noticing when the credential stops working or the daily ceiling trips.

The agent runs unattended, it retries by policy, and it puts the credential wherever the code can read it. Gmail will not let an agent hold an email address of its own, and Google and Microsoft both run aggressive bot detection against external agents, so the agent ends up borrowing a person's mailbox and a person's password. A sending domain the sender owns is the alternative, and the worked example further down shows the move.

Read Google's own guidance on app passwords from the top and the first line is not instructions. It is a recommendation against: “App passwords aren't recommended and are unnecessary in most cases. To help keep your account secure, use ‘Sign in with Google’ to connect apps to your Google Account.” (Google Account Help, Sign in with app passwords)

That advice is right, and it is unavailable to an agent.

Consent. Sign in with Google is OAuth, and Google describes the sequence plainly: “The authorization sequence begins when your application redirects a browser to a Google URL”, after which “the user is asked whether they are willing to grant one or more permissions that your application is requesting.” Google's own answer for hardware with no browser is the limited-input device flow, where the application “shows to the user” a URL and a code, and “the user obtains the URL and code from the device, then switches to a separate device or computer with richer input capabilities” (Google, Using OAuth 2.0 to access Google APIs). That is still a person. An agent running unattended in a terminal or on a schedule cannot produce one, so it falls back to the credential Google opens the page by recommending against.

Scope. An app password is not a permission to send mail. Google defines it as “a 16-digit passcode that gives a less secure app or device permission to access your Google Account.” The agent asked for the credential that makes the send work. What it received was the mailbox, the archive and the contacts. Nobody re-scopes it afterwards, because there is nothing to re-scope it to.

Rotation. A person whose mail client starts asking for a password knows within a day that something changed. An unattended sender discovers a revoked app password at the authentication step of a connection nobody is watching, and what surfaces is a failed job rather than a prompt.

Which Gmail SMTP port to use

Start with 587. The client connects in plain text, issues STARTTLS, and upgrades the connection before any credentials are sent. It is the setting most mail clients and libraries document first.

Use 465 when the client expects SSL from the first byte of the connection, which some older apps and devices do. The settings are otherwise identical. A mismatch, such as STARTTLS on 465 or implicit SSL on 587, usually shows up as a connection that hangs or a handshake error rather than a clear message, which is why it is worth checking first when a working username and app password still fail.

Google also lists port 25, but outbound port 25 is often blocked by ISPs and cloud hosts, so it is the last one to try. SMTP port numbers covers what each port is for, and SMTP TLS covers pairing the encryption to the port. Working code for both ports is on the PHP send mail using SMTP and Python email automation pages.

The ceilings, and who they were sized for

Google publishes two numbers for this path and they are not the same number.

• Google Workspace, through smtp.gmail.com: “The sending limit is 2,000 messages per day.”
• Personal Gmail: the limit message appears when you “send an email to a total of more than 500 recipients in a single email and or more than 500 emails sent in a day”, and Google says “you should be able to send emails again within 1 to 24 hours” (Gmail Help, Limits for sending and getting mail).

Both are ceilings, not targets. The published caps describe what one working person can reasonably send, which is a sensible limit when the sender is a working person and a meaningless one when the sender is a process that never gets tired.

The second ceiling has no number on it. Mail sent through smtp.gmail.com from a personal gmail.com address goes out as a mailbox user on Google's shared infrastructure, so whatever standing it builds belongs to that account and not to a domain the sender owns.

Google asks every sender to keep the spam rate reported in Postmaster Tools below 0.3% and to authenticate with SPF or DKIM. Senders above 5,000 messages a day count as bulk senders and need SPF, DKIM and DMARC. Their DMARC policy can be set to none (Gmail Help, Email sender guidelines).

The 0.3% figure is where blocking starts, so the number worth watching is the headroom beneath it, and DMARC aggregate reports are where unknown sources sending as the domain show up. Inbox providers like Gmail also expect that mail to come from a dedicated sending subdomain rather than the domain people reply to. Email authentication covers the records, and deliverability goes through what accumulates and where it lives.

Google's own recommendation is not this

On the same page, before it documents smtp.gmail.com at all, Google names a different option first: “We recommend using the SMTP relay service to send email from devices or apps. The SMTP relay service authenticates messages with IP addresses, so devices and apps can send messages to anyone inside or outside of your organization. This option is the most secure.”

The relay is smtp-relay.gmail.com, on port 25, 465 or 587, and Google puts the allowance at up to 10,000 recipients per day per user (Google Workspace Admin Help, Send email from a printer, scanner, or app). For a Google Workspace account sending from a server, that is the option to read about, and the Google SMTP relay page covers the setup.

Authenticating by IP means a static address and an allowlist configured in the Admin console by a Workspace administrator, which is a person with privileges an agent does not have and should not be given. Google's third option, the restricted server, “lets your organization send messages to Gmail or Google Workspace users only” and “doesn't require authentication”, which solves the credential problem by removing almost everybody worth emailing.

All three options are coherent. All three were designed around an administrator. The SMTP ports guide has the rest of the hosts and ports for comparing providers, and Outlook and Office 365 SMTP settings covers the Microsoft side.

Worked example: moving signup emails off Gmail SMTP

The reader of this page who has the problem is usually an app, not a scanner: a signup handler that an assistant wired to smtp.gmail.com on port 587 with a personal app password, because that was the first set of working settings it found. Prompt, in the user's words: Our signup emails go through my Gmail app password. Move them off it.

Before. A personal Gmail app password in .env. The handler opens a connection to smtp.gmail.com for every signup. A retry loop around the send, because the SMTP library times out sometimes, and nothing in the loop can tell whether the first attempt already went out.

After. A verified sending domain, a subdomain you own, in place of the personal mailbox. An API key in the secret store instead of a mailbox password in a file. And the sequence below, in this order, with a person at the one step that needs one.

1. nitro_get_status: account context, sender identity and readiness.
2. nitro_manage_domains: add and verify a customer sending domain.
3. nitro_manage_template: create the signup template.
4. nitro_review_delivery on that template: validation, spam analysis, preflight and previews. It never approves or sends.
5. nitro_send_test_message: one real test of the template, delivered to the test recipients set with nitro_configure_account. It never sends to an audience.
6. A person opens the test and checks it. This is the gate.
7. The signup handler sends each message through the transactional email API with an idempotency_key per signup. An agent sending one message itself uses nitro_send_message, and reuses the idempotency_key only for an exact retry.
8. nitro_get_insights: email analytics with trends, benchmarks and recommendations, once the first signups have gone out.

The longer version of this example, built around the credential itself, is on Gmail app password for SMTP. For the agent side of the same move, send email from LLMs covers how a coding assistant or an agent reaches the API, and pricing has the plan limits the handler will run under.

Where it goes wrong when an agent uses Gmail SMTP

Each of these is a normal outcome of an agent doing exactly what the settings table says, with nobody watching.

• The app password leaked into a commit, a log line or a plain-text CI config. The credential is the whole mailbox, not a permission to send, so whoever reads it gets the archive and the contacts too.
• A retry loop that burns the daily sending limit, after which Google stops that account sending until the limit resets. The numbers are in the ceilings section: 2,000 messages a day on Workspace, and the limit message on personal Gmail above 500 emails in a day.
• The agent pairs the wrong encryption with the port (STARTTLS on 465, or implicit SSL on 587), or passes the local part instead of the full address as the username, and authentication fails. The fix is in Which Gmail SMTP port to use.
• The app password can be revoked out from under the handler (when, and how to replace it: Gmail app password for SMTP), and SMTP authentication fails with nothing in the app saying why.
• Product mail tied to a personal account's reputation. Whatever standing the signups build belongs to one gmail.com mailbox, not to a domain the sender owns.
• A signup template the agent wrote and nobody read before the first real recipient got it. nitro_review_delivery and one test message are the gate, and they sit before the first send in the example.
• A retry after a timeout double-sends, because SMTP has no way to say it already sent.

SMTP has no way to say it already sent

RFC 5321, the SMTP specification, sets a ten minute client timeout for the reply after the message body ends, and then explains why that number is generous. In the specification's words: “A spurious timeout at this point would be very wasteful and would typically result in delivery of multiple copies of the message, since it has been successfully sent and the server has accepted responsibility for delivery.” (RFC 5321, section 4.5.3.2.6)

The same document gives the only defense it has, and it is not a client-side one: “To avoid receiving duplicate messages as the result of timeouts, a receiver-SMTP MUST seek to minimize the time required to respond to the final <CRLF>.<CRLF> end of data indicator.” (RFC 5321, section 6.1) The protocol's answer to duplicate sends is that the server should hurry up. There is nothing the client can present on a second attempt that says “this is the same message as the one before”.

A person does not need one. A person who is unsure whether a send went through checks the Sent folder. An agent has no Sent folder and no instinct, and retrying a call that did not return is the correct, well-behaved thing for a client to do. So the exact combination that SMTP is least equipped for, a timeout after the server committed and a client that retries by policy, is the normal operating behavior of the software now writing integrations.

The Nitrosend send takes an idempotency key for this reason. An application sends each message through the transactional email API with an idempotency_key, and an agent sending one message with nitro_send_message reuses that key only for an exact retry, so the second attempt can say it is the same message as the first. An SMTP transaction has no field for that.

For weighing the two submission paths on their merits rather than on familiarity, SMTP versus an HTTP API lays out the rest of the differences, and the transactional email API page shows the call itself.

Why there is no Nitrosend SMTP host

There is no Nitrosend SMTP host to point a client at. The documented submission surfaces are the REST API, the SDK, the MCP server and the CLI. Anyone here for a host and a port to paste into PHPMailer or Nodemailer in place of Gmail's will not find one.

SMTP was specified for mail transfer between systems that a human administered. Judged as an interface for something that is not a human, it has three properties Nitrosend chose not to inherit.

• Credential. A username and a password, presented in full on every connection, scoped to whatever the account can do. What an agent should hold is a key that was issued for one job and can be taken away without touching anything else, which on the API is a bearer token in an Authorization header.
• Retry. The transaction has nowhere to put an idempotency key, so a retry is a gamble rather than a question. Of the three, this is the one that matters most to an agent.
• Errors. Three digit codes with free text that every server words differently, so a client ends up parsing English to find out what went wrong. A structured response that names the field is not a nicety when the thing reading it is deciding whether to try again.

What replaces the settings table, in short: no host and port to configure. A person signs in once, which is the one place a human genuinely belongs. Then the same agent runs campaigns and flows over MCP while the application fires receipts and password resets over the email API, from a separate sending subdomain, which is what stops a large promotional send dragging down receipts and password resets. Language by language examples are on send email programmatically, and the free plan is 5,000 emails up front and then 500 a month.

Gmail's settings at the top of this page are correct and they will keep working. Use them for what they are for, which is a device or a script that a person set up and a person will notice going quiet.

FAQ

Go deeper