---
title: "Email protocols for AI agents: IMAP, SMTP, Graph, and MCP"
description: "Compare IMAP, SMTP, Microsoft Graph, and MCP for AI agents. Choose an existing-mailbox connection, test reading and sending, and restrict agent access."
url: https://mailera.app/en/blog/email-protocols-for-ai-agents
published: 2026-10-25
updated: 2026-10-25
---

# Email protocols for AI agents: IMAP, SMTP, Graph, and MCP

Choose the connection by the mailbox you already use and the actions your agent needs. Reading mail, sending it, and exposing agent tools are separate jobs.

## What do IMAP, SMTP, Microsoft Graph, and MCP actually do?

An agent that summarizes incoming mail needs mailbox access. An agent that replies also needs a working sending connection and permission to use it. MCP can expose those actions as tools, but it doesn't replace the underlying email connection.

| Technology | Layer | Reading | Mailbox changes | Sending | Authentication | Provider coverage |
| --- | --- | --- | --- | --- | --- | --- |
| IMAP | Mailbox access protocol | Yes | Yes | No | Depends on provider and connection | Servers offering IMAP |
| SMTP | Mail transfer and submission protocol | No | No | Yes | Depends on server requirements | Servers offering SMTP |
| Microsoft Graph | Microsoft API | Yes | Yes | Yes | OAuth authorization | Supported personal and organization Outlook mailboxes |
| MCP | AI application tool interface | Through exposed tools | Through exposed tools | Through exposed tools | Depends on server; Mailera uses an API key | Depends on the connected service |

### IMAP vs SMTP: access is not submission

The [IMAP specification](https://www.rfc-editor.org/rfc/rfc9051.html) describes accessing and manipulating messages stored on a server. It explicitly leaves outgoing submission to a separate mechanism. SMTP handles mail transfer; the [message submission standard](https://www.rfc-editor.org/info/rfc6409/) distinguishes submitting a message from relaying it onward.

For an IMAP-based integration, successfully reading a folder says nothing about whether outgoing SMTP works. Treat those as separate capabilities.

### IMAP vs Microsoft Graph: different interfaces, overlapping jobs

The [Microsoft Graph mail API](https://learn.microsoft.com/en-us/graph/api/resources/mail-api-overview?view=graph-rest-1.0) supports reading, sending, and mailbox operations such as updating or deleting messages. A Graph integration therefore doesn't inherently need a separate SMTP integration to send.

OAuth answers a different question: how the application gets authorized access. It isn't a replacement for a mailbox interface. Microsoft's [authorization documentation](https://learn.microsoft.com/en-us/graph/auth/auth-concepts) distinguishes delegated access on behalf of a signed-in user from application permissions without a signed-in user. Those are Graph authorization models, not a promise that every integration offers both.

### MCP sits on the agent side

The [MCP introduction](https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro) describes a standard for connecting AI applications to external systems. In Mailera, tools such as `list_messages` and `send_email` expose mailbox actions to an agent. The provider connection still does the underlying email work.

## Which connection should you choose for an existing mailbox?

Start with the provider, then decide whether your workflow needs sending.

| Existing mailbox | Mailera connection | What to check |
| --- | --- | --- |
| Outlook.com, Hotmail, Microsoft 365 | Microsoft Graph with OAuth | Microsoft sign-in and consent |
| Gmail or Google Workspace | App password; IMAP incoming, SMTP outgoing | 2-Step Verification, account eligibility, and administrator policy |
| Other supported app-password providers | Provider-specific connection | The provider's documented requirements |
| Private or company mail server | Custom IMAP, with optional SMTP | Incoming settings and outgoing settings separately |

For Microsoft, choose **Sign in with Microsoft**. Mailera doesn't connect Microsoft mailboxes with app passwords. The [Microsoft provider page](https://mailera.app/en/providers/microsoft) covers that connection path.

Mailera's [Gmail connection](https://mailera.app/en/providers/gmail) uses an app password. That describes Mailera's connection method, not a claim that Gmail lacks other authorization options. Google's [app-password guidance](https://support.google.com/accounts/answer/185833) requires 2-Step Verification and notes that organization accounts may not show the option. Google recommends "Sign in with Google" when an application offers it.

For a private server, the [custom IMAP connection](https://mailera.app/en/providers/imap) separates **Incoming server (IMAP)** from optional **Outgoing server (SMTP)**. You can connect incoming mail without setting up sending.

![Mailera Add mailbox screen with Microsoft sign-in and Custom IMAP connection options.](https://mailera.app/media/d8e9591c875d36fe/email-app-passwords-connect-your-mailbox-to-an-ai-agent-add-en-1200.jpg)
_Choose the provider connection before deciding which actions the agent can use._

Keep two restrictions distinct:

- **Read-only agent access** means the agent's key lacks permission to send, even if the mailbox can send.
- **Receive-only connection** means the mailbox lacks a working outgoing connection. Adding a sending permission doesn't repair that connection.

This distinction matters for a summarizer: connect the mailbox normally if needed, but give the agent only the access its task requires.

## Where does Mailera sit between the mailbox and the agent?

[Mailera](https://mailera.app/en/product) connects existing mailboxes through provider-specific connections and exposes them through REST, MCP, and webhooks. Your application can use those interfaces without implementing each provider connection itself.

![Existing mailboxes connect through Microsoft Graph or IMAP and optional SMTP to Mailera, which exposes REST, MCP, and separate webhook events.](https://mailera.app/media/230b51c2b8f16d28/email-protocols-for-ai-agents-imap-smtp-graph-and-mcp-en-1200.jpg)
_Provider connections handle mailbox access; REST and MCP expose actions, while webhooks carry application-facing events._

The two main API capabilities map directly to the decision above:

| Task | REST endpoint | Required scope | MCP tool |
| --- | --- | --- | --- |
| List messages in a folder | `GET /mailboxes/{id}/messages` | `read` | `list_messages` |
| Send a message | `POST /mailboxes/{id}/send` | `send` | `send_email` |
| Inspect a send attempt | `GET /sends/{id}` | `send` | `get_send_status` |

REST calls use a Bearer API key in the `Authorization` header. Provider authorization and Mailera key permissions are separate: a connected mailbox doesn't give every key access to it or permission to send from it.

Notifications also have separate layers. For Microsoft mailboxes, Graph change notifications tell Mailera about new mail, with periodic background checks as a fallback. Mailera's `message.received` webhook is an application-facing event, not the Graph notification itself.

Background-check frequency varies with mailbox activity. Inactive mailboxes can sleep and wake on use, so don't design a workflow around instantaneous arrival.

For the broader architecture, see [using existing email for AI agents](https://mailera.app/en/blog/email-for-ai-agents). The [developer overview](https://mailera.app/en/developers) covers the application interfaces, while [Mailera's MCP tools by task](https://mailera.app/en/blog/mailera-mcp-tools) helps you choose which actions to expose.

## How can you verify the connection before giving an agent access?

Use a test mailbox you own. Keep connection testing separate from an actual send.

1. **Confirm the provider requirements.** In Mailera, an Admin or Leader can add the mailbox. Use Microsoft OAuth for Microsoft accounts; for other providers, check the required credentials and account restrictions before entering connection details.
2. **Inspect incoming and outgoing results separately.** For IMAP/SMTP setup, **Test & connect** checks the connection without sending an email. Review **Incoming server sign-in** and **Outgoing server sign-in**. **Skipped (no outgoing server)** is not a successful send test. If outgoing setup fails, **Save as receive-only** preserves incoming access.
3. **Confirm a known message appears.** Send a harmless test message to the mailbox from another account you control, then look for it in Mailera. If your workflow needs replies, plan a separate, explicitly approved send test to a recipient you control.
4. **Create a narrowly scoped key.** In **Settings**, open the API key tab and choose **Create key**. Set **Mailbox scope** to the test mailbox's group and grant **Read** first. Add **Send messages** only when the workflow needs it, including an approved send test.
5. **Check the send attempt.** After the approved test, inspect its status through `GET /sends/{id}` or `get_send_status`. Statuses include `queued`, `sending`, `sent`, `failed`, and `unknown`. Don't treat a `sent` status as proof that the message reached the recipient's Inbox.

![Mailera API key creation dialog with one mailbox group selected, Read enabled, and Send messages disabled.](https://mailera.app/media/217ef7f9fc71e178/why-a-mailera-mailbox-goes-to-sleep-and-how-to-wake-it-wake-en-1200.jpg)
_A mailbox can support sending while the agent's key remains read-only._

Check that the agent can find the expected message in the intended mailbox group and cannot send until you grant that permission.

## What commonly goes wrong?

### Reading works, but sending fails

For an IMAP connection, check whether SMTP was configured and whether outgoing sign-in succeeded. A mailbox saved with **Save as receive-only** still needs a working outgoing connection before it can send. For Microsoft, inspect the Graph connection and authorization rather than adding SMTP settings.

### Microsoft sign-in fails

Review OAuth consent and the account or tenant policy with the account administrator. Switching to an app password isn't a Mailera Microsoft connection path.

### An app password is missing or rejected

Check the provider's current requirements rather than repeatedly trying the normal account password. For Google, verify 2-Step Verification and account eligibility. Google also revokes app passwords when the Google Account password changes, which can explain a previously working connection failing.

### New mail appears later than expected

Separate provider notifications from Mailera background checks. Check connection status and whether the mailbox is sleeping before assuming that message parsing or your agent prompt is responsible.

### An API action is denied

Check the key's mailbox-group scope and action permission separately. A key with **Read** doesn't have **Send messages**. Also check provider authorization: expanding a Mailera key's permissions doesn't fix a disconnected provider account.

## How do you keep an email-reading agent safe?

Treat message bodies, subjects, attachments, and linked content as untrusted data. A message asking the agent to reveal a key, change permissions, or forward private mail to another address is content to evaluate, not an instruction to execute.

Use the narrowest mailbox-group scope and start with **Read**. Keep API keys, app passwords, and refresh tokens out of prompts, screenshots, and logs. Review the [Mailera security information](https://mailera.app/en/security) when deciding how credentials and access fit into your application.

Require confirmation in your application before sending or forwarding. Present the intended recipients and message content for approval; don't rely on an instruction inside an incoming email as that approval. Build this control into your workflow rather than assuming a connection or tool interface supplies it.

OAuth and encrypted connections don't make incoming content trustworthy. Authorization controls access; it doesn't decide whether an email's instructions should be followed.

## Which Mailera limits affect this decision?

Mailera connects existing mailboxes; it doesn't create mailboxes or new email addresses. Proton Mail and Tuta aren't supported, and Mailera doesn't provide bulk or marketing sending.

A working incoming connection doesn't establish outgoing capability. Mailera also doesn't guarantee instantaneous message arrival or Inbox placement. Choose the provider connection first, then grant only the actions your workflow actually needs.

**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)