Why an app password is required
Account passwords stopped working from third-party mail clients when Google removed what it called less secure app access. An SMTP client cannot complete a two-step verification challenge, so a second credential type was needed.
What an app password is and is not
one credential, two very different jobsAn app password solves that narrowly. It authenticates through the ordinary PLAIN or LOGIN mechanism, so no client changes are required, while remaining separate from the account password.
The security property that matters is revocation. Each app password is scoped to one application and can be revoked individually, so a leaked credential is contained rather than requiring an account-wide password change.
Enable two-step verification
App passwords are only available on accounts with two-step verification enabled. The option does not appear otherwise, which is the most common reason people cannot find it.
Turn it on in the Google Account security settings. For Workspace accounts, an administrator may control whether two-step verification and app passwords are available at all, so the option can be absent for policy reasons rather than configuration ones.
Generate the app password
Google documents the process under sign in with app passwords. Generating one produces a 16-character code shown once.
Name it for the application that will use it. That name is the only thing distinguishing entries later when deciding which to revoke.
Copy the code without spaces. Google displays it in four groups of four for readability, and the spaces are presentation rather than part of the credential.
Store it immediately in an environment variable or a secrets manager. The code cannot be retrieved after the dialog closes, only regenerated.
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 username is the full Gmail address including the domain. The password is the 16-character app password rather than the account password.
Authentication happens after the connection is encrypted. A client attempting AUTH before completing STARTTLS on port 587 will be refused, which presents as a credential error rather than a sequencing one.
Limits and when this is the wrong approach
Gmail applies per-mailbox sending limits sized for a person, and Workspace applies its own quotas. Exceeding them results in temporary account blocks rather than a clear error at send time.
Mail sent this way authenticates as an individual mailbox, so it carries that account's reputation and shows that address as the sender. It cannot send as your domain unless the mailbox is on your domain, and even then the reputation is the mailbox's.
Google is also moving toward OAuth as the preferred mechanism, which makes an app password a bridge rather than a destination for anything long-lived.
For application mail the appropriate path is a submission service authenticating as a verified sending domain, ours verifies one in about a minute, which provides per-message delivery events, bounce classification and suppression handling that a mailbox does not.
Why the credential keeps getting harder
App passwords exist because a mail client cannot complete a second authentication factor, and providers were unwilling to keep accepting account passwords from clients that could not. The credential is a workaround for a protocol that predates the security model now wrapped around it.
The direction of travel is worth naming: every year the gap widens between what a consumer mailbox is designed for and what an application needs. Aggressive bot detection makes automated access harder by design, and an automated agent cannot hold its own mailbox on the major consumer platforms at all.
The pull toward Gmail is real. When George, our CEO, scanned all 443 brands (439 users) in our production database, 78% of users lived in a Google mailbox, 52% plain gmail.com signups plus 110 custom domains on Workspace MX.
That gap is why our own Gmail integration was deprecated in July 2026. Gmail remains a destination we coexist with, and mail for addresses we do not handle forwards on to Google Workspace, Outlook, Zoho or whatever a customer already runs, untouched. What we no longer do is treat a consumer mailbox as sending infrastructure.
For anyone weighing an app password against something else, the question is what the credential is for. Connecting a personal client to a personal mailbox is exactly what app passwords are for and they work well. Wiring an application to a consumer mailbox is using a personal credential as production infrastructure, and every hardening step a provider takes lands on you.
The practical tell is whether a human will be present when things change. App passwords survive account password changes and have to be revoked deliberately, so an application depending on one keeps working until somebody tidies up and then stops without warning.