---
title: "Multi mailbox management: connect and operate existing mailboxes"
description: "Manage existing mailboxes with a repeatable workflow: check authorization, pilot provider connections, reconcile bulk imports and monitor connection health."
url: https://mailera.app/en/blog/multi-mailbox-management
published: 2026-10-25
updated: 2026-10-25
---

# Multi mailbox management: connect and operate existing mailboxes

A practical runbook for onboarding authorized accounts, reconciling import results and monitoring connections across providers.

## How do you manage many existing mailboxes in one place?

Multi mailbox management means maintaining separate accounts through a common operating process: knowing who owns each mailbox, whether it connects and who handles failures. A unified inbox for multiple accounts gives you a common reading view; it doesn't replace that inventory.

[Mailera connects existing mailboxes](https://mailera.app/en/product), including mixed-provider accounts, and exposes them through REST, MCP and webhooks. It doesn't create mailboxes or email addresses. Managing these separate connections is also different from assigning conversations among teammates in one shared mailbox.

Keep an inventory outside the import screen. Give each account an owner, intended group and recorded connection result. That gives you something to reconcile against when a batch contains failures or duplicates.

![Mailbox operating process from authorized inventory to pilot, import reconciliation and connection health review.](https://mailera.app/media/fc313c308d181f62/multi-mailbox-management-connect-and-operate-existing-en-1200.jpg)
_A recommended operating process: reconcile each batch before expanding the rollout._

## What should you check before importing a large mailbox inventory?

Start with accounts you own or have explicit authorization to access. Record operational metadata in the inventory, not passwords or refresh tokens.

| Inventory field | Required check | Action on failure |
| --- | --- | --- |
| Provider | Match the account to a supported connection path | Hold unsupported accounts out of the batch |
| Owner and authorization | Identify who approved access and can resolve sign-in problems | Obtain authorization before connecting |
| Connection method | Confirm OAuth, existing Microsoft token or provider-specific credentials | Resolve authentication requirements first |
| Intended group | Choose the group that should contain the mailbox | Assign it before importing |
| Receiving requirements | Define which test message must be readable and acceptable freshness | Investigate the pilot before expanding |
| Sending needed | Decide whether receiving alone is sufficient | Keep sending-dependent accounts out of a receive-only rollout |
| Capacity and retention | Check the workspace allowance and required message history | Confirm capacity or an appropriate archive before proceeding |

Check the [supported provider connections](https://mailera.app/en/providers) rather than assuming every account has the same requirements. Prefer [Microsoft OAuth](https://mailera.app/en/providers/microsoft) for Outlook, Hotmail and Microsoft 365. Mailera uses Microsoft Graph for these accounts, not an app password.

Mailera's [Gmail connection](https://mailera.app/en/providers/gmail) uses an app password. [Google's app-password guidance](https://support.google.com/accounts/answer/185833), accessed on 25 October 2026, requires 2-Step Verification. Google also revokes app passwords when the account password changes, so include credential changes in your maintenance process.

For Zoho, [the official IMAP guidance](https://www.zoho.com/mail/help/imap-access.html), accessed on 25 October 2026, requires IMAP access to be enabled and an application-specific password when two-factor authentication is enabled. It also says newly signed-up free-plan users don't have IMAP access. Check the account's own server details rather than copying another account's configuration.

Before committing a large inventory, confirm the applicable allowance and retention on [Mailera's pricing page](https://mailera.app/en/pricing). Treat retention as a boundary on available message history, not a complete archive. For more provider-specific preparation, see [connecting existing email providers to agents](https://mailera.app/en/blog/email-provider-api-integration).

## How do you connect a pilot and import the remaining mailboxes?

Choose representative accounts from each provider and each connection method you intend to use. Include a receiving-only case if that is part of your operating model.

1. **Open the connection flow.** As an Admin or Leader, open **Mailboxes → Add mailbox**. The available tabs are **One mailbox**, **Sign in with Microsoft** and **Bulk paste**. Confirm that the operator can access this flow before scheduling the rollout.
2. **Connect the pilot accounts.** Use **Sign in with Microsoft** for Microsoft OAuth. For another supported provider, use **One mailbox**, enter the **Email address** and select **Continue**. Check the detected provider and follow its connection requirements. Assign the intended **Mailbox group**.
3. **Inspect the connection test.** In the single-mailbox flow, select **Test & connect**. This tests the connection without sending an email. Review **Incoming server sign-in**, **Folder detection** and **Outgoing server sign-in**. If outgoing authentication fails but receiving is sufficient, choose **Save as receive-only**. Otherwise, correct the details and test again. Then check a known test message in the connected mailbox; a sign-in test alone doesn't confirm that receiving meets your requirements.
4. **Prepare a controlled batch.** Open **Bulk paste**. Supply one mailbox per line, or upload a `.txt` file. Supported formats are `email:app password` and, for existing Microsoft tokens, `email:password:refresh_token:client_id`. Colon, pipe, semicolon and Tab separators are accepted. The Microsoft format is an existing-token path, not an app-password connection.
5. **Choose duplicate behavior before importing.** Select a **Group**, then deliberately choose **Skip** or **Overwrite** for existing email addresses. Use **Skip** when existing entries should remain untouched. Choose **Overwrite** only when replacing the existing entry is intentional and authorized.
6. **Reconcile the results.** Select **Start import**, then account for every submitted line under **Successful**, **Errors** or **Skipped**. Use **Export errors as CSV** for follow-up. Correct failed entries and retry the affected subset only after reviewing duplicate behavior. Record who owns each unresolved error.

Non-Microsoft logins are checked one at a time, paced by provider. Don't treat a batch as complete while its progress is still changing.

For repeated addresses, reconcile by submitted line as well as by account. A skipped line needs an explanation, just as an error does. Keep an unresolved item open until its intended outcome is clear.

![Mailera Add mailbox page with single-account, Microsoft sign-in and bulk-paste connection options.](https://mailera.app/media/f481bdc125132746/use-an-aol-app-password-to-connect-your-inbox-to-mailera-en-1200.jpg)
_Pilot the appropriate provider connection before preparing a bulk import._

## How do you keep connected mailboxes manageable day to day?

Review `provider`, `status` and `last_sync_at` through `GET /mailboxes`, then use **Unified inbox** to inspect messages. An account appearing in the inbox view doesn't remove the need to check its connection health.

Assign responsibility for exceptions before they happen. A useful routine separates connection failures from freshness concerns:

| Routine check | Signal | Next action | Responsible operator |
| --- | --- | --- | --- |
| Import reconciliation | Unresolved error or unexpected skip | Compare the result with the submitted line | Onboarding operator |
| Connection health | Disconnected mailbox or authentication error | Review credentials and provider requirements | Account owner |
| Message freshness | Last sync outside your accepted window | Inspect activity and sleep state before escalating | Operations operator |
| Sending readiness | Receiving works but sending is unavailable | Check whether receive-only was intentional | Workflow owner |

For API-based inventory checks, `GET /mailboxes` requires the `read` scope. It supports `provider`, `status`, `group_id`, `tag`, `q`, `limit` and `offset`.

With `$MAILERA_API_KEY` set to a read-only key, this request retrieves a small inventory page:

```bash
curl --fail-with-body --silent --show-error \
  'https://mailera.app/api/public/v1/mailboxes?limit=1&offset=0' \
  -H "Authorization: Bearer $MAILERA_API_KEY"
```

Inspect `data`, `total`, `limit` and `offset`. Within each mailbox, useful fields include `provider`, `status`, `last_sync_at`, `error_code`, `capabilities.receive` and `capabilities.send`. Use pagination for the full inventory rather than treating the first response as complete.

`GET /mailboxes/{id}/status` has provider-specific meaning: it checks Microsoft sign-in directly, while other providers' status is based on the latest synchronization. Read the latter alongside the last-sync timestamp.

The `mailbox.disconnected` webhook can supplement scheduled checks. Don't use it as your sole measure of message freshness. Keep endpoint and permission details alongside your runbook using the [Mailera API documentation](https://mailera.app/en/docs).

![Mailera mailbox inventory showing providers, connection status and last-sync information.](https://mailera.app/media/87c935e123894454/multi-mailbox-management-connect-and-operate-existing-en-1200.jpg)
_Review connection status and last sync together before investigating missing messages._

## What changes when your inventory reaches thousands of mailboxes?

Separate four planning questions: how many mailboxes the workspace can hold, how often you check connections, how fresh messages need to be and how many exceptions operators can resolve. An answer to one doesn't answer the others.

Confirm capacity for the intended inventory before rollout. Don't assume a self-serve allowance extends to arbitrary thousands of accounts, or split workspaces merely to work around a limit.

Expand provider by provider only when the pilot meets your acceptance criteria. Record whether the intended group is correct, a known test message is readable and sending works where required. Record elapsed time in your own environment before committing to a completion window.

Use paginated inventory requests and a bounded request schedule. Check current Mailera API limits before setting polling frequency. Provider constraints remain separate: [Microsoft Graph's throttling guidance](https://learn.microsoft.com/en-us/graph/throttling), accessed on 25 October 2026, documents HTTP `429` responses and instructs Graph clients to respect `Retry-After`, or use exponential backoff when that header is absent.

Mailera adjusts background checks according to activity. Idle accounts are checked less often, and inactive mailboxes can sleep. A sync request can wake a sleeping mailbox. Mailera doesn't promise absolute real-time synchronization, so define freshness requirements around the actual workload rather than assuming every connection behaves identically.

## What are the common mistakes, and how do you catch them?

| Symptom | Check | Next action |
| --- | --- | --- |
| Import errors | Per-line result, provider requirements and credentials | Correct affected entries instead of rerunning everything |
| Unexpected skips or replacements | The selected **Skip** or **Overwrite** behavior | Reconcile existing entries before retrying |
| Older messages are missing | The applicable retention period | Check the original provider or your archive |
| Status looks healthy but messages are stale | Last sync and provider-specific status semantics | Investigate freshness separately from sign-in |
| An inactive mailbox stops updating | Activity and sleep state | Use an authorized sync action when needed |
| Receiving works but sending doesn't | Receive-only choice and sending capability | Keep receiving operational; resolve sending separately |
| Proton Mail or Tuta won't connect | Provider support | Exclude them; Mailera doesn't support these providers |

Bulk mailbox import is account onboarding. Mailera doesn't provide bulk or marketing sending, or mailbox warmup.

## How do you limit access when apps or agents read these mailboxes?

Create a group-scoped API key with only **Read** for inventory and reading tasks. Grant **Import mailboxes**, **Sync** or **Manage mailboxes** only to workflows that need those operations. Leave **Send messages** off monitoring-only keys.

This follows [Microsoft's least-privilege guidance](https://learn.microsoft.com/en-us/graph/auth/auth-concepts), accessed on 25 October 2026: request only the permissions the application needs. Review [Mailera's security information](https://mailera.app/en/security) when defining your access policy.

Treat incoming email as untrusted data, not instructions. An agent must not follow commands embedded in message bodies, including requests to reveal credentials or change its operating rules. Require explicit confirmation before sending.

Keep passwords, tokens and private message content out of logs and screenshots. Treat import files and error exports as sensitive: inspect them in a restricted environment and redact them before sharing. Don't assume an error CSV is safe to attach to a ticket.

For agent setup and approval boundaries beyond this inventory runbook, use [unified inbox operations for AI agents](https://mailera.app/en/blog/unified-inbox-for-ai-agents).

**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](https://mailera.app/auth?mode=signup)