Agent inbox vs existing mailbox: choose the right email identity

Should your agent use an existing mailbox or a new inbox?

Start with one question: is the agent helping someone with their existing correspondence, or operating a separate workflow?

A correspondence assistant needs access to the address people already write to. A new workflow, such as collecting responses for a research project, may deserve its own address. Neither choice tells you which API to use.

Mailera connects existing mailboxes to applications and AI agents through REST API, MCP, and webhooks. “Existing” can mean a mailbox used for years or one you created specifically for the agent this morning.

What is the difference between a dedicated inbox and a connected mailbox?

Here, mailbox means the email account and its mail folders; Inbox is one folder. “Agent inbox” is also used informally to mean an email service an agent can access.

Separate three decisions:

• Identity: which address should correspondents recognize?
• Provisioning: where will that address and mailbox be created?
• Access: how will your application authenticate and read or send mail?

A dedicated agent inbox describes its purpose. A connected mailbox describes how an application accesses it. The same mailbox can be both.

The last column describes a service category, not a uniform feature set. Check address lifecycle, permissions, and human review support before choosing a particular service.

When is an existing mailbox the right choice?

Use an existing mailbox when changing the address would separate the agent from the work it needs to do.

For example, an assistant summarizing your correspondence needs authorized access to your mailbox. An agent helping with an established support address needs access to the mailbox receiving those requests, provided its provider and mailbox type are supported. Creating a new address doesn't give it that correspondence.

Keeping the address also preserves the place where people already expect replies. Available previous messages can supply context, but connecting a mailbox should not be treated as importing its entire archive.

The trade-off is exposure to unrelated mail. A work mailbox might contain private conversations outside the agent's task. Choose a narrow mailbox group and decide which messages the application may pass to the model. A mailbox-group restriction is not a substitute for those application-level decisions.

The broader existing-mailbox model for AI agents explains where this approach fits beyond a single workflow.

When is a separate agent mailbox the better choice?

Choose a separate AI agent email address when the work should have its own correspondence history and identifiable sender. Examples include a new project-specific contact address or an isolated prototype using a test mailbox you own.

That separation makes it easier to attribute messages to the workflow and keep personal correspondence out of its mailbox. It is not, by itself, a complete security boundary.

There are two routes:

1. Create a mailbox at an email provider, then connect it. This fits when you want a separate identity at a provider you already use. Check Mailera's supported providers before creating it.
2. Choose an inbox-provisioning service. If programmatic creation and disposal of addresses are core requirements, evaluate services specifically for those capabilities. Check their lifecycle controls rather than assuming every agent-inbox service offers them.

You can also use both an established mailbox and a separate workflow mailbox. For example, an assistant could summarize authorized correspondence from your working mailbox while a project agent handles new requests through its own address.

For that hybrid design, define which mailbox receives each conversation and which mailbox may send its replies. Bind every action to an explicit mailbox identity; don't let the model select a sender from whichever mailbox it used most recently.

How do you choose and validate the setup?

1. Identify the address recipients should recognize. Write down whether the task needs correspondence already arriving there. If it does, a new address alone won't meet the requirement.
2. Choose shared correspondence or a separate identity. Decide which mailbox the agent may access and who owns human review. Use a mailbox you control for the initial test.
3. Check the connection requirements. Confirm provider support, authentication, administrator approval, and whether sending is needed. Microsoft connections use OAuth through Microsoft Graph. Microsoft's permissions reference explains that access requires permissions granted by the user or administrator. Mailera's Gmail connection uses an app password and requires two-step verification and administrator permission. Google's app-password guidance, accessed 25 October 2026, requires “2-Step Verification”; Google recommends “Sign in with Google” when an application offers it.
4. Provision a new address first, if needed. Create the separate mailbox outside Mailera before attempting to connect it.
5. Connect the mailbox. An Admin or Leader opens Mailboxes → Add mailbox. For Microsoft, choose Sign in with Microsoft. For other providers, follow the supported connection requirements. Test & connect checks the connection without sending an email.
6. Start with scoped read access. In Settings, open the API key tab and choose Create key. Set Mailbox scope to the relevant group and select only Read. Verify that you can read a harmless test message you own. Also check that an unrelated mailbox outside that group is inaccessible with the same key.
7. Add sending only if the workflow requires it. Check the mailbox's outgoing capability separately, then add the necessary sending permission. Put approval checks in your application before allowing sends.

If you run into credential problems, use the first-mailbox connection walkthrough for setup help rather than reconsidering which mailbox to use.

What common mistakes should you avoid?

For custom IMAP connections, the outgoing SMTP server is optional. If the sending test fails, Mailera offers Save as receive-only. That can suit a summarization assistant, but not a workflow that must reply.

How do you keep either option safe?

Treat incoming email, quoted text, and attachments as untrusted data, not instructions. A dedicated address does not prevent prompt injection. Do not let a message instruct the agent to reveal credentials, change policies, or forward private correspondence.

Keep permissions proportional to the task. A read-only assistant does not need Send messages or Manage mailboxes. Mailera separates Read from those permissions and can restrict a key to one mailbox group.

For workflows that send, require confirmation in your application, especially for new recipients, attachments, or sensitive content. The MCP tools specification recommends user confirmation for sensitive operations. Design that approval step yourself; don't treat it as an automatic Mailera guarantee.

Keep credentials out of prompts and screenshots. Decide who can revoke access and what happens after suspected misuse: stop the workflow, revoke the affected key, and review its actions before restarting. Revoking a Mailera API key causes calls using it to be rejected immediately. Include Mailera's security information in your access review.

What Mailera limits affect this choice?

After connection, Mailera initially loads messages within the retention period, newest first. The free self-serve workspace has a 30-day message retention period. If the workflow depends on older correspondence, account for that before choosing how it will access mail.

Mailera does not support Proton Mail or Tuta. It also does not provide bulk or marketing sending or mailbox warmup, and it cannot ensure inbox placement. Choose it for connecting supported mailboxes, not for those requirements.