Resend vs. Amazon SES vs. SendGrid vs. Postmark: How to Actually Choose an Email Provider (August 2026)

Every email-provider comparison ends with a table of "dollars per 1,000 emails". That table does not work as an estimate, because it silently assumes implementation effort costs zero. The deliverability dashboard, the suppression-list sync, the unsubscribe flow, the bounce-handling wiring — none of these exist unless someone builds them, and none of them appear anywhere in a unit-price table.

This article is a selection guide built on a different question: not "which is cheapest" but "which job do you not want to own". I compare Resend, Amazon SES, SendGrid and Postmark using only numbers taken from their official pricing pages on 6 August 2026, then work through total cost of ownership, a decision flow, and a migration runbook.

I run this portfolio site itself on Resend in production — the contact form, the lead-magnet delivery, a seven-email course, and the fulfilment email after a Stripe payment. I have also put the domain authentication records on the apex by mistake and left /api/contact returning 502 until I found it. So this is not a Resend advertisement. I give the cases where you should not pick it the same amount of space.

On the date these numbers were taken: every price and limit below was confirmed on the vendors' official pricing pages on 6 August 2026. Pricing changes often, so verify current values on each official page before you commit to an estimate. All amounts are in USD (Resend's pricing page has no currency selector).

First, update your facts to August 2026

Email delivery is no longer a field where you learn something once and coast for five years. At least four commonly quoted facts now contradict the official pages.

There is one more, very recent change on the SES side. A footnote on the pricing page reads: "New SES accounts and account x region combinations with no metered SES activity since June 1, 2025 will start on the Essentials plan beginning July 21, 2026." In other words, the billing assumptions for a dormant SES account you created long ago may have changed last month.

Break the decision into six axes

Collapsing the comparison into a single "cheap vs. expensive" axis guarantees a bad decision. I evaluate on six. The more of these axes you do not want to own in-house, the closer the higher-unit-price managed service is to being correct.

Axis 4 is one sixth of the decision. The reason most comparison articles only cover axis 4 is that axis 4 is the only one that is easy to source publicly. This article quotes official prices too, but make the decision on axes 1, 3, 5 and 6.

Where each service stands (retrieved 2026-08-06)

Resend

Volume-based transactional plans and contact-based marketing plans are billed separately. Here is the full transactional ladder.

The official caveats matter as written: "The overage rate applies only to emails sent beyond the included volume" and "The Free plan is limited to 100 emails per day."

Two things in this table get missed. First, at 100,000 emails/month Pro is $35 and Scale is $90. The Scale premium buys Slack support, 1,000 domains, 500 AI credits and dedicated-IP eligibility — not more email. Second, the effective rate (my arithmetic: price divided by included volume) is $0.40 per 1,000 on Pro $20 and $0.35 per 1,000 on Pro $35, both cheaper than Scale's $0.90 per 1,000.

Key per-plan limits from the official comparison table:

For what every plan includes, read the rows of the official comparison table that are checked on all four columns: RESTful API, SMTP relay, official SDKs, inbound emails, scheduled sends, batch sending, open and link tracking, React Email, multi-region, DKIM/SPF/DMARC authentication, webhooks (all events), SOC 2 Type II certification, GDPR compliance, MFA, and API key permissions. Add to that the automatic suppression list, bounce details, deliverability insights, and 10,000 automation runs per month — all on every plan.

Pay-as-you-go overage is an opt-in available to paid subscriptions, enabled under team settings as "Transactional Overages". What matters is that the runaway-spend stop is documented: "To prevent extreme overages and unexpected costs, a hard limit of 5x your monthly quota applies… Once you reach this limit, sending will be paused until the next billing cycle."

Other numbers that move the decision:

• Dedicated IPs: $30/month, gated on "the Scale plan" plus more than 3,000 emails sent per day. (The knowledge base words the requirement as "an active Transactional Scale or Marketing Pro subscription" while the pricing card says "on the Scale plan" — check both.) The pool is managed only, and Resend explicitly does not expose the list of IPs in your dedicated pool.
• Rate limit: 10 req/s, per team, no burst allowance. A batch request counts as one request against the limit while carrying up to 100 emails, so batching is the legitimate throughput lever.
• Account-pause thresholds: bounce rate under 4%, spam rate under 0.08%. Exceeding either "may result in a temporary pause in sending".
• Annual billing: the pricing FAQ says "we only provide monthly plans"; the knowledge base says annual subscriptions are available for Enterprise. The accurate synthesis is self-serve is monthly-only, annual is Enterprise-only via sales. No non-profit or education pricing; all major credit cards.
• Vercel Marketplace: the native integration shipped on 1 July 2026, provisioned with vc i resend. Billing lands on a Vercel-issued invoice (Vercel handles taxation), and the sending region can be passed as metadata, for example -m region=ap-northeast-1.

Amazon SES

Three plans plus an à la carte (metered-only) option.

À la carte is $0.10 per 1,000 outbound emails (plus $0.12 per GB of attachment data) and $0.10 per 1,000 inbound (plus $0.09 per 1,000 incoming chunks). On unit price alone it is an order of magnitude below the other three.

AWS publishes its own worked examples. Essentials with 250,000 emails at 32KB: $40.00 plus $0.96 of data equals $40.96/month. Pro with 2,000,000 emails: $440.00 plus $7.68 of data plus the $105.00 fixed charge equals $552.68/month. À la carte with 2,000,000 emails: $200.00/month.

SendGrid (Twilio)

Converted to per-1,000 (my arithmetic), the overages are $1.30, $0.90, $1.10 and $0.50. Effective entry rates are $0.399 per 1,000 on Essentials and $0.90 per 1,000 on Pro.

The one teammate on Essentials is easy to miss and goes straight to organisational requirements: if more than one person needs the dashboard, you are on Pro at $89.95 and up. Note also that SendGrid's data retention is not stated on the pricing page and I could not confirm it. Do not compare a remembered retention figure against Resend's documented 30 days.

Postmark

The figures below are what the pricing page shows with the slider at 10,000 emails/month.

Effective rates at 10,000 emails (my arithmetic) are $1.50 per 1,000 on Basic, $1.65 on Pro and $1.80 on Platform — the most expensive of the four. What Postmark sells in exchange is retention: "45 days worth of full content history by default to help you troubleshoot (customizable from 7 to 365 days if needed)."

Add-ons: dedicated IPs start at $50/month per IP (300,000 emails per month or more, Pro plans or higher), custom activity retention starts at $5/month, DMARC monitoring starts at $14/month per domain. The FAQ states there is no tier between the 100-emails/month free developer plan and 10,000 emails/month, that annual plans are not offered, and that bootstrapped companies charging for a launched product can get a $75 account credit. The free plan is 100 emails per month, not per day, and it does not expire.

Postmark's pricing above 10,000 emails/month was not embedded in the page HTML and I could not confirm it. If you are evaluating Postmark at volume, read the slider on the official page directly.

The same volumes, side by side

Putting the above together at three representative volumes. Cells marked "not confirmed" are ones I could not verify on an official page.

SES being an order of magnitude cheaper is a fact. How you read that gap is the actual subject of this article.

Total cost of ownership: count the line items that are not on the price list

At 100,000 emails/month, SES Essentials at $16 and Resend Pro at $35 differ by $19 a month. Set that against the engineering time to build even one of the operational features below and then keep maintaining it, and it disappears. So the real decision is: how much work can you outsource for $19?

The useful test is whether the same capability appears as a separately priced line item on the other vendor. SES's pricing page is admirably honest here.

This is not an argument that SES is expensive. It is a structural difference: SES sells components, Resend sells the assembly. And a component's price never includes the person who assembles it.

When you build the estimate, count at minimum these five things you will end up building yourself:

1. Suppression-list integration — receiving permanent bounces and complaints, and reliably consulting them before the next send. In Resend, suppressions apply to the entire team and are skipped across all domains and subdomains automatically. Reproducing that guarantee yourself means designing the pre-send lookup and its race conditions.
2. Template management — who edits copy, where, and when it reaches production. The design for React Email is in the templates and variables guide.
3. Subscription management and unsubscribe — RFC 8058 one-click unsubscribe, per-topic opt-out, and where the source of truth for opt-out state lives. Covered in the batch, scheduled and subscription-management guide.
4. Dashboard and search — a screen where a non-engineer can answer "did it reach that person?" themselves. Without it, every such question becomes an engineering ticket.
5. Bounce and complaint event wiring — signature verification, no ordering guarantee, and resistance to duplicate delivery. That is the webhooks, signature verification and bounce-handling guide.

A comparison table that assumes those five already exist is not a comparison. Conversely, if you already have an email-platform team running all five, the SES unit-price gap converts straight into savings. That is a correct decision too.

Decision flow

Translating the six axes into the order you actually work through them:

[start] What kind of mail are you sending?
   |
   +-- Mostly transactional (signup confirmation, password reset, notifications, receipts)
   |      |
   |      +-- Q1: Is data residency, IP allowlisting, or annual invoiced billing a HARD requirement?
   |      |      YES -> Resend likely cannot satisfy it
   |      |             - account data and logs are stored in the US regardless of sending region
   |      |             - dedicated IPs are managed pools; the IP list is never disclosed
   |      |             - self-serve is monthly only (annual is Enterprise, via sales)
   |      |             -> consider SES inside your own AWS account, or an Enterprise contract
   |      |      NO  -> go to Q2
   |      |
   |      +-- Q2: Do you already have a team that operates email infrastructure?
   |      |      YES -> SES (a la carte, $0.10 per 1,000). The unit-price gap is maximised
   |      |      NO  -> go to Q3
   |      |
   |      +-- Q3: How long must logs be retained?
   |      |      More than 45 days -> Postmark (45-day default, customizable 7 to 365 days)
   |      |      30 days is enough -> go to Q4
   |      |
   |      +-- Q4: Is your stack Next.js / TypeScript?
   |             YES -> Resend (React Email, typed SDK, native on the Vercel Marketplace)
   |             NO  -> compare Resend / SendGrid / Postmark on axis 3 (operational features)
   |
   +-- Mostly marketing (newsletters, campaigns)
          |
          +-- Q5: Do you need delivery, or scenario automation?
                 Delivery -> Resend marketing plans (billed on contacts, no cap on
                             emails sent. Free covers 1,000 contacts;
                             Pro marketing runs $40 / 5,000 up to $650 / 150,000)
                 Advanced automation -> Resend Automations appear on the pricing page as a
                             usage-billed feature (10,000 runs/month included on all plans,
                             then $0.0015 per run), but I did not verify how expressive the
                             scenario builder is. Read the official documentation on
                             feature scope before deciding

Q1 comes first on purpose. Organisational requirements cannot be worked around later. You can renegotiate unit price and developer experience; you cannot renegotiate which country your logs are stored in.

When to choose Resend, and when not to

Choose it when

• Next.js and TypeScript are your home turf. Writing templates in React Email and branching on { data, error } from a typed SDK is the lowest-friction path of the four. Implementation is in the Next.js App Router guide.
• You need to be in production today. The docs state there is no production approval, no sandbox mode and no waiting period, and that free accounts have full production access immediately. Not waiting on an approval queue matters a lot when a launch date is fixed.
• You want deliverability work to come standard. DKIM/SPF/DMARC, automatic suppression, bounce details, deliverability insights, pristine shared IPs and multi-region are on every plan. Setup is in the domain authentication and deliverability guide.
• You are in the 50,000–100,000 emails/month range. Pro $20 (effective $0.40 per 1,000) and Pro $35 (effective $0.35 per 1,000) are essentially level with SendGrid Essentials at $0.399 per 1,000, while adding 10 domains, no daily cap and pay-as-you-go overage.
• You run on Vercel. The native Marketplace integration consolidates billing onto the Vercel invoice (Vercel handles taxation) and injects the API key as an environment variable.

Do not choose it when

• You must retain logs for more than 30 days. Resend's data retention is a fixed 30 days on Free, Pro and Scale; only Enterprise is Flexible. If someone can ask for the body of an email sent six months ago, Postmark — 45 days by default, configurable up to 365 — is the honest fit.
• IP allowlisting is a requirement. Resend's dedicated IPs are managed pools, and the docs state that because the pools are dynamically scaled, "we do not expose the list of IPs" in your dedicated pool. That is structurally incompatible with a recipient-side IP allowlist.
• Data residency is a requirement. You can pick Tokyo (ap-northeast-1) as a sending region, but the docs say region selection "controls where your emails are routed and sent from. It does not control where customer data is stored", and that all account data, email metadata, logs and API records are stored in the United States regardless.
• You want multiple domains on the free plan. Free allows one custom domain. Because each subdomain is added and verified as its own domain object, splitting updates.example.com (marketing) from account.example.com (transactional) is not possible on the free plan. (That is an inference from two documented facts, not a single stated sentence.)
• You need annual contracts, invoiced billing or non-profit discounts. The pricing FAQ states self-serve is monthly only, payment is by major credit cards, and all plans are priced the same for every customer with no non-profit or education pricing.
• You are hoping a dedicated IP will fix deliverability at low-to-mid volume. Resend itself lists the cases where dedicated IPs do not help: sending less than 90,000 emails a month may not keep the IPs warm; sudden changes in volume hurt IP reputation; and a new sender has no sending history. A dedicated IP is not a silver bullet.
• You want to compare on seat counts. Resend documents neither a per-plan seat limit nor a per-seat price anywhere. You cannot put it on the same axis as SendGrid (1 teammate on Essentials, 1,000 on Pro) or Postmark (up to 4 users on Basic, unlimited on Platform).

Migration: four steps that do not take you offline

When you decide to switch, the accident happens at the moment of cutover. This is the order I use.

Step 1: run domain authentication in parallel

This is the best news in the whole migration. Resend's SPF records (an MX and a TXT) go on send.example.com, and DKIM goes on resend._domainkey.example.com. As the docs state, "MX records only impact the subdomain they are associated to", so they do not collide with your existing apex MX or SPF. You can validate Resend while the old provider stays fully live.

DMARC is the one exception — there is only one record, at _dmarc. During the migration, set p=none with a rua address, collect reports, and confirm that both the old provider and Resend are passing either SPF or DKIM before you move to p=quarantine. DMARC compliance requires passing SPF or DKIM, not both; a message only fails when both fail.

The outage I mentioned earlier was exactly this. I put all four records — SPF MX, SPF TXT, DKIM and DMARC — on the apex, domain verification never completed, and /api/contact kept returning 502. Resend's own troubleshooting page lists "verify that the records are added at the correct location (the send subdomain, not the root domain)" as its own numbered step. The full setup is in the domain authentication and deliverability guide.

Step 2: cut over a small slice first

Do not move all sending at once. The reason is the same one Resend gives in the dedicated-IP docs: "sudden changes in email volume can hurt your IP reputation." In practice, migrate in this order:

1. Internal notifications (failure does not touch customers)
2. Low-frequency transactional mail (receipts, monthly reports)
3. High-frequency transactional mail (signup confirmation, password reset)
4. Marketing sends

This ordering is my own operational judgement, not an official recommendation. The rationale is smallest blast radius first, so that you detect anomalies before hitting Resend's thresholds (bounce rate under 4%, spam rate under 0.08%).

Step 3: receive webhooks from both providers

Take delivery events (sent, delivered, bounced, complained) from both the old provider and Resend, and normalise them into one table in your own database. The non-negotiable detail is a composite unique constraint on (provider, provider_event_id). The two providers' event IDs live in different namespaces, so omitting provider will collide.

There is one more mine that every migration steps on, so here it is up front. Idempotency keys do not span providers. Resend's Idempotency-Key is only meaningful inside Resend (retained for 24 hours) and is never reconciled against the same message sent through the old provider. The only thing that can prevent double sends during a migration is your own send ledger. Lock on "which event, which provider, sent when" in your database before you call either API. The idempotency and retry design is in the idempotency, retry and error-handling guide, and the same two-layer pattern on the payments side is in the Stripe webhooks and idempotency guide. I designed that two-layer idempotency on a payment platform and it has kept production double charges at zero.

Step 4: build the rollback path before you need it

A migration you cannot reverse is not a migration. At minimum, prepare three things:

• Keep every send call behind one module, so switching providers is one environment variable.
• Have a sender-address fallback. After my outage I implemented a retry path that switches the sender to a different verified domain when a send fails.
• Do not delete the domain when you roll back. If you remove a domain that has a configured tracking subdomain, Resend's provisioned proxy is removed too, which breaks links inside emails you have already sent. On top of that, "a domain can only be active on one Resend team at a time", so moving between teams requires delete-then-reverify — and the docs tell you to "plan for potential sending interruptions during the DNS propagation window".

Pre-migration checklist

The items I check before putting a new email provider into production.

• Evaluated candidates on all six axes and can state a reason that is not axis 4
• Recorded prices in the estimate with the date they were retrieved (the numbers here are from 2026-08-06)
• Confirmed the data-retention requirement (Resend 30 days; Postmark 45-day default, up to 365)
• Confirmed the data-residency requirement (Resend stores account data and logs in the US)
• Confirmed the seat-count requirement (Resend does not document one; SendGrid Essentials is 1 teammate)
• Confirmed overage behaviour (Resend hard-stops at 5x the monthly quota, and it is opt-in)
• Designed for the rate limit (Resend is 10 req/s per team; a batch counts as one request). Application-side throttling is covered in the serverless rate-limiting guide
• Placed SPF/DKIM on the subdomain and verified no collision with existing apex records
• Started DMARC at p=none with rua and confirmed both old and new senders pass
• Receiving webhooks from both providers, keyed uniquely on (provider, provider_event_id)
• Keeping a send ledger in your own database so idempotency spans providers
• Wrote down and shared the rollback procedure (one environment variable; never delete the domain)

Conclusion: what will you outsource for $19?

The conclusion of this article is not written anywhere in the comparison tables.

• Choose SES on unit price. À la carte at $0.10 per 1,000 is an order of magnitude below the other three. But that price exists because deliverability visibility, archiving, address validation and multi-tenant separation are all separately priced components. Someone pays for the assembly.
• Choose Postmark on retention. "45 days by default, customizable from 7 to 365 days" is a single sentence that easily justifies the unit-price gap in an audited business.
• Choose Resend on developer experience and time-to-production. No approval, no sandbox, deliverability tooling on every plan, and the shortest distance to Next.js. Just say the three constraints out loud during selection: 30-day logs, undisclosed IPs, data stored in the US.
• Choose SendGrid on seats and marketing features. Confirm two things with sales first: Essentials is one teammate, and data retention is not stated on the pricing page.

And once more, the thing that matters most. Choosing an email provider is not a price comparison; it is deciding who you outsource the jobs you do not want to own to. If $19 buys you out of maintaining a suppression-list sync, it is cheap. If you already have a dedicated team, $19 is waste. Only your organisation can tell which is true.

For implementation detail on each topic, start from the Resend production guide, the pillar of this cluster.

This article is based on the Resend documentation, Resend Pricing, Amazon SES Pricing, Twilio SendGrid Email API Pricing and Postmark Pricing, all as of 6 August 2026, restructured with operational judgement added. Effective rates labelled "my arithmetic" are computed from official prices and included volumes; they are not figures the vendors publish. Prices, limits and feature sets change frequently, so verify current values on each official page when you make the decision.