Amazon SES Alternative
SES gives you the
building blocks. Ark
gives you the building.
Amazon SES is the cheapest way to send email at scale. It's also the most work. If you're building a SaaS platform where your customers send email through you, SES gives you a send API and leaves you to build everything else: tenant isolation, domain management, analytics, suppression, webhooks. Ark ships all of that out of the box.
Acme Corp
3 domains
StartupXYZ
1 domain
Agency Pro
5 domains
ShopFront
2 domains
Every tenant gets isolated domains, credentials, analytics, and suppression lists
The real cost of building on SES
Amazon SES is brilliant at one thing: sending email cheaply. At $0.10 per thousand messages, nothing else comes close. But SES is a send primitive, not a platform. If you're building a SaaS product where your customers send email through you, SES gives you the SMTP relay and leaves you to build everything on top.
That means engineering sprints. Configuration sets for tenant isolation. IAM policies for access control. SNS topics for event notifications. Kinesis Firehose for analytics pipelines. CloudWatch dashboards for monitoring. Lambda functions for bounce processing. DynamoDB tables for suppression lists. And a customer-facing UI to tie it all together.
Most teams estimate the SES integration at two weeks. Six months later, they're still maintaining a bespoke email infrastructure system that nobody wants to own.
Ark replaces all of that with a single white label email API. Multi-tenancy, domain management, analytics, suppressions, webhooks — included from day one.
What you'd build on SES
Configuration sets and tenant isolation
SES configuration sets, IAM policies per tenant, sending identity management, per-tenant credential rotation, and usage tracking across accounts.
Domain identity management
DKIM setup automation, custom MAIL FROM configuration, DNS record generation, verification polling, customer-facing onboarding UI for adding domains.
Analytics, webhooks, and suppression
SNS topic subscriptions, Kinesis event pipeline, per-tenant bounce/complaint processing, suppression list storage, webhook delivery system with retries.
Maintenance and monitoring
CloudWatch alarms, SES sending quota management, IP reputation monitoring, AWS service limit increases, infrastructure cost tracking, on-call rotations.
Multi-tenant architecture
SES has no concept of tenants. The closest abstraction is a configuration set, which groups sending behavior and event destinations. But configuration sets are flat. They don't scope domains, credentials, suppressions, or analytics. You still share a single SES account, a single suppression list, and a single set of sending identities across all your customers.
To isolate tenants properly on SES, most teams end up building a management layer: separate IAM users or roles per tenant, tagging on every send call, custom Lambda functions to route events by tenant, and a database to track which domain belongs to which customer. It works, but you've built an email platform on top of a send API.
Ark's entire system is organized as a white label email API hierarchy: Platform, Tenants, Domains, and Email. When you create a tenant in Ark, everything is scoped to that tenant — their domains, credentials, webhooks, suppression lists, and analytics. There's no IAM to configure, no tagging to manage, no Lambda functions to maintain.
SES approach
Flat structure · Shared suppression · No tenant concept
Ark approach
Tenant A
Tenant B
Tenant C
No tenant limit · Isolated by default · All plans
SES configuration sets
- Flat structure, no tenant hierarchy
- Shared account-level suppression list
- IAM policies for access control (you build it)
- No per-tenant analytics or webhooks
Ark tenants
- Platform > Tenants > Domains > Email hierarchy
- Per-tenant suppression lists, automatic
- Scoped credentials and API keys per tenant
- Built-in per-tenant analytics and webhooks
Domain management and onboarding
SES uses Easy DKIM, which generates three CNAME records per domain. You can also configure a custom MAIL FROM domain, which adds another MX and TXT record. The records get generated through the SES console or SESv2 API, and then your customer has to manually add them to their DNS provider.
There's no customer-facing onboarding UI. No guided setup. No provider-specific instructions. You either build that experience yourself, or your support team walks customers through DNS configuration over email. Neither option scales well past a dozen customers.
Ark provides guided domain onboarding. When a tenant adds a domain, Ark detects their DNS provider and shows them the exact steps for their specific provider. There are dedicated setup guides for Cloudflare, Vercel, Namecheap, Porkbun, GoDaddy, DigitalOcean, Netlify, and more. After the records are added, the verify endpoint checks the DNS configuration and confirms everything is set up correctly.
For a deep dive into DNS setup, SPF/DKIM/DMARC configuration, and reputation isolation for platforms, read our guide to sending email from your customer's domain.
Sending domain
We'll show Cloudflare-specific DNS instructions
Required DNS records
TXTSPF VerifiedCNAMEDKIM VerifiedCNAMEReturn PathPending[email protected]Hard bounceEach tenant's suppression list is independent — Acme's bounces don't affect StartupXYZ
Hard bounce
Instant suppression
Spam complaint
Instant suppression
Soft bounce
18 retries over 48h
Deliverability and suppression management
SES has an account-level suppression list. When a recipient bounces or complains, SES suppresses that address for your entire account — across all tenants. There's no way to scope suppression per customer. If Tenant A sends to an address that bounces, Tenant B can't send to that address either, even if the bounce was specific to Tenant A's sending domain.
Dedicated IPs on SES cost $24.95 per month each. You can assign them to configuration sets, but managing IP warmup, rotation, and reputation across tenants is entirely your responsibility. SES provides the raw infrastructure; you build the management layer.
Ark manages per-tenant suppression lists automatically. Hard bounces trigger immediate suppression for that tenant only. Spam complaints result in instant suppression. Soft bounces are retried up to 18 times over roughly 48 hours before the address is suppressed. This all happens per-tenant, so one customer's bounces never affect another.
On the Scale plan, tenants can get dedicated IPs if they need full IP reputation control. But for most platforms, per-tenant domain reputation combined with automatic per-tenant suppression is what actually keeps deliverability healthy.
Pricing comparison
SES wins on raw email cost. But the total cost of ownership includes the infrastructure you build around it.
Amazon SES
Pay-as-you-go
- 3,000 free/mo from EC2
- Dedicated IPs at $24.95/mo each
- SESv2 API and SMTP
- SNS for event notifications
- Multi-tenant architecture
- Per-tenant suppression lists
- Guided domain onboarding
- Per-tenant analytics
- +SNS notifications ($0.50/1M)
- +Kinesis Firehose for analytics
- +CloudWatch alarms and dashboards
- +Lambda for event processing
- +Engineering: 2-4 sprints ($40K-$120K)
Ark Starter
Full multi-tenant features
- 50K emails/month included
- Unlimited tenants
- Up to 10 domains
- Per-tenant suppression lists
- Guided DNS onboarding
- Per-tenant analytics
- Two-level webhooks
- Full message logs
An honest note about pricing
SES is cheaper per email. At $0.10 per thousand messages, nothing else comes close on raw send cost. If you have an engineering team that's already built the multi-tenant layer and you're happy maintaining it, SES is the most cost-effective option. Ark's value is in the infrastructure you don't have to build: the tenant isolation, domain management, analytics pipeline, suppression system, and webhook delivery. For most platform teams, the engineering cost of building and maintaining that on SES far exceeds the difference in email pricing.
As you scale, Ark's Growth plan ($99/month) supports 100 domains and 250K emails. The Scale plan ($499/month) supports 1,000 domains and 2M emails with dedicated IP options.
$ curl -X POST \
https://api.arkhq.io/v1/tenants/{id}/messages
{
"to": "[email protected]",
"from": "[email protected]",
"subject": "Order confirmed",
"html": "<h1>Thanks!</h1>"
}
# 200 OK — message queued
/emails/emails/batch/tenants/{id}/domains/tenants/{id}/suppressions/tenants/{id}/webhooks/tenants/{id}/credentials/tenants/{id}/usage/platform/webhooksDeveloper experience
SES uses IAM for authentication, which means managing access keys, roles, and policies. The SESv2 API is well-documented but ceremonious — sending an email requires constructing a SendEmail request with nested Destination, Content, and Body objects. It's the AWS way.
Ark's API is a clean REST interface. Bearer token authentication. Flat JSON payloads. Tenant-scoped endpoints where the tenant ID is in the URL path, not a tag or header. There are 66 endpoints covering the full lifecycle: tenants, domains, credentials, messages, webhooks, suppressions, usage tracking, and logs.
Official SDKs are available for Python, Node.js, Ruby, and Go. Ark also ships with SMTP support for platforms that need it. Self-hosted tools like Listmonk, Coolify, or Metabase can send through Ark by changing one SMTP configuration.
26 MCP tools for AI assistants. Manage email infrastructure using natural language.
Per-customer analytics and event handling
SES publishes events to SNS topics, Kinesis Firehose, or CloudWatch. You pick a destination, build the pipeline, parse the events, and store them somewhere queryable. Want per-tenant analytics? You'll need to tag every send with a tenant identifier, then filter and aggregate events by that tag in your own analytics system.
That's a real engineering project. SNS delivers events as JSON to Lambda functions or HTTP endpoints. Kinesis requires a consumer application. CloudWatch gives you metrics but not per-message detail. Most teams end up building all three to cover different use cases.
Ark provides per-tenant message logs, delivery status tracking, and bounce analysis out of the box. Every message sent by a tenant is queryable through the API with full delivery details. Webhooks come in two levels: tenant-level webhooks that fire for a specific tenant's events, and platform-level webhooks that fire for all tenants with a tenant_id field in the payload.
{ "event": "delivered",
"tenant_id": "ten_abc123",
"message_id": "msg_xyz",
"recipient": "alice@..." }
3+
AWS services to build event pipeline
0
Infrastructure to build with Ark
Who should switch to Ark
Platform teams that don’t want to become email companies
You’re building a SaaS product, not an email infrastructure platform. You want multi-tenant email to work out of the box so your team can focus on your actual product.
Small-to-mid engineering teams (2-20 engineers)
You don’t have a dedicated email infrastructure engineer and don’t want to hire one. Every sprint spent on SES plumbing is a sprint not spent on your product.
Teams tired of maintaining custom SES infrastructure
You’ve already built the SES layer and it works, but maintaining it is a drag on your team. Lambda functions, SNS subscriptions, IAM policies, CloudWatch alarms — it adds up.
Teams scaling from a few to many customers
You started with SES and a single configuration set. Now you have 20 customers and need proper tenant isolation, per-customer analytics, and domain management that scales.
When SES is still the right choice
We're not going to pretend Ark is the right tool for everyone. SES has genuine strengths that make it the better choice for certain use cases.
If you have a dedicated email engineering team, SES gives you maximum flexibility. Your team can build exactly the system they want, optimized for your specific requirements. The raw cost advantage is real, and if you have engineers who know AWS infrastructure well, the maintenance burden is manageable.
If you've already built a working system on SES, don't switch for the sake of switching. If your custom SES infrastructure is stable, well-maintained, and your team is comfortable owning it, the migration cost may not be worth it. Ark is for teams that haven't built that layer yet, or teams that are tired of maintaining it.
If you need raw AWS flexibility, SES integrates natively with Lambda, S3, Kinesis, IAM, and the entire AWS ecosystem. If your email pipeline is deeply embedded in AWS infrastructure — triggering Lambda functions, storing to S3, processing through Kinesis — SES is the natural fit.
If you're not doing multi-tenant email, Ark's primary value is tenant isolation and per-customer email management. If you're a single company sending your own email, SES is simpler and cheaper. You don't need the multi-tenant overhead.
Also compare
What migrating from SES looks like
The migration from SES to Ark is straightforward. The biggest win is all the infrastructure you get to delete.
Set up tenant hierarchy
Map your customers to Ark tenants. Each tenant gets created via the API or dashboard. Attach metadata to store your internal customer IDs and any SES configuration set references.
Add and verify sending domains
Use the API to add each customer’s domain to their tenant. Ark returns exact DNS records needed. Customers follow guided setup for their specific DNS provider. Your existing SES DKIM records won’t conflict.
Swap send calls
Replace SESv2 SendEmail calls with Ark’s REST API or SMTP endpoint. The message format is simpler — flat JSON instead of nested AWS request objects. If you use SMTP, it’s a configuration change.
Set up webhooks and remove SES event pipeline
Configure Ark webhooks to replace your SNS/Kinesis/Lambda event pipeline. Once webhook delivery is confirmed, decommission SNS topics, Kinesis streams, Lambda functions, and CloudWatch alarms.
Run in parallel, then cut over
Send a percentage of traffic through Ark while keeping SES active. Monitor deliverability and events. Once confident, move all traffic to Ark and delete the remaining SES infrastructure.
Most teams complete the migration in 1-2 days for the integration work, plus whatever time their customers need to update DNS records. The best part is deleting the Lambda functions.
FAQ
Stop building email infrastructure.
Start shipping your product.
Delete the Lambda functions. Decommission the SNS topics. Let Ark handle multi-tenant email so your team can focus on what matters.