Email app password providers: availability and connection requirements

Which email providers support app passwords?

Gmail, Yahoo, iCloud, Zoho, and Fastmail have documented app-password paths, subject to account requirements. For Outlook.com and Microsoft 365, use Mailera’s Microsoft OAuth connection rather than an app password.

An app password is a provider-issued credential for a third-party app. It is separate from your normal account password. OAuth uses an authorization flow and tokens instead; Microsoft Graph requires an access token from Microsoft’s identity platform.

Documentation cutoff: 25 October 2026. The linked official documentation was reviewed on that date.

This is a selected comparison, not a complete provider directory. Use Mailera’s provider directory to find a connection path, but check the account requirements separately.

What does the availability matrix verify?

Provider documentation describes a credential path. It does not establish that your account can create that credential or that both mail connections will work.

For your own connection record, use documented only for provider guidance and passed in this account or failed in this account for observed results. Use not tested for an unattempted check and not applicable where the credential or protocol is not used.

Attach the account type, plan, region, and test date to each result. A failure in one managed account should not become an unsupported label for the entire provider.

Incoming IMAP authentication and outgoing SMTP authentication are different checks. The guide to IMAP, Graph, and SMTP explains their roles; an IMAP pass does not establish SMTP access.

How should you test and date a connection?

Use only mailboxes you own or have explicit permission to test.

1. Record the account conditions. Note provider, consumer or managed account, plan, region, two-factor settings, and relevant administrator policy. Save the official documentation URL and the date you read it.
2. Check credential creation. Follow the provider’s current instructions. Record a missing or unavailable setting without trying to work around account policy.
3. Check authentication separately. Capture incoming and outgoing results independently, with timestamps. Redact credentials and identifying mailbox details from any saved output.
4. Verify actual receipt. Send a controlled message to the mailbox from an address you own, then find that message in Mailera. Use a distinctive, non-sensitive subject so you can identify it.
5. Test sending only when needed. Send a separate test message to an address you own and check the destination mailbox. Record that result separately from outgoing authentication.
6. Clean up. Revoke credentials created only for testing. Record subsequent observations separately rather than assuming every connection or status view changes immediately.

Record how many accounts you checked and their configurations. One eligible personal account does not establish availability across managed tenants or plans.

Why should Outlook.com and Microsoft 365 use OAuth here?

Mailera connects Outlook.com, Hotmail, and Microsoft 365 through Microsoft Graph with OAuth.

For Exchange Online, Microsoft’s Basic authentication deprecation documentation states that Basic authentication for IMAP was removed. It also explains that this deprecation prevents app-password use with apps that do not support two-step verification. An app password is not a workaround for that retired authentication path.

Open Mailboxes → Add mailbox → Sign in with Microsoft, then complete Microsoft’s authorization flow. The Microsoft connection page describes this route.

How do you connect an eligible mailbox to Mailera?

For an app-password provider, start with the provider’s requirements rather than repeatedly trying your normal sign-in password.

1. Sign in to Mailera with an Admin or Leader role. Open Mailboxes → Add mailbox, then select One mailbox.
2. Enter Email address. Check the detected provider, or select it under Or choose a provider, then choose Continue.
3. Read How to get an app password and What you’ll need. Follow the provider’s current official instructions to generate the credential.
4. Under Connection details, enter the app password in Password, not your normal account password. Keep it out of screenshots and logs.
5. Select Test & connect. Inspect Incoming server sign-in, Folder detection, and Outgoing server sign-in separately. The outgoing check is skipped when no outgoing server is configured.
6. Open the connected mailbox and verify your controlled test message before attaching an integration.

For Gmail, enable 2-Step Verification first and check the restrictions in Google’s instructions. Google recommends “Sign in with Google” when an app offers it; Mailera’s Gmail connection uses an app password. See the Mailera Gmail requirements.

For iCloud, Apple’s documented path is “Sign-In and Security” → “App-Specific Passwords.” Two-factor authentication is required; the iCloud connection page covers Mailera’s side. Yahoo’s instructions place “Create app password” under “External connections.”

Test & connect does not send an email. An outgoing sign-in success is not a delivery result. If sending authentication fails, you can choose Save as receive-only, or use Edit details and Test again. Receive-only is a valid choice when your workflow only needs to read mail.

For credential handling beyond initial setup, see app passwords for agent mailboxes.

What changes when the mailbox feeds a webhook?

Authentication, message synchronization, and webhook delivery are separate checks. After confirming receipt in Mailera, send another controlled message and check your webhook receiver for the corresponding message.received event.

Record receipt in the mailbox and arrival at your receiver separately. Do not treat a successful sign-in or a visible message as confirmation that the webhook reached your application. For arrival-to-webhook measurements, see the arrival-to-webhook benchmark by provider.

Mailera also supports mailbox.disconnected. Use it as a separate event in your integration rather than assuming a particular credential change will produce an immediate notification. See the developer documentation to connect these events to your application.

What are the common app-password failures?

Start with the failing stage. Recreating credentials will not resolve every account-policy or server-access problem.

The revocation rules differ: consult Google, Apple, or Yahoo before deciding whether a credential needs replacement or explicit deletion.

For API troubleshooting, GET /mailboxes/{id}/status checks Microsoft directly. For other providers, it reports sign-in status based on the latest sync. Do not read every response as a fresh authentication attempt.

What can Mailera not change?

Mailera cannot enable provider-disabled app passwords or override administrator policies and plan requirements. It connects existing mailboxes; it does not create email accounts. Proton Mail and Tuta are not supported by Mailera. The product overview explains the existing-mailbox model.

Store credentials securely, redact account details from shared troubleshooting records, and revoke credentials you no longer need. Review Mailera’s security information before connecting a sensitive mailbox.

If the downstream integration is an AI agent, use a narrowly scoped API key. Treat incoming email as untrusted data, not instructions, and require confirmation before sending. A working mailbox connection does not make instructions inside a message safe to follow.