Why Google app passwords cannot be automated

Almost every cold-email tool asks for an SMTP username and password. For a Google Workspace mailbox, the password it wants is an app password — a sixteen-character string Google issues so that a program can authenticate without going through an interactive login. If you are provisioning mailboxes one at a time by hand, you generate one, paste it in, and never think about it again.

If you are provisioning them by the hundred, you eventually try to automate that generation, and you discover it is not slow or fiddly. It is impossible. This is the chain, in the order you hit it.

The chain, link by link

Generating an app password requires being signed in as the mailbox user and visiting the account security page. So the automation needs to: sign in as the user, enable 2-step verification, then generate the password. Three steps. Each one has a wall behind it.

Link 1: app passwords require 2-step verification

Google does not offer app passwords on an account without 2SV enabled. The option is not hidden or hard to find — it does not exist on the page until 2SV is on. So the first link demands the second.

Link 2: only the user can enable 2-step verification

This is where an administrator would expect to be able to help, and cannot. A Workspace super-admin can enforce 2SV as a policy, but cannot enable it on a specific account. The Admin Console says so on the card itself:

Only the user can turn on 2-step verification

Enabling 2SV means choosing and registering a second factor, and Google treats that as an act only the account holder can perform. Which means the automation has to sign in as the user. Which brings us to the wall.

Link 3: a brand-new user cannot sign in from automation

A freshly created Workspace user has a password that the provisioning system set, so signing in ought to be mechanical. It is not. Google accepts the password and then serves an identity-assurance challenge:

url:      accounts.google.com/v3/signin/challenge/iap
heading:  "Verify it's you"
inputs:   ["tel[phoneNumber]"]
body:     "Enter a phone number to get a text message with a verification code."

The account has never signed in before, has no recovery phone set, and is being accessed from an unfamiliar context. Google will not hand out a session until it can deliver an SMS to a real handset.

The administrative control that looks like the answer

There is a per-user setting in the Admin Console called the login challenge, and it can be turned off for ten minutes. It is exactly the shape of thing you would expect to solve this, and it is automatable — the control is there, it responds, the console even warns you that “disabling login challenge will make the account less secure”, which reads like a system that expects you to be about to do something it will then permit.

It does not solve it. That control covers knowledge-based identity questions — the “confirm the recovery email on this account” class of prompt. It does not cover the phone challenge above. We reproduced the same challenge/iap page twice: once before clearing the login challenge and once immediately after. Same wall.

What this forces

Follow the chain to its end and the consequences are unambiguous:

• No app password can be generated by automation. Not slowly, not with better selectors, not with a smarter browser profile.
• A human signing in once per mailbox would work. And that is precisely the thing that does not scale. Any system built to stand up hundreds of mailboxes exists to keep humans out of the per-mailbox path; putting one back in at the last step defeats the entire design.
• So the mailbox gets stuck one step from usable. Domain registered, DNS published, verification passed, DKIM signing — and then no credential to hand you.

The way out is architectural, not technical

The answer is to stop needing an app password at all. A service account with domain-wide delegation can be authorised to impersonate users in a Workspace, and mint an access token for any mailbox on demand. No browser, no sign-in, no 2SV, no per-mailbox secret — nothing in the path for Google to challenge, because nothing in the path is pretending to be an interactive human.

That is what Infrabox does, and it is why the provisioning pipeline’s sending- credential step mints and verifies a credential rather than generating and storing one. The mechanics are in the domain-wide delegation guide.

The thing your sending tool connects to is then not Gmail’s SMTP server with an app password, but the Infrabox relay with a credential Infrabox issued. From the tool’s point of view it is still a host, a port and a password. Underneath, the impossible link in the chain has been removed rather than worked around.