Gmail App Password for SMTP: How to Create and Use It

What Google says it is

If smtp.gmail.com just rejected your account password, the credential you need is a 16-digit app password, and the walkthrough is in the next section. Google's own definition of that credential is broader than the one most people configuring an SMTP client have in mind.

Google Account Help puts it in a single sentence. An app password is "a 16-digit passcode that gives a less secure app or device permission to access your Google Account" (Google Account Help, Sign in with app passwords). Not permission to send mail. Permission to access the account.

That distinction has no interface anywhere. Creating one asks you for a name and hands back sixteen characters. The name is a label so you can find the row again later. It is not a scope, it is not carried in the credential, and it restricts nothing. An entry called "invoice sender" and an entry called "everything" have exactly the same authority, which is all of it.

Generate the app password and configure SMTP

The short version, in order:

1. Turn on 2-Step Verification on the Google Account that will send.
2. Open App Passwords in the account's security settings, generate one and name it for the app or script that will use it.
3. Copy the 16 characters and drop the spaces. Store them now: Google shows each app password once.
4. In the SMTP client, use the full Gmail address as the username and the app password as the password, never the account password.
5. If the client still reports an authentication error, SMTP authentication covers what the server is asking for.

Server smtp.gmail.com, port 587 or 465: full Gmail SMTP settings.

Generate it

Turn on 2-Step Verification first. Google is explicit that app passwords "can only be used with accounts that have 2-Step Verification turned on", and the App Passwords screen does not appear in your security settings until it is on. That is the most common reason people cannot find it. You switch on a second authentication factor in order to mint a credential whose function is to skip it.

If the screen is still missing on a Google Workspace account once 2-Step Verification is on, your administrator is the next stop rather than your own security settings.

With 2-Step Verification on, generate the password from Google's app passwords page and name it for the thing that will use it. Google shows the passcode in four groups of four for legibility. The spaces are presentation, not part of the credential, so strip them before you paste.

Store it before you close the dialog, and store it where a secret belongs rather than where a password belongs. Google's wording is "Every app password can only be checked once." There is no read-back and no recovery, only replacement, and replacement needs someone signed in to that Google Account.

Revoke from the same screen. Google's instruction is to "find the one whose password you want to revoke" in the list and remove it, and the only thing in that list to find it by is the name a human typed. If nobody typed a useful one, whoever inherits the account has to guess which entry production depends on.

Configure the SMTP client

The server is smtp.gmail.com. Use port 587 with STARTTLS, or port 465 with implicit TLS, and match the port to the encryption mode rather than mixing them. The full settings table, in Google's own wording, is on Gmail SMTP settings.

The username is the full Gmail or Workspace address including the domain. The password is the 16-digit app password, not the account password.

Authentication happens after the connection is encrypted. A client attempting AUTH before completing STARTTLS on port 587 is refused, and that refusal looks like a credential error rather than a sequencing one. So the first thing people do is regenerate a password that was never the problem. SMTP authentication covers what the server is asking for at that point.

What an agent does differently with an app password

A person types an app password into one mail client and forgets about it. An AI agent or a coding assistant treats it as one more secret to wire into code. It writes it into a .env file, a config file, a test script or a CI variable, runs the send on a schedule nobody watches, and retries when Google says no.

Nitrosend co-founder George Hartley has described the wider pattern: every agent you run today borrows your email address, signs up for things as you, and lands every reply in your inbox for you to sort out. An app password is the most direct form of that borrowing. The agent is not handed a permission to send mail. It is handed your Google Account.

An app password in a repository, a container image, a CI log or a stale .env file is therefore an account exposure, with the mail, the archive and everything else that account can reach inside it. Containing it runs like this:

1. The agent leaks the app password into a commit or a log.
2. Google's instruction for an exposed account is to "change your password immediately for: Your Google Account" (Google Account Help, Secure a hacked or compromised Google Account).
3. Changing the account password revokes every app password on that account, not only the leaked one, so every other integration on the mailbox stops at the same moment.

Removing the single entry instead leaves the account password alone. That stops the leaked credential, but it does not undo what the credential could reach while it was out. Either way, the credential belongs to a person's Google Account rather than to the system, and events the system cannot see can revoke it.

Worked example: moving signup emails off a Gmail app password

The prompt, in the user's words: "Our signup emails go through my Gmail app password. Move them off it."

Before. Unguided, an agent keeps the shape it found. The personal app password stays in .env, the signup handler keeps connecting to smtp.gmail.com, and a retry loop wraps the send. One bad afternoon of errors runs into Google's daily cap and blocks the account.

After. With the Nitrosend MCP server connected, the agent works through the calls in this order:

1. nitro_get_status gets the current account context, sender identity and readiness, so the agent knows what is already set up.
2. nitro_manage_domains adds and verifies a customer sending domain, a subdomain you own, in place of the personal mailbox.
3. nitro_manage_template creates a reusable email template for the signup email.
4. nitro_review_delivery runs a read-only review of that template, with validation, spam analysis, preflight and previews. It never approves or sends.
5. nitro_send_test_message sends one real email test for the template. It never sends to an audience. This is the approval gate: a person reads the test email before anything goes live.
6. nitro_send_message sends one transactional email now, with an idempotency_key that is reused only for an exact retry. In the app, the signup handler makes the same kind of send through the REST API with an nskey_live_ API key.
7. nitro_get_insights gets email analytics once the first real signup emails have gone out, so the agent can confirm the new path is sending.

The end state is a verified domain and an API key that belongs to the system, with no personal credential in the repository. The owner of the Gmail account can then change their password without breaking signup mail, and the old app password can be removed from Google's list once the new path has sent its first real signup email.

Where it goes wrong when an agent holds the password

The setup guides stop at the paste. An app password has no expiry date and no renewal cycle, so it works until one of these events ends it, and an agent keeps running after it does.

• The password leaks into a commit or a log. An agent that wires the credential into code can commit the .env file, print the password in a debug line or paste it into a CI log. That is an account exposure, as the section above sets out.
• A retry loop burns Google's daily cap. An agent that reads an SMTP error as a reason to try again can push a personal account past Gmail's limit of 500 emails a day, and everything else that sends from that account stops too (ceilings below).
• Somebody changes the Google Account password. This is the documented design: "To help protect your account, we revoke your app passwords when you change your Google Account password." A routine rotation or a prompt after a suspicious sign-in is enough.
• Somebody turns off 2-Step Verification. Google warns that "if you use app passwords to let apps access your Google Account, you may get errors when you turn off 2-Step Verification" (Google Account Help, Turn off 2-Step Verification).
• Somebody tidies the list. Entries are identified only by the name typed at creation, so the person removing stale ones cannot tell which one the production sender uses.
• An administrator revokes it. On Google Workspace, Google tells administrators to revoke a user's app password "if a user loses a device or stops using an app that was authorized with that password" (Google Workspace Admin, Manage a user's security settings). On a personal gmail.com account there is no administrator, so sending rests on one individual keeping access to their account.
• Product mail rides on a personal account's reputation. Signup and receipt mail sent this way goes out as one person's mailbox, so its standing belongs to that Google Account and not to your domain. Sending through a connected Gmail or Outlook inbox shifts the reputation risk onto the user rather than the platform.
• Nothing reports its state. An app password has no status endpoint, no expiry to plan a rotation around, no webhook when it is revoked and no machine-readable list. The only test is to send an email, which spends the sending allowance.

A person meets any of these as a password box and fixes it in a minute. An unattended sender meets an authentication failure at the AUTH step of a connection nobody is watching, and an agent may retry it, log it or swallow it.

Ceilings sized for a person

Google publishes a limit for this path and it is a human-sized one. On a personal account the block 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). Google Workspace publishes its own separate numbers for the relay path.

Mail sent this way authenticates as an individual mailbox on shared infrastructure, so it goes out as that address and whatever standing it earns belongs to that Google Account. It cannot send as your domain unless the mailbox is on your domain, and even then the history accrues to the mailbox. None of the work you put into deliverability on this path accumulates anywhere you can take with you.

What a machine should hold instead

There is no Nitrosend SMTP host to swap Gmail's for. The documented submission surfaces are the REST API, the SDK, the MCP server and the CLI. A reader looking for a replacement host and port will not find one here, and the sections above are the reason.

The MCP route removes the long-lived secret altogether. A supported MCP client opens a browser for a Nitrosend sign-in once, and from then on the client manages the bearer token. No secret is pasted into a config file, so there is nothing to leak, inherit or guess the purpose of.

Where a REST key is the right tool, it is an nskey_live_ key created and removed under Settings, API Keys. It is a different object from anybody's sign-in password, so revoking it touches nothing else, and nobody's routine password change touches it.

The sender identity moves too. Instead of an individual's mailbox you verify a sending subdomain you own. Nitrosend's documentation says to always send from a subdomain rather than your primary domain, because "it keeps your corporate mail untouched" and your primary domain already has authentication set up for your team's inboxes. Nitrosend generates the DNS records and verifies them automatically once they resolve, which takes anywhere from a few minutes to a couple of days depending on your DNS provider. The reputation that follows stays with the domain, which a mailbox cannot offer.

Gmail keeps doing what Gmail is for: your team's mail, on your primary domain, untouched by any of this. The email API shows the call, and send email programmatically has it language by language. The transactional email API covers signup and receipt mail specifically, and sending email from LLMs covers the agent side.

If a person will be sitting there when things change, an app password is the right credential and it works well. Once the sender runs without a person, the question stops being which port and becomes who can revoke this, how would anyone find out, and what else goes down with it.

Gmail app password SMTP questions

Why can't I find the App Passwords option? Google only shows the App Passwords screen once 2-Step Verification is turned on, because app passwords can only be used with accounts that have it on. That is the most common reason the option is missing. On a Google Workspace account where it is still missing afterwards, the administrator controls it, so ask them rather than searching your own settings.

Do I type the spaces in the 16-digit app password? No. Google shows the passcode in four groups of four so it is easier to read. The spaces are presentation and not part of the credential, so strip them before you paste it into the SMTP client. Store it straight away, because Google lets you check each app password once only.

Which server and port does it work with? smtp.gmail.com on port 587 with STARTTLS, or port 465 with implicit TLS, with the port matched to the encryption mode. The username is the full Gmail or Workspace address including the domain. The password is the app password, not the account password, and the client must finish STARTTLS before it sends AUTH.

Should an AI agent hold a Gmail app password? It can, but Google defines the credential as permission to access the Google Account, so the agent holds the whole account rather than a sending permission. It also inherits Gmail's personal limit of 500 emails a day. For product mail, an agent is better off sending from a verified domain through an API key or an MCP sign-in.

Does Nitrosend offer an SMTP server to use instead? No. There is no Nitrosend SMTP host. Sending goes through one of four surfaces: the REST API, the SDK, the MCP server or the CLI, from a sending subdomain you verify. Nitrosend generates the DNS records and verifies them once they resolve, which takes from a few minutes to a couple of days.

Go deeper