Gmail SMTP settings, and what they cost an agent

The settings, from Google

Gmail's SMTP settings are a published constant. They have not moved in years, every page that lists them lists the same values, and here they are with Google's own wording beside each one so you can check the source rather than trust me.

That is the whole answer, and if it is all you came for you can stop reading. Before you do, look at the title of the page those values 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”. That filing is the most useful thing on this page. Google documents this path as the one you reach for when the sender cannot do anything better.

The rest of this page is about what happens when the thing that cannot do anything better is not a scanner. It is an AI agent, writing the integration for you, and it will configure exactly what you ask it to.

The password is not your password

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

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 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 your integration.

The longer walkthrough, including what to do when the App Passwords option is missing from the account, is on the Gmail app password page. If the failure you are looking at is an authentication error rather than a missing password, SMTP authentication covers what the server is actually asking for, and SMTP TLS covers pairing the encryption to the port.

Every step above assumes a person is sitting there

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. Three moments in the Gmail SMTP path need a human, and none of them is labeled as such.

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.” A browser, a screen, a person, a click. 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.

I wrote something blunter than any of this on the day we shipped agentic sending: “Gmail is agent hostile and expensive per seat, and every email platform ever built assumes a human sitting in a dashboard.” The app password is the cleanest proof of the first half. It is a workaround Google maintains for devices that cannot do the secure thing, and an agent is now in that category for reasons that have nothing to do with how capable it is.

There is a related asymmetry worth naming, because it decides more architectures than the port number does. The line I used when we launched agent inboxes was “Gmail won't let an agent hold an address. Your domain on Nitrosend will.” That is not a settings problem and no configuration on this page fixes it.

SMTP has no way to say it already sent

This is the part that is specific to agents, and it is in the protocol rather than in anybody's product.

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 your integration.

We learned that lesson on our own tool surface rather than on SMTP. A delete call timed out after the database had already committed, the client retried, and the retry came back as a not-found, because the first attempt had in fact worked. Nothing was broken. The client simply had no way to ask whether the thing had already happened, and an idempotency key would have turned the retry into a clean no-op.

So the send endpoint takes one. A POST to /v1/my/messages accepts an Idempotency-Key header, and the documented behavior is exact: reusing the same key with the same payload returns the original message, and reusing the key with a different payload returns 409 idempotency_conflict. The agent retries, the recipient gets one email, and the second call tells you which of the two things happened. That is the whole feature, and it is the thing an SMTP transaction has no field for.

If you are 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.

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 were sized for an outbox. They describe what one working person can reasonably send, which is a sensible ceiling when the sender is a working person and a meaningless one when the sender is a process that never gets tired. The constraint that used to hold volume down was how long it took to produce an email, and that constraint is gone. The email marketing guide works through what replaces it, because the answer is a decision you now have to make on purpose.

The second ceiling has no number on it. Mail sent through smtp.gmail.com goes out as a mailbox user on Google's shared infrastructure, so whatever standing you build belongs to that account and not to a domain you own. Google asks bulk senders to keep the spam rate reported in Postmaster Tools below 0.3% and to authenticate their sending domains with SPF and DKIM, and above 5,000 messages a day to publish DMARC as well, at an enforcement policy that may be set to none (Gmail Help, Email sender guidelines). Those requirements are written for a sender with a domain. An app on a personal mailbox is not one, which means the work you put into deliverability there does not accumulate anywhere. Deliverability goes through what does accumulate 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. If you run Google Workspace and you are sending from a server, that is the option to read about, and the Google SMTP relay page covers the setup.

Note what it costs, though, in the terms this page cares about. 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 your 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 you wanted to email.

All three options are coherent. All three were designed around an administrator. The SMTP ports guide has the rest of the hosts and ports if you are comparing providers, and SMTP port numbers covers what each port is actually for.

Why there is no Nitrosend SMTP host

I should say this plainly on a page that ranks for SMTP settings, because being vague about it would be worse than being unhelpful. 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. If you are here looking for a host and a port to paste into PHPMailer or Nodemailer and swap for Gmail's, we do not have one to give you.

That is a decision, and everything above is the reason for it. 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 we did not want to inherit.

The credential is 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.

The transaction has nowhere to put an idempotency key, so a retry is a gamble rather than a question. That is the one I would not trade away.

And the errors are 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, if you want the short version: point your agent at the install skill at nitrosend.com/SKILL.md and it connects itself, with no API key to paste and no host and port to configure. You sign in once, which is the one place a human genuinely belongs. Then the same agent runs campaigns and flows over MCP while your 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 your receipts and password resets. Language by language examples are on send email programmatically, and the free plan is 8,000 emails up front and then 500 a month, which is enough to find out whether any of this argument holds.

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. The moment the sender is something that runs without you, the question stops being which port and becomes which credential, what happens on a retry, and who finds out when it fails.

FAQ

Go deeper