How to create a Gmail app password for SMTP (and when you should not use Gmail at all)

You are connecting Gmail to something — a CRM, a form tool, a script — and it keeps rejecting your password. The password is right. You can log into Gmail with it.

Gmail will not accept it over SMTP. It has not since 2022. You need an app password, which is a separate 16-character password generated per application, and there is one prerequisite nobody mentions until you are already annoyed.

The short version

1. Turn on 2-Step Verification on your Google account. App passwords do not exist without it.
2. Go to myaccount.google.com/apppasswords
3. Name it after the thing you are connecting, and create it
4. Copy the 16 characters — you will not see them again
5. Paste that as the password in the tool, not your normal one

Then the settings:

Those are the values Groundbase pre-fills when you pick Gmail, and they are the same everywhere else.

The prerequisite that trips everyone

If you cannot find the app passwords page, or it 404s, 2-Step Verification is off. That is almost always the reason.

Google does not explain this on the page. It just does not show you the option. Turn on 2SV under Security in your Google account, then go back and the page exists.

Two other cases where it will not appear:

• Google Workspace with app passwords disabled. An admin can switch them off for the whole organisation. If you are on a work account and the page is missing with 2SV on, that is your answer, and you need your admin rather than a workaround.
• Advanced Protection enrolment. It deliberately blocks app passwords. That is the feature working as intended.

What the errors actually mean

"Username and Password not accepted" or a 535 — you used your normal password, or pasted the app password with the spaces Google displays it with. Google shows it in four blocks of four for readability. Some tools cope with the spaces; plenty do not. Strip them.

It connects but no mail arrives in the app — SMTP sends, IMAP receives, and they are separate. Check IMAP is enabled in Gmail under Settings → Forwarding and POP/IMAP. It is off by default on some accounts.

It worked and then stopped — an app password is revoked if you change your Google account password, and revoked individually if you delete it from that page. Changing your main password invalidates every app password you have made. Generate a new one.

"Sender address rejected" — you are trying to send from an alias Gmail does not know about. Add it under Gmail → Settings → Accounts → Send mail as first. Gmail will only send from addresses it has verified you control.

The limit nobody mentions until it bites

This is the part that matters most, and almost no guide covers it.

Gmail caps how much you can send. Roughly 500 messages a day on a free account and around 2,000 on Google Workspace, counted per recipient rather than per message. Exceed it and Google temporarily locks sending — typically for around 24 hours — with no warning beforehand.

For normal work this is irrelevant. For anything resembling outreach it is a wall you will hit fast, and hitting it takes out your actual email, not just the tool.

Worse, Gmail is not designed for bulk sending and its reputation systems are tuned for personal correspondence. A burst of similar messages to people who did not ask for them is exactly the pattern that gets an account flagged.

So the honest rule: Gmail over SMTP is right for one-to-one email that happens to be sent from a tool — replies, follow-ups, the ordinary conversation of running a business. It is wrong for campaigns.

If you are sending to a list, use something built for it. I wrote up setting up Resend and verifying your sending domain, which is the path I recommend — a proper sending domain with SPF, DKIM and DMARC, separate from your personal inbox, and a free tier that covers most people starting out.

Using both is a perfectly sensible arrangement: Gmail for conversations, a sending service for campaigns. That is how Groundbase is set up to work, and it is what I do.

Is an app password safe?

Reasonably, with two things understood.

An app password grants access to your mail — sending and, depending on scope, reading. It bypasses your second factor, which is the entire point of it existing. So it is worth being deliberate:

• One per tool. They are free and unlimited. Separate ones mean you can revoke access for one thing without breaking everything else.
• Name them properly. "Groundbase" rather than "test". In a year you will be looking at a list and deciding what to revoke.
• Revoke on the same page you created them. Immediate, and it does not affect your account password.
• Anything storing one should encrypt it. Groundbase does, and it is a fair question to ask any tool before you paste one in.

If you would not be comfortable with a tool reading your inbox, do not give it an app password. That is the actual decision you are making.

Outlook, Yahoo, iCloud

Same shape, different hosts. All use port 587 with STARTTLS, and all require an app password rather than your login password if you have two-factor enabled:

• Outlook / Microsoft 365 — smtp.office365.com
• Yahoo — smtp.mail.yahoo.com
• iCloud — smtp.mail.me.com

iCloud is the strictest: app-specific passwords are mandatory, not optional.

One caveat on all of this: Google in particular has tightened access repeatedly — "less secure app access" is already gone — and the exact behaviour of app passwords has moved more than once. Everything here reflects how it works as I write, but if the flow does not match what you are seeing, believe your screen and check Google's current documentation rather than my post.

If you are still deciding whether you need any of this yet, when a spreadsheet stops working as a CRM is the honest version of that question.

---

Stuck on a connection error I have not covered? Send me the exact message: blog-gmail-smtp@groundbasecrm.com — I read every one.