Technical Decision

Transactional email: Resend vs. Postmark vs. Amazon SES

Resend, Postmark, or Amazon SES for password resets and receipts: pricing, deliverability, SPF/DKIM/DMARC, inbound mail, logs, and lock-in.

By Lance King · · 10 min read

A smiling mail carrier juggles colorful envelopes above three different mailboxes, one of which has a little envelope peeking out.

This guide is for developers and founders choosing who will send their app’s password resets, sign-in links, receipts, and alerts. Transactional email is mail a user triggers by doing something, sent one at a time to one person. It has to arrive fast and land in the inbox, and nobody thinks about it until it doesn’t. The three providers most teams shortlist are Resend, Postmark, and Amazon SES. All three can deliver your mail. They differ in price, in how much deliverability work they do for you, and in how much plumbing you have to build yourself.

The short answer

  • Choose Resend if you want the quickest setup in a modern JavaScript or TypeScript stack, a clean API, and inbound mail on every plan.
  • Choose Postmark if inbox placement for critical mail matters most and you want strict separation between transactional and marketing traffic built in.
  • Choose Amazon SES if you send high volume, already run on AWS, and are willing to build your own logs, dashboards, and bounce handling.
  • Use more than one if the email is critical: a second provider configured and tested is cheap insurance.

What actually matters

1. Deliverability, meaning whether mail reaches the inbox. Providers send from IP addresses, and mailbox providers like Gmail judge those IPs by their history. A shared IP is used by many customers, so you inherit their reputation, good or bad. A dedicated IP is yours alone, so you own its reputation, but only helps if you send enough steady volume to build one. Just as important is keeping transactional mail separate from marketing mail, so a promotional campaign that draws spam complaints doesn’t drag down your password resets.

2. Price at your volume. All three charge mostly per email. The gap between them is real at a million emails a month and small at ten thousand.

3. Developer experience. How fast you go from signup to a delivered message, the quality of SDKs and docs, and whether you can write templates in a way your team likes.

4. Logs and webhooks. When a customer says “I never got the email,” you need to look up that message and see whether it was delivered, bounced, or marked as spam. Webhooks push those events to your app so you can stop mailing bad addresses.

5. Inbound email. Replies to notifications, support mailboxes, and “email this address to create a ticket” features all need a way to receive and parse mail.

6. Lock-in. How much of your code and templates depend on one vendor.

The authentication rules you must follow anyway

Whichever provider you choose, you’ll set up three DNS records for your sending domain. They prove mail really comes from you:

  • SPF (Sender Policy Framework) lists the servers allowed to send mail for your domain.
  • DKIM (DomainKeys Identified Mail) adds a cryptographic signature that receivers check against a public key in your DNS.
  • DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receivers what to do when SPF or DKIM fails, and sends you reports.

Since February 1, 2024, Google requires everyone sending to Gmail to use SPF or DKIM, have valid forward and reverse DNS, use TLS, and keep the spam rate reported in Postmaster Tools below 0.3%. Senders of roughly 5,000 or more messages a day to personal Gmail accounts must set up SPF, DKIM, and DMARC (a policy of p=none is enough), align the From domain with SPF or DKIM, and support one-click unsubscribe on marketing messages. Google counts all subdomains of a primary domain together toward the 5,000, and once you’re classified as a bulk sender, the status doesn’t expire.

Google also says that starting November 2025 it is “ramping up its enforcement on non-compliant traffic,” including temporary and permanent rejections. Yahoo’s requirements match closely: SPF and DKIM plus a DMARC policy of at least p=none for bulk senders, a spam rate under 0.3%, one-click unsubscribe for marketing mail, and unsubscribes honored within two days.

One relief for transactional mail: Google’s FAQ states that one-click unsubscribe “is required only for marketing and promotional messages. Transactional messages are excluded from this requirement.” Password resets and order confirmations don’t need an unsubscribe header. Authentication, though, applies to everything you send.

The options at a glance

Prices are from each vendor’s official pricing page, as of October 2026.

Resend Postmark Amazon SES
Free tier 3,000 emails/mo, 100/day 100 emails/mo (developer plan) No permanent free tier; new AWS accounts get up to $200 in Free Tier credits
Entry paid plan Pro $20/mo for 50,000 emails Basic $15/mo for 10,000 emails $0.10 per 1,000 emails, pay as you go
Overage $0.90 per 1,000 on Pro; down to $0.46 on larger Scale tiers $1.80 per 1,000 on Basic; $1.30 on Pro; $1.20 on Platform Same per-email rate
Dedicated IP $30/mo, Scale plan, over 3,000 emails/day From $50/mo per IP, Pro plan or higher, 300,000+ emails/mo $24.95/mo per standard IP; managed dedicated IPs also available
Transactional vs. marketing separation Separate marketing plans Message streams on separate IP pools Up to you (configuration sets, IP pools)
Inbound email All plans Pro and Platform plans $0.10 per 1,000 emails plus $0.09 per 1,000 256 KB chunks
Logs and events Dashboard plus webhooks (5 endpoints on Pro, 10 on Scale) Dashboard, 45-day default retention, event webhooks Build it from event publishing to SNS, CloudWatch, or Firehose

The options in more detail

Resend

Resend is built around developer experience: a REST API, official SDKs, SMTP relay, and a dashboard that’s easy to read. Its team also created React Email, an MIT-licensed library for writing emails as React components. React Email renders to plain HTML, so it works with Postmark, SES, and other providers too. That matters for lock-in, covered below.

As of October 2026, the free plan sends 3,000 emails a month with a 100-a-day cap and keeps data for 30 days. Pro is $20 a month for 50,000 emails or $35 for 100,000, with overage at $0.90 per 1,000. Scale starts at $90 a month for 100,000 emails, with overage rates down to $0.46 per 1,000 on larger tiers. Every plan includes inbound email, batch sending, and multi-region sending.

Resend sends from shared IPs by default. A managed dedicated IP is a $30-a-month add-on on Scale for customers sending over 3,000 emails a day, and Resend warms it up automatically. Resend’s own docs are candid that a dedicated IP isn’t a deliverability guarantee and can backfire at low volume (it gives under 90,000 a month as an example) or with uneven sending patterns.

Marketing email is a separate product with separate plans priced by contact count, so you can keep campaigns apart from your transactional sending.

Inbound works by pointing your domain’s MX records at Resend. It parses each message and posts it to your webhook, with temporary download URLs for attachments.

Postmark

Postmark focuses on transactional mail and is known for its deliverability practices. ActiveCampaign acquired it in May 2022, and it still runs as its own product.

Its central idea is message streams. Transactional mail and broadcast (bulk) mail go through separate streams, and Postmark says “transactional and broadcast traffic never intersect in Postmark, including IP ranges.” That’s the separation you’d otherwise have to build yourself. Postmark also manually vets new customers, and new accounts must request approval before sending broadcasts. That vetting is part of why its shared IPs have a good reputation, and it means signup takes a little longer.

As of October 2026, the free developer plan sends 100 emails a month. Paid plans at 10,000 emails a month are Basic at $15, Pro at $16.50, and Platform at $18, with overage of $1.80, $1.30, and $1.20 per 1,000 respectively. Postmark is the most expensive of the three per email, and the gap grows with volume. Default data retention is 45 days, with up to 365 days available as an add-on on Pro and Platform. Dedicated IPs start at $50 a month per IP and require the Pro plan or higher and at least 300,000 emails a month.

Inbound processing is on Pro and Platform only, not Basic. It turns incoming mail into JSON and posts it to your webhook, including base64-encoded attachments and spam-check headers. You can use a generated Postmark address or your own domain.

Amazon SES

SES is the cheapest by a wide margin and the most do-it-yourself. As of October 2026, pay-as-you-go sending costs $0.10 per 1,000 emails, with attachments at $0.12 per GB. AWS also now lists bundled plans: an Essentials plan with no monthly fee, and Pro ($105 per account per region per month) and Enterprise ($500) plans that add things like managed dedicated IPs, deliverability monitoring, and email add-ons. Their per-email rates are higher than pay-as-you-go, so read the plan details carefully.

New SES accounts start in a sandbox: you can only send to verified addresses, up to 200 messages per 24 hours and one per second. You request production access through the console, and AWS says it gives an initial response within 24 hours. Sandbox status is per AWS region.

SES gives you the raw parts. The console shows account-level sending stats and reputation, but there’s no per-message search out of the box. To see what happened to an individual email, you set up event publishing to SNS, CloudWatch, or Firehose and store the events yourself. Separating transactional from marketing traffic is also your job, using configuration sets and IP pools. Standard dedicated IPs cost $24.95 a month each.

Inbound email uses receipt rules that can store messages in S3, publish to SNS, or bounce them, at $0.10 per 1,000 emails plus $0.09 per 1,000 incoming 256 KB chunks. Receiving is only available in some AWS regions.

If you’re comfortable with AWS, SES at scale is hard to beat on price. If you’re not, the time spent building logs and bounce handling can cost more than the savings.

Which one for you

Prices in this section are as of October 2026.

Solo founder or small app. Resend’s free tier or $20 Pro plan covers most early products, and setup is quick. Postmark is a fine choice too if you’d rather pay a little more for its transactional focus.

Growing startup with marketing email too. Keep transactional and marketing traffic on separate streams, or separate providers. Postmark’s message streams do it for you; with Resend, use its separate marketing product or a separate subdomain; with SES, set up separate configuration sets and IP pools.

High-volume sender. At millions of emails a month, SES’s price wins. Budget engineering time for event storage, a bounce and complaint pipeline, and dashboards. See build vs. buy for how to weigh that.

Regulated company. Check each provider’s compliance documents and data-processing terms directly; this guide doesn’t cover them. SES inherits your existing AWS agreements, which can simplify procurement if you already have them.

Mistakes to avoid

  • Sending marketing and password resets from the same stream and domain. One bad campaign can push your critical mail into spam. Use separate streams, and consider a separate subdomain for marketing.
  • Buying a dedicated IP too early. With low or bursty volume, a dedicated IP can hurt deliverability. Shared pools from a well-run provider are usually better until you send steadily at scale.
  • Skipping DMARC. Start at p=none, read the reports, then tighten the policy once you know every service sending as your domain.
  • Ignoring bounces and complaints. Process webhook events and stop mailing addresses that bounce or complain. Providers can suspend accounts with high rates.
  • Forgetting the SES sandbox. Request production access well before launch day.

Lock-in and migration

Email lock-in is lighter than most infrastructure. Sending is a simple API call, and all three support SMTP, so you can wrap sending in a small interface in your code and swap providers behind it. The sticky parts are templates stored in a vendor’s dashboard, webhook formats your code depends on, and inbound addresses customers have saved. Keep templates in your repo (React Email or any HTML templating works with all three), normalize webhook events into your own format, and receive inbound mail on your own domain rather than a vendor address. Record the choice in a technical decision record so the next person knows why.

A quick checklist

  • Have you set up SPF, DKIM, and DMARC on your sending domain?
  • Are transactional and marketing mail on separate streams or subdomains?
  • What will you pay at 12 months’ projected volume?
  • Can you look up a single message’s delivery status when a customer asks?
  • Does your app process bounce and complaint webhooks?
  • Do you need inbound email, and is it on the plan you’re buying?
  • Are your templates in your own repo?
  • If you chose SES, have you requested production access?

Sources