Which Outlook account or application are you trying to connect?
Outlook can mean the email application or a Microsoft-hosted mailbox. That distinction determines which sign-in rules apply. Start with the company hosting your email, not the app you use to read it.
| What you're connecting | Who hosts the mailbox | Which rules apply | Next step |
|---|---|---|---|
| Personal Outlook.com or Hotmail mailbox | Microsoft | Outlook.com authentication requirements | Use a supported Microsoft OAuth connection |
| Microsoft 365 work or school mailbox | Microsoft Exchange Online | Exchange Online authentication requirements | Use a supported Microsoft OAuth connection |
| Outlook application with another provider's mailbox | That provider, such as Google | The mailbox provider's requirements | Follow that provider's connection instructions |
Reading Gmail in Outlook does not turn it into a Microsoft mailbox. For that case, use the Gmail connection guide.
A custom-domain address also doesn't tell you which connection to choose. Your company address may be hosted by Microsoft 365. Ask your administrator who hosts it before choosing Custom IMAP.
Why did my Outlook app password stop working for IMAP?
An app password is an alternative password for certain applications that cannot handle two-step verification. It does not change the authentication method the application uses.
With Basic authentication, the client authenticates using a username and password. OAuth lets a compatible client use an access token after Microsoft sign-in and authorization. Putting a different password into a Basic authentication connection leaves it using Basic authentication.
Personal Outlook.com and Hotmail accounts
Microsoft's Outlook.com Modern Authentication guidance gives September 16, 2024 as the date Basic authentication became unavailable for Outlook.com account access. Generating another Hotmail app password won't restore that connection method.
The client configuration matters too. Microsoft says Outlook for Windows does not support Modern Authentication when configured to connect to Outlook.com through POP or IMAP. Its recommended route is a new Outlook Desktop profile with automatic account configuration, which adds the Outlook.com account using Modern Authentication.
Microsoft 365 work or school accounts
Exchange Online has separately removed Basic authentication for IMAP. Microsoft's Exchange Online retirement guidance explicitly says this also prevents app passwords from working with affected applications. Neither your administrator nor Microsoft support can re-enable the retired method.
Don't apply the Outlook.com retirement date to Microsoft 365. These are separate services with separate guidance.
Why do app-password help pages still exist?
Microsoft's general app-password guidance describes devices that cannot handle two-step verification. That account-level feature is not permission to use a retired authentication method for email.
For work or school accounts, Microsoft Entra guidance also states that app passwords don't work for accounts required to use Modern Authentication. An app password cannot fix these Microsoft IMAP Basic authentication connections. That doesn't mean Microsoft discontinued every app password for every service.
How do you replace an app-password IMAP connection with OAuth?
If you want to keep using an IMAP mail client, use one that supports Microsoft's OAuth connection. Microsoft documents OAuth support for IMAP for both Microsoft 365 and Outlook.com.
- Identify the host and account type. Establish whether this is a personal Microsoft mailbox or a work or school account.
- Check the client's Microsoft OAuth support. A setup form that accepts only a username and password is not enough. Upgrade or change the client if it cannot use OAuth.
- Select its Microsoft account connection or OAuth authentication option. Follow that client's instructions. For Thunderbird, Microsoft specifically recommends selecting "OAuth2" instead of "Normal password" for incoming-server authentication.
- Complete Microsoft sign-in and consent. Check which account you're authorizing.
- Verify message retrieval. Open the intended mailbox and look for a recent message you can also see at the provider.
If the client still cannot connect, confirm that it supports Microsoft OAuth for IMAP and is configured to use it. Generating another app password won't change its authentication method.
OAuth is not another name for IMAP. IMAP remains the mail-access protocol in this path; OAuth changes how the client authenticates. Mailera takes a different path through Microsoft Graph. For a broader comparison, see IMAP, Graph and SMTP for agent builders.

How do you connect Outlook or Microsoft 365 to Mailera?
Use an existing mailbox you own or are authorized to connect. You need the Admin or Leader role to add a mailbox in Mailera.
Mailera connects Outlook.com, Hotmail, and Microsoft 365 through Microsoft Graph using OAuth. You don't need to fix the old client's IMAP configuration to connect to Mailera. The Mailera product overview explains how those existing mailboxes become available to apps and agents.
- Open Mailboxes → Add mailbox.
- Select Sign in with Microsoft.
- On Microsoft's sign-in page, select the intended account and complete authentication.
- Review the requested access and complete consent if you are authorized to do so. If Microsoft requests administrator approval, involve your administrator.
- Return to Mailera and open Mailboxes. Confirm the intended mailbox appears, then open it and check for an expected recent message in the intended folder.

Microsoft Graph permissions can sometimes be approved by the user. Some Microsoft Graph permissions require administrator consent; if Microsoft requests approval, involve your administrator. An approval prompt is therefore a different problem from an incorrect password. See Microsoft's Graph authentication and authorization explanation for that distinction.

Use the Microsoft connection details for this flow. Don't switch to Custom IMAP just because your Microsoft 365 address uses a company domain, and don't apply the custom IMAP Test & connect stages to the Microsoft sign-in flow.
What common mistakes keep the connection from working?
First locate the failure: is it in your old IMAP client, during Microsoft consent, or after the mailbox appears in Mailera? Those need different checks.
| Symptom | Check | Next action |
|---|---|---|
| A new app password fails like the old one | Is the client still using Basic authentication? | Configure Microsoft OAuth or use a compatible client |
| Mailera setup asks for an IMAP server and password | Did you choose Custom IMAP for a Microsoft-hosted mailbox? | Return to Add mailbox and select Sign in with Microsoft |
| The wrong mailbox was connected | Which account did you select at Microsoft sign-in? | Repeat setup with the intended account |
| Microsoft requests administrator approval | Some Microsoft Graph permissions require administrator consent | Involve your administrator and share the prompt details with personal information redacted |
| An IMAP client still cannot retrieve mail | Does the client support Microsoft OAuth for IMAP? | Confirm that it is configured to use Microsoft OAuth |
| A mailbox appears in Mailera but a message is missing | Confirm the intended mailbox and folder | Look for an expected recent message in that folder before treating it as a sign-in failure |
For the last case, use a recent message as your test. Mailera's free self-serve workspace retains messages for 30 days, so an older message is not a useful connection check.
Mailera uses Graph, not IMAP, for Microsoft mailboxes. It does not connect them with app passwords, restore retired Basic authentication, or create new Outlook addresses or Microsoft 365 accounts.
What should you protect when connecting apps or AI agents?
Keep Microsoft authentication on Microsoft's sign-in page. Never publish passwords, refresh tokens, Mailera API keys, or consent screenshots containing personal information. Consult Mailera's security information before sharing connection details with anyone helping you troubleshoot.
If you connect an agent after setup, create a key with Read permission and the smallest appropriate Mailbox scope. Don't grant Send messages just to test reading. Require explicit confirmation before any later sending action.
Treat incoming email as untrusted data, not instructions. A message may contain text trying to redirect the agent, expose credentials, or trigger an action. The agent must not follow commands embedded in messages.
For broader credential guidance across providers, see app passwords for agent mailboxes.
Connect your first mailbox in 2 minutes
Add an Outlook, Gmail or IMAP mailbox and read email messages in the app or via the API.
Connect mailbox








