Gmail app password SMTP setup explained: the 2-Step Verification rule, the ports, the restrictions, and when OAuth is the safer choice.

What a Gmail app password is

A Gmail app password SMTP connection is the older way to let a sending tool or CRM send mail through your mailbox. Instead of a login screen, the tool signs in with your address and a passcode. Google calls that passcode an app password.

Google's own wording is short. An app password is a 16 digit passcode that gives a less secure app or device permission to access your Google Account, and it can only be used with accounts that have 2-Step Verification turned on.

Google is equally blunt about when to use one. Its help page says app passwords are not recommended and are unnecessary in most cases, and that "Sign in with Google" is the way to connect apps to your account.

So the honest framing for a sales or marketing team is this: an app password is a fallback for tools that have not implemented OAuth yet. It works, it is supported, and it deserves the same care as any other password.

When an app password is needed, and when it is not

Before you generate anything, look at the connection screen in the tool you are wiring up. The screen tells you which world you are in.

• There is a Sign in with Google button: use it. The tool gets a scoped OAuth token, you never type a password into it, and you can withdraw access from your Google Account later.
• The screen asks for server, port, username and password: that is SMTP authentication. With 2-Step Verification on, your normal password will not work, so an app password is the supported answer.
• The tool sends through its own infrastructure: many sequencers and email marketing campaign platforms relay mail themselves and only need your domain records, not your mailbox.
• The device is a scanner or printer: Google's admin help lists exactly this case and offers OAuth, an alternative sending method, or an app password for the device.

Google's guidance is to not create an app password unless the app or device you want to connect does not have Sign in with Google. That rule alone removes most of the requests that land on an IT desk.

Two step verification is a prerequisite

There is no way around this one. Google states that app passwords can only be used with accounts that have 2-Step Verification turned on, and that you need 2-Step Verification on the account before you can create one.

That ordering catches people out. They open the app passwords page, find nothing, and assume Google removed the feature. Usually the account simply has no second factor yet.

The security logic is worth understanding rather than resenting. A password alone is a single secret that can be phished. Adding a second factor protects the interactive login, and the app password is then a separate, narrow credential you can revoke without touching your main password.

How to create a Gmail app password and use it for SMTP

1. Check whether the tool offers Sign in with Google

   Google says app passwords are not recommended and unnecessary in most cases. If the tool has an OAuth connect button, use it and stop here.

2. Turn on 2-Step Verification

   App passwords can only be used with accounts that have 2-Step Verification turned on, so switch it on in your Google Account first.

3. Create the app password in your Google Account

   Open the app passwords page in your Google Account, name the entry after the tool and the mailbox, and generate the passcode.

4. Copy it once and paste it straight into the tool

   Google shows the passcode a single time. Paste it into the tool's own password field, then store a copy in your password manager, nowhere else.

5. Enter the server name, port and username

   Use smtp.gmail.com with port 465 for SSL or 587 for TLS, your full email address as the username, and the app password instead of your account password.

6. Send a test, then write down what you granted

   Send one message to yourself, confirm it arrives, and record the tool, the mailbox and the date so the entry can be revoked later.

Google notes that you usually need to enter an app password once per app or device, and that every app password can only be checked once. If you lose it, you generate a new one rather than looking the old one up.

Gmail app password SMTP settings and ports

These are the values Google publishes, not values copied from a forum. The username is always the full email address, and the password field takes the app password in place of your account password.

Google's developer documentation puts it in one line: incoming connections to imap.gmail.com:993 and pop.gmail.com:995 require SSL, and a client that starts in plain text before issuing STARTTLS should use port 465 for SSL or port 587 for TLS.

Two smaller settings matter in practice. Google recommends a server timeout greater than one minute, with five minutes suggested, and notes that you can add Gmail to up to 15 email clients at a time per account before the "too many simultaneous connections" error appears.

If the port and protocol vocabulary is new, our IMAP server entry explains what each protocol does and why sending and receiving use different ones.

Three ways Google lets a device or app send mail

For Google Workspace accounts, the admin help documents three separate sending routes. Which one you should use depends on who owns the device and how much volume it sends.

Google calls the relay the most secure of the three because it authenticates messages with IP addresses rather than a shared secret. It needs admin setup, which is exactly why a request to your admin beats a quiet app password.

The restricted server is the odd one out. It requires no authentication and no TLS, but it can only deliver to Gmail and Workspace users, so it is useless for outbound prospecting.

Google Workspace admin controls

On a work account, this is not only your decision. Google's admin help is explicit that from May 1, 2025, Workspace accounts no longer support less secure apps, third-party apps or devices that ask you to sign in with your username and password, and that OAuth must be used instead.

The same page keeps one door open for hardware. For office devices such as scanners and multifunction printers that send over SMTP, IMAP or POP3, it says to configure OAuth or create an app password for use with the device.

Admins also get visibility. In a user's security settings, the application-specific password section lists every app the user created an app password for, when it was created and when it was last used, and lets the admin revoke any of them.

• Admins can revoke your app passwords: a connection can stop working without anyone touching the tool, which is worth knowing before you blame the vendor.
• Admins can reset sign-in cookies: Google notes it can take up to an hour to sign a user out of current Gmail sessions.
• Admins can see connected third-party apps: the connected applications list shows the access level each app was granted and when.
• The less secure apps enforcement setting is gone: Google states it is no longer available in the Admin console, so there is nothing left to toggle.

If you are building a stack around a shared mailbox, put this in the record early. Our sales tech stack entry covers why ownership of each connection matters more than the tool count.

OAuth as the better route

OAuth is not a marketing preference here. Gmail supports OAuth 2.0 over IMAP, POP and SMTP through the SASL XOAUTH2 mechanism, which is a documented, standard way for a client to present a token instead of a password.

The practical difference is what leaks if something goes wrong. A password gives full mailbox access with no expiry. A token is scoped, can be withdrawn from your account page, and expires.

Google documents that behavior for Workspace: OAuth 2.0 tokens issued for certain products are automatically revoked when a user's password is changed, and a Gmail IMAP session authenticated with OAuth is limited to the validity period of the access token, usually one hour.

When a tool you rely on has no OAuth option, say so to the vendor. A missing OAuth integration is a roadmap item, and buyers asking for it is how it gets prioritized.

Yahoo Mail app password and Yahoo SMTP settings

A Yahoo Mail app password works on the same idea with different mechanics. Yahoo describes app passwords as randomly generated codes that let non-Yahoo email apps access your account when they do not use Yahoo's sign-in page.

To generate one, sign in to the Yahoo Account Security page, click Create app password under "External connections," enter the app's name, click Generate password, use the code in the app, then click Done.

Yahoo's documented server settings are short. Incoming mail uses imap.mail.yahoo.com on port 993 with SSL required. Outgoing mail uses smtp.mail.yahoo.com on port 465 or 587, with SSL and authentication required, and the login is your full email address plus the generated app password.

Yahoo also has a page for the moment a connected client stops working. Its advice is to reauthenticate: delete the stored password in the email application's settings, then re-enter the password you use there, whether that is your account password or a third-party app password.

Gmail and Yahoo side by side

The row that bites teams is the third one. A Google app password silently dies the next time someone rotates the account password, so a routine security action looks like a broken integration on Monday morning.

Why app passwords may be unavailable

If you have 2-Step Verification on and still cannot find the option, Google lists three specific reasons rather than leaving you guessing.

• 2-Step Verification is set up only for security keys: the account has a second factor, but not the kind that allows app passwords.
• You are signed in to a work, school or other organization account: the availability is decided above your account, not inside it.
• The account has Advanced Protection: Google's strictest program removes this fallback by design.

Yahoo handles unavailability differently, through eligibility. Its help page asks you to use a browser you have signed into Yahoo with for several days in a row, to avoid Incognito mode, and to use webmail or the official Yahoo app if that does not work.

Yahoo then adds a sentence worth reading twice: customer care cannot override the process that determines app password creation eligibility. There is no ticket that fixes it, so plan the integration around OAuth instead of waiting.

An app password is a credential, so handle it like one

The whole risk of this setup sits in one fact. Those 16 characters give whoever holds them permission to reach your Google Account, and they keep working until the entry is revoked.

This is the same discipline that keeps a shared sending domain healthy. If several people touch the same mailbox, the record of who connected what is the only thing that makes a later cleanup possible.

Revoking an app password

Revoking is the part people skip, and it is the cheapest security control on this page. Google's advice is direct: if you lose a device, or no longer use an app that was authorized with an app password, revoke its app password.

In a Google Account, open your app passwords, find the app in the list, and click Remove. Google states that once you revoke the app password, the app cannot access your Google Account again.

In Yahoo, open the Account Security page, click the app passwords under External connections, click Delete next to the one you want, and confirm. Yahoo is explicit that deleting is the only way to invalidate an app password.

• When a tool is replaced: revoke on the day the old tool is switched off, not at the next audit.
• When someone leaves: revoke every entry tied to a mailbox they used, then reconnect what is still needed.
• When a passcode may have been shared: revoke first, investigate second. Generating a new one costs a minute.
• On a schedule: review the list each quarter alongside the connected apps list, and remove anything nobody recognizes.

Connecting a mailbox to a sending tool or CRM

Most people arrive at this page because a sequencer, a CRM or an outbound sales automation platform asked for mailbox access. Work through the same checks every time, whatever the tool.

Two things sit outside the mailbox and still decide whether your mail lands. The domain's MX records route incoming replies, and sending reputation is built slowly, which our email warm up guide covers in detail.

Errors you will actually see

Notice how many of these are not bugs. They are the security model working: a credential changed, expired or was withdrawn, and the tool has no way to know that except by failing.

Sending limits and what SMTP is not built for

An app password gets a tool connected. It does not turn your mailbox into a sending platform. Google documents a limit of 2,000 messages per day on the Gmail SMTP server, and up to 10,000 recipients per user per day on the relay.

Those are ceilings, not targets. A new mailbox that suddenly sends near either number looks exactly like a compromised account, and Google's own page notes that spam filters may reject or filter suspicious messages.

For real volume, the answer is a sending service with its own authentication and reputation, not a bigger mailbox. Personal mailbox sending belongs to conversations, not to an email blast.

The same logic applies to how you plan touches. A sales cadence that fits inside a normal working mailbox is also the one least likely to trigger a filter.

Common mistakes

• Creating an app password without checking whether the tool offers Sign in with Google first.
• Pasting the 16 characters into a chat or a support ticket so a colleague can "set it up".
• Using one app password across several tools, so nothing can be revoked without breaking everything.
• Naming entries "test" or "new", then having no idea what they unlock a year later.
• Assuming a Workspace mailbox behaves like a personal one, when password based third-party access is no longer supported there.
• Treating a broken connection after a password change as a vendor outage rather than a revoked credential.
• Pushing outbound volume through a personal mailbox because the SMTP connection made it easy.
• Never reviewing the list, so app passwords outlive the tools, the campaigns and sometimes the people.

The note to send your admin

If the mailbox belongs to a company, the fastest safe path is usually a short message before you create anything. The note below was written for this page. It asks two questions and commits to not sending the credential anywhere.

Subject: Sending access for {{toolName}} from {{mailbox}}

Hi {{adminName}},

I need {{toolName}} to send from {{mailbox}} for {{useCase}}. Two questions before I set anything up.

1. Does our policy allow this tool to connect with OAuth? That is the route I would prefer, and the vendor lists it under {{integrationName}}.
2. If OAuth is not available for this tool, may I create an app password for it, and would you rather issue it yourself?

I will not send the credential over email or chat either way. Happy to do the setup on a call with you.

{{senderName}}

Frequently asked questions