Anjal vs Amazon SES — Comparison

Amazon SES is the cheapest reliable way to get email out of a machine, and we know that better than most: Anjal sends through SES. It is our relay. So this is not a post about SES being bad. It is a post about what SES is, what it is not, and how much of the gap you end up writing yourself.

SES is a pipe. An agent needs a mailbox.

Quick summary

	Anjal	Amazon SES
What it is	Mailboxes for agents: send, receive, thread, search	A send API and an inbound event source
Pricing model	Per-inbox subscription from $5/mo	Per email, from $0.10 per 1,000
Receiving	Real inbox, IMAP, threads kept	Delivered to S3, SNS or a Lambda; you build the rest
Threading	Message-ID, In-Reply-To and References written and tracked	You parse and store headers yourself
Per-agent addresses	An inbox is the unit	You design the addressing scheme
MCP server	Yes (`anjal-mcp`)	No
Time to a working agent loop	Minutes	Days, and then you own it

Pricing, honestly

SES is cheaper per message and it is not close.

Outbound à la carte is $0.10 per 1,000 emails. The Essentials plan is $0.16 per 1,000 up to 10M a month, falling to $0.11 above 100M. Inbound is $0.10 per 1,000 emails plus $0.09 per 1,000 incoming chunks. A managed dedicated IP is $15/month/account. Virtual Deliverability Manager is $1,250/month per region per account. (AWS pricing page, as of 2026-09.)

Anjal is $5/month for Starter (2 inboxes, 6,000 emails, 2 domains), $15/month for Developer (10 inboxes, 20,000 emails, 10 domains) and $199/month for Startup (200 inboxes, 150,000 emails). Growth past a plan is a $2/month add-on per extra inbox, domain or 1,000 emails. There is a 7-day trial.

At 20,000 emails a month, SES outbound costs about $2 and Anjal Developer costs $15. If your only requirement is "put this message on the internet", SES wins on price and you should use SES.

The comparison only becomes interesting when your agent has to read the reply.

What SES gives you on the inbound side

SES can receive mail. It is worth being precise about what that means, because "SES supports inbound" is true and also does most of the work of hiding the problem.

An inbound rule set can write the raw message to S3, publish to SNS, or invoke a Lambda. What arrives is an RFC 5322 blob. To turn that into something an agent can use, you write:

MIME parsing, including multipart, quoted-printable, and the encodings that show up in real mail from real people
attachment extraction and storage, with size limits
a threading model: read Message-ID, In-Reply-To and References on the way in, and write them correctly on the way out, or every reply starts a new thread in the recipient's client
quote stripping, so the agent reads the new text and not the last six messages again
a store with search, because an agent asking "what did they say about pricing" needs an index, not an S3 prefix
bounce and complaint handling from SNS, and a policy for what to do when an address goes bad
a per-agent addressing scheme, plus the routing rules to match it

None of this is hard. All of it is real work, and all of it is yours to maintain. We know the size of it because we wrote it.

The part that is genuinely different

The gap is not a feature list. It is that SES has no concept of a mailbox, and an agent loop is built around one.

With SES you hold a stream of events and a bucket of blobs, and you assemble state from them. With Anjal the inbox is the primitive: it has an address, a thread list, unread state, IMAP and SMTP credentials if a human wants to open it in Apple Mail, a calendar, and an API where "list threads in this inbox" is one call. An agent asks what arrived, reads a thread, replies in it, and the reply lands as a proper continuation in the recipient's client because the headers were written for it.

There is a security dimension too, and it only exists once you have an inbox. Inbound mail is attacker-controlled text that an LLM is about to read. Anjal scans every inbound message for prompt injection and quarantines the ones that combine a hostile pattern with a model judgement, so the agent never sees them. On SES that is another thing you would build, and most teams do not know they need it until an agent follows instructions it found in an email.

When to pick Amazon SES

Be honest about this, because SES is the right answer often.

You only send. Notifications, receipts, password resets, alerts. No agent is reading replies. SES is cheaper and you do not need an inbox.
Volume is your dominant cost. At millions of messages a month the per-message price difference dwarfs everything else, and building the inbound layer amortises.
You are already deep in AWS. IAM, VPC endpoints, CloudWatch, a compliance story that wants everything in one account. SES fits a stack that already exists.
You want to own the whole thing. Some teams genuinely should. If mail handling is core to your product rather than plumbing under it, build it.

When to pick Anjal

Your agent has to read and reply. Two-way is the whole reason the inbox exists.
You need many addresses. An inbox per customer, per campaign, per agent, created by API, isolated by workspace.
You want the loop working today. Create an inbox, send, receive a webhook or a WebSocket event, reply in thread. No parsing layer to write.
You want agents to reach it over MCP. Claude, ChatGPT and Codex connect to mcp.anjal.app and get the mailbox as tools, with no glue code.
You want inbound treated as hostile by default, because it is.

The honest middle

You can have both, and plenty of people should. Send your bulk transactional traffic through SES directly, and give the agents that need to hold a conversation their own Anjal inboxes. They are not competing for the same job. Anjal itself sits on SES for exactly this reason: SES is very good at the part it does.

Verdict

If nothing reads the reply, use SES. If something does, the question is whether you want to spend a week building a mailbox and then own it, or spend $15 a month not to.

Try it: anjal.app gives you a working inbox and a 7-day trial. Related reading: Anjal vs Resend, Anjal vs Mailgun, and why Gmail doesn't work for AI agents.

SES pricing quoted from the AWS SES pricing page as of 2026-09. AWS changes prices; check the source before making a decision on the numbers.