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

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.

IMAP vs SMTP: access is not submission

The IMAP specification 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 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 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 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 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.

For Microsoft, choose Sign in with Microsoft. Mailera doesn't connect Microsoft mailboxes with app passwords. The Microsoft provider page covers that connection path.

Mailera's Gmail connection uses an app password. That describes Mailera's connection method, not a claim that Gmail lacks other authorization options. Google's app-password guidance 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 separates Incoming server (IMAP) from optional Outgoing server (SMTP). You can connect incoming mail without setting up sending.

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 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.

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

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. The developer overview covers the application interfaces, while Mailera's MCP tools by task 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.

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 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.