Configuring a Gmail account for third-party sending

Connecting Gmail to an external tool has two paths. OAuth is the one to prefer: scoped, revocable per app, no credential to leak. An app password is the fallback for clients that only speak SMTP and IMAP, and it requires two-step verification on the account. Your ordinary Google password will not authenticate either way.

Quick reference

The username is always the complete address, including on Google Workspace domains. Authentication is required on every one of these.

Generating an app password

1. Enable two-step verification on the account. Without it, the app password option does not exist — this is the reason most people cannot find it.
2. Open your Google Account security settings and find app passwords.
3. Create one, naming it after the specific client or integration.
4. Paste the generated value as the password in your client. It is shown once.

Two practices worth keeping: one app password per integration, so revoking one does not break the others, and never storing it in a shared document — it is a credential with broad mailbox access and no second factor in front of it.

On Google Workspace, an admin can disable app passwords or restrict less-secure access for the organisation. If the option is missing on a Workspace account and two-step verification is on, that is where to look.

Prefer OAuth when the tool supports it

OAuth asks you to sign in to Google and consent to specific scopes. Nothing reusable is stored on your side, access can be revoked per application from your account, and an admin can govern it centrally. For anything that will send on your behalf continuously, this is the right choice; an app password is a long-lived secret doing the same job with worse properties.

Workspace admins can restrict third-party app access under Security → Access and data control → API controls, which is the usual cause of a consent screen that refuses to complete.

Enable IMAP if anything needs to see replies

Check that IMAP access is enabled in Gmail's settings, then configure imap.gmail.com:993 over SSL. Prefer IMAP to POP: POP can remove messages from the server depending on client settings, so a second client sees an empty mailbox and any process watching for replies sees nothing.

Troubleshooting

"Username and Password not accepted" — the account password was used instead of an app password, or two-step verification is not enabled so no app password exists. Generate one and re-enter it.

Connection times out — a firewall or network blocking outbound 465 or 587. Try the other port before suspecting Google; some networks permit 587 and block 465.

TLS or certificate error — port and encryption mismatched. 465 expects implicit SSL/TLS; 587 expects STARTTLS.

Sends work, replies never appear — IMAP is off, or the client is on POP and has already removed the messages.

Mail sends but arrives unsigned — on a Workspace domain, DKIM is not yet generated and published. An admin must do that under Apps → Google Workspace → Gmail → Authenticate email; it is not automatic.

Working settings are not deliverability

An authenticated connection proves nothing about placement. Three things to get right separately:

• Authentication on the domain. Verify on a real received message that dkim=pass header.i=@yourdomain.com, spf=pass and dmarc=pass header.from=yourdomain.com. A pass on a bounce subdomain with a different From domain is an alignment failure.
• Send limits. Gmail and Workspace cap sending by edition and by sending method, and new accounts are capped lower. Look up the figure for your own configuration rather than trusting a number from an article, and design to sit under it rather than probing for it.
• Reputation. A new mailbox will be throttled below its nominal quota because providers accept volume in proportion to trust. Warm up before the mailbox carries a campaign, and watch spam rate in Postmaster Tools v2 against Google's 0.30% threshold, aiming under 0.10%. There is no reputation grade to check — the domain and IP reputation dashboards retired with v1, senders redirected from 30 September 2025 and v1 gone by the end of 2025, with v2 reporting spam rate, authentication, delivery errors, compliance status and, since June 2026, a Deliverability analysis report.

What not to do

• Do not use your Google account password in a third-party client. It will fail, and repeated failures can trigger security interventions.
• Do not reuse one app password across several tools.
• Do not choose an app password when OAuth is offered.
• Do not configure POP when something needs to watch for replies.
• Do not run cold outreach from a free consumer Gmail address. Limits cap it and you build no domain reputation you can keep.
• Do not assume a successful test send means good placement. Accepted mail includes spam-foldered mail.

How MailPilot helps

MailPilot connects Gmail and Google Workspace mailboxes over OAuth, and SMTP/IMAP senders including SendGrid, Amazon SES, Mailgun, Postmark and custom hosts where OAuth is not available. It checks SPF, DKIM and DMARC alignment on the sending domain, warms each mailbox with real conversations spread through the day, measures placement per provider with a seed-inbox network that reports Gmail's tabs separately, and tracks per-mailbox reputation daily.