# How do AI agents send and receive email?

An AI agent never speaks SMTP itself. It calls a tool, and the tool talks to
a mail system. That tool is usually an MCP server, a REST API, or a library
that logs into an existing inbox over IMAP or the Gmail API. Outgoing mail
is sent from a domain that publishes SPF, DKIM and DMARC so receivers trust
it. Incoming mail is stored by the mail system, and the agent finds out
about it by polling, long-polling or a webhook.

## Three ways to connect an agent to email

| Approach | How the agent uses it | Good for | Watch out for |
| --- | --- | --- | --- |
| MCP server | The agent's client lists tools such as `send_email` and `reply`, and the model calls them | Chat and coding agents: Claude, Codex, Cursor, OpenCode | Each client has its own setup and approval prompts |
| REST API | Your code makes HTTP requests and passes results to the model | Agents you build yourself, scripts, servers | You write the loop and the error handling |
| Existing inbox via IMAP/SMTP or the Gmail API | Your code logs into a person's mailbox | Assistants that must act on your own mail | Full access to that mailbox, OAuth setup, provider limits |

MCP (Model Context Protocol) is the common choice for agents people already
use, because no code is needed: you add a server URL and the agent sees the
tools. A REST API suits frameworks such as LangChain or a plain Python loop.
Logging into a personal inbox gives the agent everything in it, which is a
security decision more than a technical one.

## Sending: what makes the mail arrive

When the agent calls a send tool, the service builds a normal email (From,
To, Subject, a Message-ID and a body) and hands it to a sending server. The
receiving provider then decides whether to trust it, based mostly on three
DNS records on the sender's domain:

- **SPF** lists the servers allowed to send mail for the domain.
- **DKIM** adds a cryptographic signature that proves the domain sent the
  message and it wasn't changed on the way.
- **DMARC** tells receivers what to do when SPF or DKIM don't line up with
  the From address, such as quarantine or reject.

Authentication alone isn't enough. Receivers also look at the domain's
reputation, complaint rates and whether recipients expected the mail. That
is why agent email services watch what agents send: one agent spamming
hurts every address on the domain.

## Receiving: how mail reaches the agent

The domain's MX record points to a mail server. That server accepts the
message, scans it, stores it, and records an event. The hard part is the
last step: telling the agent.

- **Polling.** The agent lists unread mail every so often. Simple, but slow
  or wasteful.
- **Long-polling.** The agent asks "anything new since event N?" and the
  request stays open until mail arrives or a timeout passes. This works well
  for an agent sitting in a session, waiting for one reply.
- **Webhooks.** The mail service sends an HTTP POST to your server for each
  new message. Best for always-on agents, but you need a public HTTPS
  endpoint and should verify the signature.

One thing surprises people: a chat or coding agent only notices mail while
it is running and checking. If the session has ended, the mail waits in the
mailbox until the agent looks again, or until a webhook starts something.

## Threading: keeping a conversation together

Every email has a Message-ID header. A reply sets In-Reply-To to the message
it answers and carries the earlier IDs in References. Mail clients use those
headers, not the subject line, to group a conversation. An agent should
answer with a reply tool rather than a new email with "Re:" in the subject,
or the other side may see a broken thread.

## Where Botmail fits

Botmail is an agent email service. Each agent gets its own address on
`botmail.pro`, a domain that publishes SPF, DKIM and DMARC records. It
offers both connection styles:

- **MCP** at `https://botmail.pro/mcp`, with tools including `send_email`,
  `reply`, `check_inbox`, `read_conversation` and `wait_for_mail`, which
  blocks for up to 30 seconds until new mail arrives and returns a cursor
  for the next call. Setup is in [Email MCP server](https://botmail.pro/guides/email-mcp-server).
- **REST** at `https://botmail.pro/v1`, with signed webhooks and a
  long-poll events endpoint. The first call returns the latest position
  immediately:

```sh
curl -s "https://botmail.pro/v1/events" \
  -H "Authorization: Bearer $BOTMAIL_KEY"
```

Pass the `next_after` value it returns as `after`, and the request waits up
to 30 seconds for new events:

```sh
curl -s "https://botmail.pro/v1/events?after=<next_after>&wait=30" \
  -H "Authorization: Bearer $BOTMAIL_KEY"
```

Replies sent with the `reply` tool or `POST /v1/messages/{id}/reply` carry
the right threading headers. Botmail has no IMAP or SMTP access, and no
custom domains yet. For working code, see
[Send email from an AI agent in Python](https://botmail.pro/guides/send-email-from-ai-agent-python)
or [in TypeScript](https://botmail.pro/guides/send-email-from-ai-agent-typescript).

To give an agent an address, paste this into it:

```text
Read https://botmail.pro/skill.md and claim a mailbox for yourself. Send the invite to my email, then wait for me to approve it.
```

## Questions

### Do AI agents use SMTP to send email?

Usually not directly. The agent calls a tool, such as an MCP server or a REST API, and the email service handles SMTP delivery from an authenticated domain.

### How does an AI agent know a new email has arrived?

It polls the inbox, long-polls an events endpoint that waits until mail arrives, or gets a webhook. A chat or coding agent only notices mail while it is running and checking.

### Why do SPF, DKIM and DMARC matter for AI agent email?

Receiving providers use them to decide whether mail really comes from the sending domain. Without them, an agent's mail is likely to land in spam or be rejected.

---

Source: https://botmail.pro/questions/how-do-ai-agents-send-and-receive-email
Agent instructions: https://botmail.pro/skill.md
All guides: https://botmail.pro/llms.txt