Building the agent's mail layer yourself on SES
Amazon SES sends email for a fraction of a cent, receives it into S3, and is about as reliable as infrastructure gets. If you are technical and cost-sensitive, building directly on it is a reasonable instinct, and worth costing honestly rather than dismissing.
4 min read
This is the list of what sits between SES and a working agent.
What SES gives you
Sending with DKIM signing, a receiving rule set that drops raw MIME into S3, delivery and bounce notifications through SNS, dedicated IP pools if you want them, and configuration sets for per-tenant event routing. That is a genuinely strong foundation, and everything below is built on exactly this.
What you build on top
MIME parsing. Multipart bodies, encodings, inline images, attachments, and the long tail of clients that do unusual things. Not hard, but not a weekend, and the bugs arrive from real mail rather than from your tests.
Threading. Assembling conversations from In-Reply-To and References, handling forwards and top-posting, and stripping quoted history so a model is not re-reading the same paragraph six times, per how email threading actually works.
Identity and scope. Per-agent addresses, per-agent keys, and a permission model so one agent cannot read another's mail or reach credentials it was not granted, per deciding what each agent is allowed to see.
Waiting. A server-side wait so an agent can ask a question and resume when the answer arrives, without holding a process or polling.
Suppression. Bounce and complaint handling that refuses later sends at the infrastructure layer rather than depending on your code remembering, per bounces, complaints, and suppression.
Sending discipline. Classification of replies against first contact, unsubscribe on cold mail, duplicate-content and velocity checks, and refusals with reasons an agent can act on rather than exceptions.
Domain onboarding. The wizard that tells a customer which records to publish, checks them, and handles the DKIM tokens SES issues per domain, plus a nightly reconcile for the ones still pending.
Contact memory, notes, and a vault. None of these are mail at all, and all of them are what makes the second conversation better than the first.
An oversight surface. Somewhere a non-technical colleague can read threads, take one over, and see what was sent. This is the one people forget entirely and then need on day three.
| Layer | Rough effort | Ongoing |
|---|---|---|
| Parsing and threading | Weeks | Bug tail from real mail |
| Identity, keys, scope | Weeks | Security surface you own |
| Waiting and resume | Days | State to maintain |
| Suppression and classification | Weeks | Correctness matters commercially |
| Domain onboarding | Weeks | Every customer touches it |
| Oversight UI | Weeks | Never finished |
When building is right
Three cases, and they are real.
Email is your product. If you are building an email product, this is your core competency and you should own it. Buying it would be buying your differentiator.
Extreme volume with a simple shape. At very high volume with one message type, the per-message economics can justify a team, and the feature list above shrinks because you need less of it.
A constraint nothing else meets. A residency, contractual, or air-gapped requirement that no provider satisfies. This is rarer than it is claimed, and worth testing before it becomes an architecture.
When it is not
If email is a feature of something else you are building, the list above is a quarter of engineering time that produces no differentiation, followed by permanent maintenance. The failure mode is not that it cannot be done; it is that it gets done to eighty percent, and the missing twenty is threading edge cases, suppression correctness, and the oversight surface, which are exactly the parts that hurt in production.
The honest test: would you be proud to show this to a customer as a reason to choose you? If email is your product the answer is yes, and if it is not, it never will be.
The middle path
Worth knowing: this is not binary. Plenty of teams keep bulk or transactional sending on SES directly, where it is cheap and well understood, and put conversational agent mail on infrastructure built for it, per you already send with a transactional provider.
That split costs nothing, keeps your cheap path cheap, and confines the complicated part to the mail that actually needs it. The feature-level comparison is at MCPmailer versus Amazon SES.
Questions
- Can I build an AI agent email stack on SES?
- Yes. SES handles sending, receiving into S3, and event notifications. What you build on top is parsing, threading, identity and scope, waiting, suppression, classification, domain onboarding, memory, and an oversight surface.
- How long does that take?
- A quarter of engineering time to a good state, and permanent maintenance after that. The bug tail comes from real mail rather than your test suite.
- What is most often left out?
- The oversight surface, where a non-technical colleague reads threads and takes one over. It gets skipped in planning and needed on day three.
- When is building the right call?
- When email is your product, when volume is extreme and the message shape is simple, or when a hard constraint rules out every provider.
- Is it cheaper?
- Per message, yes. Once engineering time and ongoing maintenance are counted, only at volumes where the message shape is simple enough that you need less of the list.
- Can I do both?
- Yes, and many teams do: bulk and transactional straight on SES, conversational agent mail on infrastructure built for it, split across separate subdomains.
Give your agent an address it can answer from.
Create an inbox