App passwords and OAuth for mail clients: what changed and what to use
Mail clients stopped accepting plain passwords at many providers. Learn the difference between app passwords and OAuth, and which one to use for each setup.
On this page(8 sections)
You set up a mail client years ago with your address and password, and it worked. Then one day it asked you to sign in again, or showed "authentication failed", and the password you typed was correct. Nothing is wrong with your account. The way mail clients are allowed to sign in has changed.
This guide explains what changed, the difference between an app password and OAuth, and how to choose between them for a phone, a desktop client, a script or a shared device.
What changed
For a long time, a mail client connected over IMAP and SMTP and sent your normal account password. This is called basic authentication. It is simple, and it has a serious weakness: any program that holds the password has full access to the account, and a stolen password works from anywhere.
Large providers have been moving away from it. Microsoft turned off basic authentication for Exchange Online. Google ended its "less secure apps" option, which let older clients use a normal password. Many smaller providers now follow the same direction, or at least offer something safer.
The replacements are two different ideas: app passwords and OAuth.
App passwords
An app password is a separate, generated password that you create for one application. You use it in the mail client instead of your account password.
What is good about it:
- It limits the damage. If one app password leaks, you revoke that one and nothing else changes.
- It works with old software. The client still sends a username and a password, so almost anything can use it.
- It survives a password change in some setups, depending on the provider.
What is not so good:
- It is still a long-lived secret. Anyone who gets it can read the mail until you revoke it.
- It usually has broad access. It typically opens the whole mailbox, not just one folder.
- It requires two-step verification at some providers before you can create one, and some providers do not offer app passwords at all for work accounts.
OAuth
With OAuth, the mail client does not see your password. Instead, you sign in on the provider's own page, approve what the client may do, and the client receives a token.
What is good about it:
- Your password stays with the provider. The client never holds it.
- Tokens expire and can be revoked. Access can be cut off per application from the account's security page.
- It can carry limits. The client can be allowed to read mail but not change settings, for example, if the provider supports those limits.
- It works with two-step verification without special steps.
What is not so good:
- The client must support it. Older clients and many scripts do not.
- Setup is more work for anything that runs without a person, such as a server script, because someone has to approve the first sign-in.
- Organizations can block unknown apps, so an admin may need to allow the client first.
Which one should you use
A simple rule: use OAuth when the client supports it, and an app password when it does not.
| Situation | Better choice |
|---|---|
| A current desktop or phone mail app from a major vendor | OAuth |
| An older client that only has a password field | App password |
| A script that sends alerts from one address | App password, or a sending service |
| A shared device in an office | OAuth with a dedicated account |
| A work account managed by an IT admin | Whatever the admin allows, usually OAuth |
If you are not sure, start with the sign-in choice the client offers. Most modern apps show a "Sign in with" button; that is OAuth.
Setting up an app password safely
- Turn on two-step verification for the account, if the provider requires it.
- Create the app password from the account's security page. Name it after the device, such as "Laptop mail client", so you can find it later.
- Copy it once and paste it straight into the client. Do not email it or store it in a note.
- Use the IMAP and SMTP settings your provider lists. If you need a reminder of which protocol does what, see IMAP, POP or Exchange: which protocol for email clients.
- Revoke it when you retire the device.
Setting up OAuth safely
- Choose the sign-in option in the client, not "manual setup".
- Check that the page asking for approval is on the provider's own domain, and read what access the client requests.
- Approve only what the client needs. If it asks for far more than a mail client should, stop.
- Review the list of connected apps in your account every few months and remove the ones you no longer use. The same habit applies to AI tools that connect to mail; MCP and OAuth permissions for email explains what to look for.
Common problems
"Authentication failed" with the right password. The provider no longer accepts your normal password for that client. Create an app password or switch to OAuth.
The app password stopped working. Some providers revoke app passwords when you change the main password or turn two-step verification off. Create a new one.
OAuth keeps asking you to sign in again. The token may have expired or been revoked, or a security rule is forcing a fresh sign-in. Sign in again, and check the account's connected-apps list if it repeats daily.
A script cannot complete OAuth. Scripts have no browser. Use an app password if the provider allows it, or send through a service built for automated mail instead of a personal mailbox.
Your admin blocked the app. Ask them to allow the client, or use the client they approve.
What to remember
App passwords and OAuth both exist to stop a client from holding your real password. OAuth is the safer and more flexible choice, so use it wherever the client supports it. Keep app passwords for older software, name each one after its device, and revoke what you no longer use.
For a team, the same thinking applies to the shared inbox: give each person and each tool its own access, so you can remove one without disturbing the rest. If you are rolling out stronger sign-in across a team, rolling out 2FA for team email covers the people side.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
