When you first need to give an AI agent email, you search “email API” and the same names come up: Mailgun, Amazon SES, and OpenMail if you've been watching the agent infrastructure space. They look similar from the outside. They're not. Using the wrong one for your use case costs time. Here's what each one actually is.
Mailgun
Mailgun is a sending API that Sinch acquired in 2020. It's been around long enough to have solid documentation, enough volume to have real deliverability reputation, and is the default answer when someone asks “which transactional email service should I use.”
Sending is straightforward. One API call, the email goes out. SPF and DKIM are configured for your sending domain. If you're sending password resets or invoice notifications to humans, it works.
Inbound exists. Mailgun can route incoming email to a webhook: you define a route, it fires a POST request when something arrives. The latency is fine for a human checking their inbox once a day. For an agent waiting on an OTP code, it's slower than you'd want, and the whole thing requires more manual wiring than the sending side suggests. There's no threading concept. There's no attachment parsing. The payload arrives, your code handles everything from there.
On lower-tier plans, you're on a shared IP pool. Your deliverability reputation depends partly on every other sender on that pool, which you have no visibility into. Dedicated IPs are available from the Scale plan at $90/month, or as a $35/month add-on on Foundation.
Pricing: a free tier at 100 emails/day, Basic at $15/month, Foundation at $35/month for 50,000 emails, Scale at $90/month for 100,000 emails with dedicated IPs.
None of that is a problem for human-facing transactional email. It becomes a problem when your agent needs to hold a conversation, parse an invoice, and maintain thread context across five inbound messages from the same customer. Mailgun sees events, not conversations.
Amazon SES
SES is the cheapest option by a significant margin: $0.10 per 1,000 emails sent. If you're already running infrastructure on AWS, billing consolidates and the integration surface is familiar.
The catch is that SES is infrastructure, not a service. You're responsible for everything above the transport layer.
To receive email with SES, you set up an inbound ruleset, route messages to an S3 bucket or an SNS topic, write a Lambda function to process them, and wire the pieces together. That's not a complaint. It's what SES is. A primitive. If you want a working inbound pipeline, you build one.
Getting to production takes longer than it should. New accounts start in sandbox mode, which means you can only send to verified addresses until you request production access (a manual approval process that can take 24 hours or more). Once approved, you manage your own sending reputation: bounce rates, complaint rates, volume ramp. If your numbers go wrong, AWS can suspend sending without warning.
Deliverability is also on you. SPF, DKIM, and DMARC require manual configuration. Dedicated IPs are a separate add-on at $24.95/month per IP. Warmup is your problem.
For high-volume, outbound-heavy workloads where the engineering team is comfortable building and maintaining the surrounding pipeline, SES is the right call. For an agent that needs to receive replies, parse attachments, and respond in near real time, the assembly cost is high enough that it competes with actual product work.
OpenMail
OpenMail is email infrastructure built specifically for AI agents. That shows up in the product decisions, not just the positioning.
Each agent gets a dedicated inbox. Not a shared mailbox, not a forwarding rule that routes into a common bucket. One inbox per agent, its own address on your domain. If five agents are running, you have five inboxes. They don't touch each other.
Inbound delivery is webhook or WebSocket. WebSocket is the right choice for most agents because it doesn't require a public URL. The agent holds an open connection and messages arrive in 2–5 seconds. That latency matters for OTP flows, where the 30–60 second polling cycle of IMAP-based tools breaks the signup before the code expires.
Attachment parsing is included. OpenMail parses PDFs, CSVs, XLSXs, DOCXs, and images to LLM-ready text before the payload reaches your agent. The agent reads content, not MIME.
SPF, DKIM, and DMARC are configured automatically on every plan. Custom domains are included on every plan, including free. Dedicated IPs and webhook retry with delivery guarantees start at Launch.
Setup is two CLI commands:
npm install -g @openmail/cli openmail setup
Done.
Pricing: Free (€0) gives 3 inboxes and 3,000 emails/month with no credit card required. Developer is €9/month for 10 inboxes and 10,000 emails. Launch is €49/month for 200 inboxes, 150,000 emails, dedicated IPs, and inbox warmup.
Comparison
| Capability | Mailgun | Amazon SES | OpenMail |
|---|---|---|---|
| Send | ✓ | ✓ | ✓ |
| Receive | ✓ | ✓ | ✓ |
| Real-time inbound | ✓ | — | ✓ |
| Attachment parsing | — | — | ✓ |
| Per-agent isolation | — | — | ✓ |
| Managed deliverability | ✓ | — | ✓ |
| Custom domains | ✓ | ✓ | ✓ |
| Dedicated IPs | ✓ | ✓ | ✓ |
| Multi-agent scale | — | — | ✓ |
Fig. 1 — Capability Comparison
Which one
Mailgun and SES are both good at outbound. SES is cheaper at scale and more flexible if you want to own the pipeline. Mailgun is faster to get working, has better documentation for common patterns, and handles inbound if you're willing to build around the webhook payload yourself.
If your agent only sends (notifications, reports, outbound outreach), either will work. Pick based on whether you prefer managed simplicity or cheap primitives you assemble yourself.
If your agent needs to hold conversations, receive replies, handle OTP flows, or parse attachments without building the pipeline yourself, neither Mailgun nor SES was built for that. OpenMail was.
