Your Email Sender Wasn't Built for Replies: An Inbound Checklist for AI Agents

The first week goes fine. Your agent sends a welcome note, a quote, a follow-up. The sending service you already use for receipts delivers every one. Then customers start hitting Reply, and you notice the part nobody planned for: where do those replies go, and how does the agent know what it said last time?

Most teams pick an email provider for outbound. That choice made sense when email was something your product sent and forgot. An agent is different. It sends, waits, reads the answer, and keeps a conversation going for days. That is an inbox job, and a sending pipe with an inbound hook bolted on often leaves the hardest parts to you.

This post is a checklist you can run against any provider before you trust it with agent replies, plus how Mermail handles each item.

TL;DR

• Ask five questions: where does a reply land, what ties it to a thread, how long is it kept, what happens when your endpoint is down, and how do you treat it as untrusted input.
• If the honest answer to the first three is "your database," you are building an inbox yourself.
• Mermail gives each agent its own mailbox with stored threads, search, signed webhooks, drafts, and MCP with OAuth, so the agent can read history instead of you rebuilding it.

Why a sending service struggles with replies

A sending service is optimized for one direction. You hand it a message, it handles authentication, delivery, bounces, and suppression. Inbound is usually a side feature: mail for your domain is matched against rules you write and forwarded to a URL. Each message arrives alone, as a POST, and then it is your problem.

That works when replies only need a handler. A support form that turns a reply into a ticket can live with it. It breaks down when the agent itself is the one in the conversation, because the agent needs three things a forwarding rule does not give it:

• An address it owns. Not a regex over a shared domain, but a mailbox that belongs to this agent and can be listed, paused, or retired.
• A thread it can reread. The reply arrives with In-Reply-To and References headers, and someone has to turn those into a conversation. With a pipe, that someone is your code.
• History that lasts. Short message retention is fine for debugging. It is not fine when the agent needs to reread last month's quote before answering a follow-up.

None of this is a flaw in sending services. They were built for receipts. The mismatch only shows up once an agent has to answer.

The five-question inbound checklist

Run these against whatever you use today. Write the answers down, because each "we handle that" on your side is code you will own forever.

1. Where does a reply land?

Good answer: in a mailbox tied to the agent, where it stays until you decide otherwise. Weak answer: it is posted to your URL and nothing is kept. If you run many agents, also ask how you tell them apart. Routing every agent through one catch-all domain and parsing the local part works, but it couples every agent to one rule set. We compared the two designs in catch-all domain or one mailbox per agent.

2. What ties a reply to its conversation?

Email threading runs on the Message-ID, In-Reply-To, and References headers defined in RFC 5322. If the provider does not group messages into threads, you store every message, index those headers, and rebuild the conversation before each reply. Ask whether there is a thread you can fetch in one call.

3. How long can the agent read it back?

Ask for the retention window in writing and check which plan it applies to. If stored messages expire in days, the agent's memory of the conversation is whatever you copied out in time.

4. What happens when your endpoint is down?

Every push-based design has a retry window. Find out how long it is, which status codes trigger a retry, which ones drop the message, and whether events can arrive twice. An agent server that is down overnight should not mean lost customer replies.

5. How do you treat inbound as untrusted?

Mail from strangers is input from strangers. Ask how deliveries are signed, whether spam and authentication results reach you, and whether you can read a sanitized body instead of raw HTML. An agent that acts on email is a target for prompt injection, and the provider should help you keep content separate from instructions.

How Mermail answers each question

Mermail was built as an inbox for agents first, with sending as one part of it. Here is how the checklist maps to what is documented today.

Replies land in the agent's own mailbox

Each agent gets a mailbox on a hosted @mermail.app address or on your own verified custom subdomain (custom domains are on Developer and Enterprise). Inbound mail is saved into the mailbox, and the standard hosted service retains mailbox content so the agent can come back to it. Hosted mailboxes can also use plus aliases such as myagent+quotes@mermail.app, which share the same inbox, limits, and permissions. See the Email module docs.

Threads are a first-class object

You do not rebuild the conversation from headers. The API has a Get thread endpoint and a safe context endpoint that returns the selected message plus an oldest-first, paginated thread page. That context call strips sensitive transport metadata, sanitizes bodies to bounded plain text, and omits bodies of inbound mail that did not scan clean. Search covers the rest when the agent needs to find an older message first.

Push events with a clear retry contract

If you want replies pushed instead of polled, email webhooks send a message.received event when new inbound mail is saved in a selected mailbox. Any 2xx response acknowledges delivery. Connection failures, timeouts, 408, 429, and 5xx responses retry with increasing delays for roughly 24 hours, while other responses fail without retry. Events can arrive more than once or out of order, so deduplicate on event_id. Because the mail itself stays in the mailbox, a missed event is a delay, not a lost reply: the agent can still search for it. We walked through a full setup in email to webhook for AI agents.

Signed deliveries and sanitized reads

Mermail signs every webhook delivery. Verify the signature, reject stale timestamps, and only then trust the event. When the agent reads mail through MCP, searches can require a clean scan status. The restricted agent-inbox profile goes further and enforces metadata-only, clean-scan, agent-safe content on list operations, which suits agents that mostly need to read.

Drafts before sends

Answering a reply is where mistakes get expensive. Mermail can save drafts and regenerate draft copy, so the agent prepares the answer and a person approves it. Start with drafting. Earn the right to automate the send.

A practical setup for an agent that answers email

1. Create one mailbox per agent or per job, on a hosted address or your custom subdomain. The Agent email inbox guide covers reuse and creation rules.
2. Connect your assistant through MCP with OAuth for interactive hosts, or use an API key for automation and the CLI for scripts and CI. Not sure which? Read MCP, CLI or REST API for agent email.
3. Add a webhook for message.received on that mailbox. Return 2xx fast and put the real work on a queue.
4. When an event arrives, fetch the thread context, not just the single message, so the agent answers with the whole conversation in view.
5. Have the agent save a draft reply. Review drafts for a week, track what you would have changed, then decide which reply types can go out on their own.
6. Watch for autoresponders before you automate anything. Our guide to out-of-office replies and mail loops covers the filters to add.

You can set all of this up from the Mermail console.

When a sending service is still the right call

Keep your current provider for what it does well: product email at volume, receipts, alerts, and replies that only need to reach a fixed handler. The checklist is not about replacing it. It is about noticing the moment an agent becomes a participant in the conversation, because that is when you need an inbox, not a pipe. If you are still deciding what that inbox should look like, start with what an agent inbox is.

FAQ

Can I keep my existing sending provider and add Mermail for replies?

Yes. You can keep product email where it is and give the agent its own Mermail mailbox for the conversations it has to carry. Just make sure the agent sends and receives on the same address, so the thread stays in one place.

Which interface should my agent use?

Mermail documents an MCP server, a CLI, and a REST API. Use MCP for assistants, the CLI for scripts, and the API from any language that can make HTTP requests.

What if my webhook endpoint is down for a day?

Webhook deliveries retry for roughly 24 hours, and the message is already saved in the mailbox either way. After you recover, search the mailbox for anything you did not process and use event_id to skip duplicates.

Is a verified sender safe to act on?

Authentication tells you who sent the message, not that the request is allowed. Email content cannot authorize an agent action. Keep approvals for anything that sends, pays, or changes an account.

References

• Mermail docs: Email webhooks
• Mermail docs: Get thread
• Mermail docs: Agent email inbox
• Mermail docs: Email module
• RFC 5322: Internet Message Format
• OWASP Top 10 for LLM Applications: Prompt Injection