How to choose a transactional email API (deliverability, SES, cost)
Choose a transactional email api service: deliverability, SES vs managed APIs, warm-up, cost at 10k emails, lock-in. For password resets to receipts.
If you are building password reset flows, receipt delivery, or webhook-triggered notifications, you are choosing a transactional email API. The decision is not about which provider has the cleanest dashboard or the most familiar brand. It is about whether the emails land in the inbox, what you pay at 10,000 sends and at 500,000, who owns your suppression list when you leave, and whether you are operating email infrastructure or renting it.
The providers are not interchangeable. Some give you an API key and abstract the whole stack. Others give you direct access to Amazon SES running in your AWS account, where you own the configuration and the data but also the setup and the monitoring.
This is the full breakdown: what makes a transactional email API service different from a marketing ESP, the deliverability criteria that actually matter, the cost structure at realistic volumes, and the lock-in points that are invisible until you try to leave.
What “transactional email API” means vs marketing platforms
A transactional email is triggered by user actions or system events: a password reset link, a receipt, a security alert, a webhook notification from Stripe or GitHub. The recipient expects it, it is contextually relevant, and it must arrive promptly. Missing a password reset email is not a minor deliverability issue — it is a broken product.
A marketing email is a newsletter, a promotion, a drip campaign. It is bulk, it is scheduled, and the recipient may or may not want it. Missing one is unfortunate but not blocking.
The technical difference shows up in three places:
Delivery guarantees and latency. Transactional mail must send immediately and reliably. Most transactional email platforms guarantee delivery within seconds and expose retry logic, queuing, and failure webhooks. Marketing platforms batch sends over hours or days to manage IP warm-up and avoid triggering rate limits.
Suppression list scope. A marketing platform suppresses unsubscribes globally — opt out of one campaign and you are out of all campaigns. A transactional system suppresses bounces and complaints but typically does not suppress unsubscribes from transactional sends, because you cannot unsubscribe from a password reset.
Sending reputation and IP pools. Marketing platforms share IP pools across many customers, because list-based sending benefits from scale and established domain reputation. Transactional platforms often isolate sends by customer or provide dedicated IPs, because one customer’s spam should not delay another customer’s password reset.
CAN-SPAM and GDPR both distinguish transactional email from marketing email. The legal definitions matter, but the practical distinction is simpler: if the recipient is waiting for it, it is transactional. If you are interrupting them, it is marketing.
Decision table: managed API vs running SES in your AWS account
The first fork in the decision tree is not which provider. It is whether you want to operate the infrastructure or rent it.
| Factor | Managed API (SendGrid, Postmark, Mailgun, Resend) | SES in your AWS account |
|---|---|---|
| Setup time | 10–30 minutes: API key, DNS records, first send | 2–4 hours: IAM, SNS topics, bounce handlers, production access request |
| Cost at 10,000 emails/month | $0 (free tier) to $20/month | ~$1 SES + negligible Lambda/queue costs |
| Cost at 500,000 emails/month | $300–$500/month (varies by provider) | ~$55–$65 all in (SES + Lambda + queues) |
| Suppression list ownership | Export via API; vendor owns the canonical list | Your Postgres/DynamoDB table; you own it |
| Bounce & complaint events | Webhooks to your endpoint; vendor’s event format | SNS to your endpoint; raw SES events in your database |
| Warm-up required | Usually no; shared IPs are pre-warmed | No for shared IPs; 4–6 weeks for dedicated IPs |
| Production access approval | Instant | 24–48 hours; requires bounce handling plan |
| Infrastructure control | Read-only dashboard + API | Full IAM, CloudWatch, configuration sets |
| Switching cost | Rewrite send calls, reformat templates, migrate suppression list, change DNS | Swap credentials, change DNS; data/templates already yours |
The trade-off is not subtle. Managed APIs are faster to integrate and someone else is responsible when deliverability drops. SES is cheaper, you own the whole event pipeline, and the operational responsibility is yours.
If you are a team of two, pre-revenue, sending 5,000 emails a month, the managed API is almost always correct. If you are past product-market fit, sending 100,000+ emails a month, already on AWS, and comfortable with Lambda and SNS, SES is usually cheaper and more flexible within a few months.
Deliverability: the criteria that matter in practice
“Deliverability” is the percentage of sent emails that reach the inbox rather than spam, promotions, or nowhere. It is the metric that decides whether your transactional email API service is functional or decorative.
Deliverability is not one number. It is the outcome of sender reputation, authentication, list hygiene, content patterns, and recipient engagement. Providers market it as a feature — “99.9% inbox placement!” — but the number is not portable. Your deliverability with SendGrid is not your deliverability with Postmark, because the IP pools are different, the domain reputation is different, and the behavior of other senders in the shared pool is different.
Authentication: SPF, DKIM, DMARC
Every legitimate transactional email platform requires SPF, DKIM, and DMARC. These are DNS records that prove you authorized the send and that the message has not been tampered with.
SPF (Sender Policy Framework) lists the IP addresses or domains allowed to send mail on behalf of your domain. You publish a TXT record; mailbox providers check it.
DKIM (DomainKeys Identified Mail) signs the message with a private key and publishes the public key in DNS. The signature proves the message came from your domain and was not modified in transit.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells mailbox providers what to do if SPF or DKIM fails: quarantine, reject, or deliver anyway. It also tells them where to send failure reports.
Every provider sets these up the same way: you publish CNAME or TXT records they give you, they verify them, and sends are authenticated. This is table stakes. If a provider does not require DKIM, do not use it.
The detail that matters: DKIM signing domain. Some providers sign with their own domain (d=sendgrid.net) by default and require extra configuration to sign with yours. Signing with your domain builds your reputation. Signing with theirs does not. Make sure the provider signs with your domain, not theirs.
Shared IPs vs dedicated IPs
By default, most transactional email platforms send from shared IP pools — a group of addresses shared across many customers. The reputation of the pool is the average reputation of everyone in it. If another customer in your pool sends spam, the pool’s reputation drops, and your deliverability drops with it.
Shared IPs are cheaper (often included in base pricing) and require no warm-up, because the pool is already established. For low-volume senders (under 50,000 emails/month), shared IPs are usually fine — you do not have enough volume to build your own IP reputation anyway.
Dedicated IPs give you an address that only your account uses. Your reputation is isolated. The trade-offs: dedicated IPs cost $20–$30/month per IP, they require warm-up (4–6 weeks of gradually increasing send volume so mailbox providers learn to trust the new address), and they only help if you send enough volume to maintain the reputation. An IP that sends 500 emails a month has no reputation — mailbox providers do not trust it because there is not enough data.
The general guidance: shared IPs are fine under 50,000 emails/month. Dedicated IPs make sense above 100,000/month, or if your use case is unusually sensitive to reputation contamination (financial services, healthcare, anything where one spam incident is a regulatory event).
On SES, shared IPs are the default and cost nothing extra. Dedicated IPs are $24.95/month per IP and require the same warm-up. The setup is identical to managed APIs; the difference is that the IP is associated with your AWS account, not a vendor’s pool.
Bounce and complaint handling
Hard bounces (permanent delivery failures) and complaints (recipient clicked “report spam”) are the two signals that damage sender reputation the fastest. Every transactional email platform monitors them, and mailbox providers penalize senders who do not.
The non-negotiable minimum: stop sending to addresses that bounced or complained. This is not optional. If your bounce rate stays above 5% or your complaint rate stays above 0.1%, most providers will suspend your account and mailbox providers will start rejecting your mail.
Managed APIs handle this automatically for addresses in their system — once a bounce or complaint event fires, the address is suppressed across future sends. But if you are porting a list from another provider, or if you imported contacts from a CSV, those suppressions do not carry over. You must merge your suppression list from the old provider into the new one, or you will re-send to addresses that already bounced.
On SES, bounce and complaint handling is your responsibility. SES publishes events to an SNS topic you configure, you write a Lambda or an HTTPS endpoint to receive them, and you write the address to your suppression table. Before every send, check the suppression list. This is more work than a managed API’s automatic suppression, but it also means you own the suppression data — it lives in your database, not the vendor’s.
Practically: if you do not have time to build suppression logic, use a managed API. If you want to own the suppression list and the event data, use SES and write the handler. Resend vs Amazon SES compares the two models in detail.
List hygiene and engagement
Deliverability is not just about authentication and IP reputation. It is also about whether recipients want your email.
Mailbox providers track engagement: opens, clicks, replies, deletes, spam reports. If recipients consistently ignore or delete your transactional email, providers assume it is not wanted and start filtering it to spam or promotions — even if it is legitimately transactional.
The fix is not technical. Send only to people who expect the email. Do not send password resets to addresses that never signed up. Do not send receipts to addresses that never purchased. Do not import six-year-old lists and hope for the best.
The transactional email API platforms cannot fix this for you. They can monitor your bounce rate and complaint rate and suspend you if they spike, but they cannot make recipients want your mail. That is on you.
Warm-up and production access: sandbox vs instant sending
Managed APIs like Resend, Postmark, and Mailgun typically provide instant production access. You verify your domain, you get an API key, and you can send. There is no sandbox, no approval process, and no waiting period. This is one of their primary advantages for early-stage products — you can integrate and send on the same day.
Amazon SES is different. New AWS accounts start in the SES sandbox, which limits you to 200 emails per 24 hours and requires that every recipient address is pre-verified in the SES console. You cannot send to arbitrary addresses until you request and receive production access.
Requesting SES production access
Production access is not automatic. You submit a request through the AWS Support Center, and AWS reviews it, typically within 24 hours. The form asks:
- Use case description — what you are sending (password resets, receipts, notifications) and to whom (your users, your customers, event-triggered sends).
- Bounce and complaint handling — how you will process SES bounce and complaint notifications. AWS wants to know you have an SNS topic configured and a plan to suppress addresses.
- Email content and compliance — whether you are sending marketing or transactional email, and how you comply with CAN-SPAM, GDPR, or other regulations.
AWS rejects vague requests (“we will send emails to users”) and approves concrete ones (“we send password reset emails, email verification links, and order receipts to users who sign up via our web app; bounces and complaints are published to SNS topic arn:aws:sns:us-east-1:123456789012:ses-bounces and processed by Lambda function handle-bounces”).
If you have not yet built bounce handling, you can describe the plan: “We will configure SNS topics for bounces and complaints and write a Lambda function to add bounced addresses to a DynamoDB suppression table.” AWS accepts this.
The full guide to requesting production access, including what AWS actually wants to see and common rejection reasons, is here: AWS SES production access.
Once approved, your sending limits start at 50,000 emails per day and increase automatically as you send and maintain low bounce and complaint rates. You can also request manual limit increases if you need to send more immediately.
Warm-up for dedicated IPs
Whether you use a managed API or SES, dedicated IPs require warm-up. Mailbox providers do not trust new IPs. An address that suddenly sends 50,000 emails looks like spam, and providers throttle or block it.
Warm-up means starting with a small daily volume (500–1,000 emails) and doubling every few days until you reach your target volume. The process typically takes 4–6 weeks. During warm-up, deliverability is lower than it will be once the IP is established. This is expected.
Most managed APIs provide automated warm-up plans if you purchase a dedicated IP. SES does not automate it — you manage the ramp yourself, either by gradually increasing your send volume or by using a warm-up service.
If you are on shared IPs (the default for both managed APIs and SES), there is no warm-up. The pool is already established.
Cost at 10,000 emails per month and how it scales
Pricing structures for transactional email platforms fall into two categories: per-email (you pay for what you send) and monthly tiers (you pay a base fee for a send allowance, then overage fees beyond it).
Managed APIs: monthly tiers
Most managed transactional email platforms use monthly tiers with per-email overages.
Example tier structure (typical for providers like SendGrid, Postmark, Mailgun, Resend):
- Free tier: 0–3,000 emails/month (some providers; not universal)
- Starter tier: $10–$20/month for 10,000–50,000 emails
- Growth tier: $80–$160/month for 100,000–200,000 emails
- Scale tier: $300–$500/month for 500,000+ emails
Overages are typically $0.50–$1.00 per 1,000 emails above the tier limit. If you are on a 10k plan at $10/month and you send 15k, you pay $10 + (5 × $0.90) = $14.50 for that month. Next month, if you send 15k again, you pay $14.50 again — or you upgrade to the next tier and pay the higher base fee every month, whether you use it or not.
At 10,000 emails per month, most managed APIs cost $0–$20/month. At 500,000 emails per month, they cost $300–$500/month. Resend vs Amazon SES breaks down Resend’s published pricing at multiple volumes as a reference point.
SES: per-email, no tiers
Amazon SES is $0.10 per 1,000 emails, with no monthly minimum, no base fee, and no tiers. 10,000 emails is $1. 500,000 emails is $50. 2 million emails is $200. Genuinely linear.
There is a pricing note: in July 2026, AWS introduced SES pricing plans (Essentials, Pro, Enterprise). New accounts default to Essentials, which is $0.16 per 1,000 emails and includes Virtual Deliverability Manager features. The à-la-carte option at $0.10 per 1,000 still exists and is switchable at any time in the SES console. The tables in Resend vs Amazon SES use à-la-carte pricing for comparison.
SES is not free at low volume — there is no free tier. At 10k emails, you pay $1. Managed APIs with free tiers (like Resend at 3k/month free) are cheaper at very low volume. Past 50k, SES is cheaper.
The full AWS bill: SES + Lambda + queues + database
“SES costs $0.10 per thousand” is accurate but incomplete. If you are operating a transactional email API service on your own AWS account, you also pay for the Lambda functions that process sends and handle delivery events, the SQS queues that manage retries, the SNS topics that publish bounce and complaint notifications, and the database that stores your suppression list and send history.
The full bill at 500,000 emails per month:
- SES: $50 (at $0.10/1k)
- Lambda: ~$2–5 (mostly free tier at lower volumes; scales to ~$20 at 2M)
- SQS, SNS, EventBridge: ~$5 (queuing, notifications, scheduled tasks)
- Database: $0–$50/month (Neon free tier, serverless Postgres, or RDS from ~$15/month)
Total: ~$55–$65 per month at 500k emails, or ~$0.12 per thousand all in.
The database is the only line that costs money when you are not sending. Everything else scales to near-zero when idle. What it actually costs to send 500,000 emails from your own AWS breaks down every line item at 50k, 500k, and 2M volumes.
The comparison at 10,000 emails/month:
| Provider | Cost |
|---|---|
| Managed API (free tier) | $0 |
| Managed API (paid tier) | $10–$20 |
| SES + Lambda + queues | ~$1–$2 |
At this volume, the managed API free tier wins if you qualify. Past 100,000 emails/month, SES is 5–10× cheaper.
Lock-in: who owns the suppression list, events, and domain configuration
Pricing is visible before you commit. Lock-in is not — it shows up when you try to leave.
Suppression list ownership
The suppression list is the record of every address that hard-bounced, complained, or unsubscribed. It is how you avoid re-sending to addresses that rejected you. Losing it when you switch providers means re-learning which addresses are toxic, and re-learning happens by sending to them and watching your complaint rate spike.
Managed APIs: You can export the suppression list via API, CSV, or dashboard. The export works, but it has gaps. Addresses suppressed globally by the provider (flagged by their abuse desk, flagged across multiple customers, or suppressed for internal reputation reasons) typically do not export, because they were never “your” suppressions — they were the provider’s. When you leave, you take the addresses you explicitly bounced or complained, but not the ones the provider suppressed on your behalf.
SES: The suppression list is in your database. SES has an account-level suppression list (managed by AWS), but when you operate on SES, you also build your own list — because you are the one receiving the SNS bounce and complaint notifications and writing them to your Postgres or DynamoDB table. That table is yours. You wrote the Lambda that populates it. When you switch providers, the table stays where it is. No export, no migration, no gap.
This is the clearest example of the ownership difference. A managed API gives you an export. SES gives you a table in your infrastructure that was never anywhere else.
Delivery events and webhooks
Managed APIs send delivery events (bounces, complaints, opens, clicks) to your webhook endpoint in the provider’s event format. The webhook works, the data is useful, and switching providers means rewriting the webhook handler to parse a different JSON schema.
SES publishes events to an SNS topic you configure. You write the handler — a Lambda, an HTTPS endpoint, whatever — and you decide what to log, what to alert on, and what to store. The event format is SES’s format, but the handler is yours. Switching providers means swapping the upstream event source (SNS topic to a new provider’s webhook), not rewriting the entire handler.
The portability question: how much of your email system is in your codebase vs the provider’s API? Managed APIs abstract the event pipeline. SES makes you build it. The trade-off is that what you build is portable.
DNS and domain reputation
Every transactional email platform requires DNS records to verify your domain and configure DKIM/SPF. When you switch providers, you change the DNS records. Your domain reputation (the trust mailbox providers have in yourapp.com) moves with you. The IP reputation (the trust mailbox providers have in the sending IP address) does not, because the IP was never yours.
This applies to both managed APIs and SES. If you are on shared IPs (the default), switching providers means new IPs with no reputation. Your domain has history; the IPs do not. If you are on dedicated IPs, same story — the IP was rented, not owned.
The exception: if you operate SES on your own AWS account and you have been sending through a dedicated IP for years, you can theoretically keep the IP when you switch AWS accounts (via AWS support), but this is rare and not the default path. Practically, treat IP reputation as non-portable.
Domain reputation is portable. DKIM proves continuity. The new provider’s IPs warm from scratch, but your domain does not.
API surface and template portability
Every managed API has a proprietary send API. Switching providers means rewriting every resend.emails.send(), sendgrid.send(), or postmark.sendEmail() call. If your templates use provider-specific features (Resend’s React Email components, SendGrid’s dynamic templates, Mailgun’s template variables), switching means reformatting or rewriting them.
SES has two send methods: the AWS SDK (SendEmail, SendBulkEmail) and SMTP. SMTP is a standard; switching providers is a credential swap. The SDK is AWS-specific, but the logic is portable — you are passing a subject, a body, a recipient, and configuration. The method signatures change; the data model does not.
The question is not “which API is easier to use.” It is “how much of your integration is provider-specific code that will need to be rewritten if you leave.”
When to choose a managed API
Managed transactional email APIs (Resend, Postmark, Mailgun, SendGrid) make sense when setup time is more expensive than monthly cost, when your volume is low or unpredictable, or when you do not want to operate email infrastructure.
You are early-stage, pre-revenue, or sending under 50,000 emails per month. The free tiers are genuinely free and the paid tiers are $10–$20/month. The difference between $20 and $2 is not worth a day of setup time if you have six other things to build.
You do not have AWS experience and you do not want to develop it. SES is cheaper, but it requires IAM users, SNS topics, Lambda functions, and suppression logic. If nobody on your team has deployed anything to AWS before, managed APIs are the path of least resistance.
You need instant production access. Managed APIs do not have sandbox modes. You verify your domain, you send. SES requires production access approval, which takes 24–48 hours. If you are on a deadline, the managed API is faster.
You want someone else to monitor deliverability. Managed APIs watch your bounce and complaint rates, alert you when they spike, and sometimes intervene proactively (suspending sends, contacting you, suppressing problem addresses). On SES, monitoring is your CloudWatch dashboard and your alerting rules. If you want the operational responsibility outsourced, the managed API is the trade you are making.
Your sending volume is low and stable, and the cost difference does not matter. If you send 20,000 emails a month and that number has been stable for a year, the difference between $10/month and $2/month is $96/year. That is not enough to justify infrastructure work unless you have literally nothing else to do.
When to choose SES in your AWS account
SES makes sense when cost matters, when you want to own the infrastructure, when you are already operating on AWS, or when you expect volume to grow and the cost gap will compound.
Your volume is above 100,000 emails per month, or you expect it to be soon. The cost gap at 100k is $80–$160/month (managed API) vs $10–$12/month (SES). At 500k it is $300–$500 vs $55–$65. These gaps are large enough to pay for setup time and still come out ahead, and they recur every month.
You are already on AWS and SES is the logical next integration. If your application runs on Lambda, your database is RDS, your secrets are in Secrets Manager, and your logs are in CloudWatch, adding SES is less work than integrating a third-party API. IAM roles, VPC endpoints, and CloudFormation templates are things you already have.
You want to own the suppression list and the event pipeline. If deliverability matters enough that you want raw access to every bounce, every complaint, and every delivery event, SES gives you the firehose. SNS delivers events to your endpoint in real time, you log them to your database, and the data is yours. Managed APIs give you a webhook, which is enough for most use cases, but it is not the raw event — it is the provider’s interpretation of it.
You want to avoid a future migration. If you can see a future where you are sending 500,000+ emails a month and the cost gap will matter, it is often easier to start with SES than to build on a managed API and migrate later. Migrations are expensive: code changes, DNS changes, suppression list exports, template reformatting, webhook handler rewrites. All of that is work you do not have to do if you start with the infrastructure you will eventually need.
You have compliance, data residency, or audit requirements that care about who operates the infrastructure. Some regulated industries require that email data and logs stay in your AWS account, not a third-party vendor’s. If your AWS account is in scope for SOC 2, HIPAA, or enterprise security questionnaires, and adding a new vendor is not, SES is the option that does not require vendor review.
You want full control of costs and no risk of mid-contract repricing. Managed APIs are venture-backed SaaS products. At some point — a year, three years, whenever investors want a return — the free tier will shrink, the Scale tier will reprice, or Enterprise minimums will appear. This is not speculation; it is the standard lifecycle of venture-funded B2B SaaS. SES pricing is public, stable, and not subject to a startup’s funding timeline.
The question is not which provider is “best”
The comparison between managed transactional email APIs and SES is not about which one is better. It is about whether you want to operate infrastructure or pay someone else to do it.
Managed APIs are the version where you pay someone else. They cost more, they are faster to integrate, and your operational responsibility ends at the API boundary. When deliverability drops, you open a support ticket. When something breaks in the provider’s stack, the provider fixes it. You are not monitoring SNS topics, you are not writing bounce handlers, and you are not managing IAM policies.
SES is the version where you operate it yourself. It is cheaper, you own the whole stack, and the trade is that you also own every failure mode. When your send rate spikes and you hit a Lambda concurrency limit, you are the one watching CloudWatch and raising the quota. When your bounce rate climbs, you are the one who has to clean the suppression table.
The lock-in question is downstream of this. If you are happy outsourcing email infrastructure forever, lock-in does not matter — you were never planning to leave. If you think you might want to bring email in-house, or if you want the option to switch providers without a multi-month project, owning the infrastructure from the beginning is cheaper than migrating later.
At 10,000 emails per month, the cost difference is small enough that simplicity and speed matter more. Use a managed API if you want to ship fast, use SES if you are already on AWS and comfortable with Lambda.
At 500,000 emails per month, the math changes. Managed APIs cost $300–$500. SES costs $55–$65. The gap is large enough that “which is easier” stops being the question. The question becomes “is the simplicity worth $250–$450 per month, and will it still be worth that when I am at 2 million emails and the gap is $1,000/month?”
If you have the team, the time, and the AWS experience, SES is almost always the more economical long-term choice. If you do not, or if your volume is low and stable, a managed transactional email API service is a rational trade of money for operational simplicity.
Selva Mail runs on your AWS account and sends through your SES. It handles suppression, bounce processing, event webhooks, and the API — so you get SES pricing without building the infrastructure yourself. One-time license, $497. See what’s included.
