vs Amazon SES·Raw infrastructure·6 min read

Amazon SES vs Mails.ai — raw infrastructure vs agent-native API

aws.amazon.com/ses/

Amazon SES is the cheapest email infrastructure available, and we run on it. The comparison is not Mails.ai-vs-SES — it is "agent-native API" vs "raw infrastructure." Different layers of the stack. The honest decision is whether you want to build the agent-API layer yourself.

What SES does well

SES at $0.10 per 1,000 emails is extreme cost efficiency. Petabyte-tier proven (Amazon dogfoods it for its own services). Native AWS integration — IAM for auth, CloudWatch for metrics, Lambda for inbound triggers, S3 for content storage, SNS for bounce/complaint notifications. Full enterprise compliance posture (SOC 1/2/3, HIPAA-eligible, PCI, FedRAMP, ISO 27001) that no application-layer vendor can match.

For an organization that is already deeply invested in AWS, with engineers comfortable in IAM policy authoring and CloudWatch dashboards, with the bandwidth to build agent primitives on top — SES is the right answer.

Where mails.ai is built differently

We sit ABOVE SES, not against it. The infrastructure SES provides is delivery; the layer we add is what an agent product actually needs:

Typed reply events. Inbound parsed into structured events with intent, entities, urgency, injection_score, sender_reputation. SES inbound delivers raw MIME to a Lambda or S3 bucket; you parse intent and entities yourself. See that post.
Prompt-injection scanning. Six-category scanner on every inbound. RCE-class defense for any agent reading inbound text. SES provides no equivalent. See that post.
Behavioral pool routing. Auto-segregation by behavior. SES customers segregate via configuration sets they configure manually per-account. Manual configuration scales; behavioral segregation auto-scales. See that post.
MCP-native distribution. Drop-in MCP server for Claude Code, Cursor, and other MCP runtimes. SES has no MCP server. See that post.
Real-time observability dashboard. Per-agent send + reply + classifier metrics in one view. AWS Console works but is not designed for the agent-product use case.

The cost question

SES at $0.10 per 1,000 sends ($0.0001 per email) is roughly 10× cheaper than our metered rate of $0.001 per send. The difference is the cost of the layer above: typed reply events, injection scanning, classifier, dashboard, MCP server. For most agent products at most volumes, the time saved by not building those primitives is worth more than the cost differential. For high-volume transactional senders where the layer above is over-budget for the value, direct SES wins.

The honest math:

A 100,000-emails-per-month agent product on SES: $10/month delivery cost, plus engineering time to build + maintain the agent-API layer (~2-4 engineer-weeks initial, ongoing maintenance).
Same agent product on Mails.ai Scale tier: $99/month, no engineer time on agent-API layer.
The breakeven depends on the value of those engineer weeks. For most VC-funded startups, $99/month is cheaper than 2-4 engineer-weeks. For enterprise teams with dedicated email-infra engineers, SES wins.

When to pick SES

You are deeply invested in AWS (IAM, CloudWatch, Lambda comfortable).
You have engineering bandwidth to build the agent-API layer yourself.
Your scale is high enough that per-event pricing matters (hundreds of millions per month).
You need full enterprise compliance posture (SOC 1, FedRAMP, ISO 27001) today.
You want maximum flexibility and minimal vendor lock-in.

When to pick mails.ai

Your team is not AWS-native.
You want agent primitives shipped, not built.
Onboarding speed matters (5 minutes vs half a day).
Typed reply events + prompt-injection scanning + MCP-native are load-bearing for your product.
You are pre-SOC-2 enterprise procurement (we are on the Phase 2 roadmap).

Use both

Phase 2 roadmap includes bring-your-own-SES — your AWS account, your IPs, your compliance perimeter, our agent-API layer on top. Best of both worlds for customers with existing SES warmth or AWS volume discounts. Closed-beta cohort members can request early access.

Migration notes

Direct-SES users moving to Mails.ai: most send code can be swapped via a single SDK import change. The bigger lift is the inbound handler — SES inbound goes to Lambda with raw MIME; ours delivers typed reply events to a webhook. The Lambda parsing logic you wrote becomes mostly unnecessary. Migration guide ships at Phase 1 launch.

Side-by-side

Amazon SESvs Mails.ai — feature matrix.

Dimension	Mails.ai	Amazon SES
Layer of the stack	Agent-native API + dashboard + SDK + MCP server	Raw send/receive infrastructure (we use SES as our backend)
Onboarding time	Sign up + drop SDK in agent code (~5 min)	AWS account + IAM policy + SES setup + sandbox-out request + DKIM + identity verification (~half day)
Language SDKs	TypeScript + Python (Phase 1) + MCP server	AWS SDK in every major language (Node / Python / Java / Go / Ruby / PHP / .NET / Rust)
Dashboard	Real-time send + reply + classifier dashboard	AWS Console (functional, not designed for sending observability)
Inbound parsing	Typed reply events (intent, entities, urgency, injection score, sender reputation)	Inbound ruleset → Lambda or S3. Body parsing on you.
Prompt-injection scanning	Six-category scanner, injection_score on every event, above 0.95 the event is flagged `quarantined`	Not in scope (raw infra)
Behavioral pool routing	Behavioral classifier auto-segregates senders	Configuration sets per-account (manual segregation, you maintain)
MCP-native distribution	Drop-in MCP server for Claude Code, Cursor, etc.	No MCP support
Pricing	Free / Pro $20 / Scale $99 monthly; Metered coming soon ($0.001/send + $0.002/inbound (+$0.003 opt-in classify))	$0.10 per 1,000 emails — extreme cost efficiency at scale
AWS ecosystem integration	Webhook-based (any infra)	Native IAM, CloudWatch, Lambda, S3, SNS integration
Scale ceiling	Inherits SES limits (we run on top); per-customer rate limits	Petabyte-tier proven (Amazon dogfoods it for own services)
Compliance posture	Phase 2 SOC 2 Type II (DPA on request)	SOC 1/2/3, HIPAA-eligible, PCI, FedRAMP, ISO 27001 — full enterprise compliance

FAQ

Questions readers ask after this page.

If you use SES as backend, why pay you instead of going direct?

If you have engineering bandwidth to build the typed-reply-event parser, the prompt-injection scanner, the behavioral classifier and pool routing, the dashboard, and the MCP server yourself — go direct to SES, it is cheaper. Most agent-product teams do not have that bandwidth or do not want to build it. We bake those in. The cost difference is the price of the abstraction layer, not the underlying delivery.

Can I bring my own SES account?

Bring-your-own-AWS is on the Phase 2 roadmap — your sends route through your SES account and IPs while still passing through our typed-reply-event + injection-scanner pipeline. Useful for customers with existing SES warmth or AWS volume discounts. Closed-beta cohort members can request early access.

Will SES ship typed reply events or an injection scanner?

Unlikely. AWS's SES roadmap focuses on infrastructure scale and compliance, not application-layer abstractions. The agent-API layer is consistently the responsibility of an upstream vendor (us, AgentMail, Resend, etc.). AWS ships the truck; we ship the moving service.

What about deliverability — does going through you mean shared-IP risk?

Behavioral pool routing handles this. Clean (transactional) and Outbound (cold + KYC) run on separate AWS account boundaries by Phase 2. Within Clean, the behavioral classifier auto-segregates cold-pattern senders to Mixed before they affect Clean reputation. Net: better deliverability than direct SES with manual configuration sets, because the segregation happens behaviorally rather than by account boundary you maintain.