# Postmark vs Resend Source: https://wraps.dev/versus/postmark-vs-resend Postmark sells inbox placement and a decade of operating its own mail infrastructure. Resend sells the twenty minutes between an empty project and a sent email. Which of those you are short of decides this. Both of these are transactional email APIs aimed at developers, both are genuinely good at it, and that is exactly why the choice is hard. The difference is not quality, it is what each company treats as its product. Postmark has spent a decade building a mail operation and sells inbox placement. Resend sells the twenty minutes between an empty project and a first sent email. If you already know which of those two you are short of, you already know the answer. ## At a glance |   | Postmark | Resend | | --- | --- | --- | | What it is | Transactional email API, deliverability-first | Developer-first email API built on SES | | Published pricing | Basic $15, Pro $16.50, Platform $18 per month — each including 10,000 emails. Overage runs $1.80, $1.30, and $1.20 per 1,000 respectively. Dedicated IP $50/mo on Pro and above, 300K/mo minimum. | Free 3,000/mo (100/day). Pro $20 at 50K and $35 at 100K. Scale starts at $90 for the same 100K and runs to $350 at 500K. Overage $0.65–0.90 per 1,000. Marketing contacts billed separately at $40/mo per 5,000. | | Best for | Transactional email where inbox placement matters more than unit price. | The fastest path from an empty project to a sent email, especially with React Email. | | Watch out for | The economics invert at volume — roughly $630 at 500K/mo against $50 of raw SES. Marketing tooling is deliberately thin, and the early-2026 repricing means long-standing accounts are not on these numbers. | Logs are purged at 30 days on every non-Enterprise plan, the API is capped at 2 requests per second on all tiers, and suspension during traffic spikes is the complaint that recurs in its public reviews. | Prices are each vendor's published list prices, verified August 2026. Check the vendor's own page before you sign anything. ## Where they actually differ ### What each company actually operates Postmark Postmark runs its own sending infrastructure and treats deliverability as the product rather than a feature of it. Transactional and broadcast traffic are split into separate message streams by the product itself, not left to you to remember, so a newsletter cannot quietly poison the reputation your password resets depend on. That separation is the most consequential design decision in the product. Resend Resend is a developer experience layered over Amazon SES. That is not a criticism: the deliverability floor underneath you is AWS's, which is a high floor, and it frees Resend to spend its engineering on the parts you touch. It does mean the thing you are buying is the API, the dashboard and React Email, rather than a mail operation the company runs itself. ### How the bill behaves as you grow Postmark Postmark bills a monthly plan with a fixed allowance of emails included and a per-thousand rate beyond it. Its tiers differ by capability rather than by volume, so moving up does not buy headroom, it buys dedicated IPs and retention. The curve is smooth and easy to forecast, and it is the steeper of the two once you pass a few hundred thousand messages a month. Resend Resend splits into two ladders, Pro and Scale, and identical volume costs materially different amounts depending which one you sit on. Marketing contacts are a separate line from sending, so a list that grows raises the invoice in a month you sent nothing to it. Overage now bills automatically, the hard caps that used to stop it having been removed in December 2025. ### The ceiling you hit first Postmark With Postmark it is almost never throughput. It is the dedicated IP threshold: isolation is gated behind the higher plans and carries a monthly volume minimum, so a small team with a reputation problem has nothing to buy its way out with. The second ceiling is scope. If what you actually needed was a campaign builder, Postmark does not have one and is not building one. Resend With Resend it is two requests per second, on every plan including the most expensive. That is ample for signup and password-reset traffic and useless for a batch job that wants to push ten thousand messages in a minute. You queue and drip instead, which is ordinary engineering, but it is work nobody budgets for and upgrading does not remove it. ### What happens to your event history Postmark Postmark's activity view is the feature its customers cite second after deliverability: full message content, the delivery path and the bounce reason, searchable without exporting anything first. The window is finite, as everyone's is, but the tooling inside it is unusually good. Answering did you get my email takes one search rather than a log pipeline someone has to build. Resend Resend purges logs at thirty days on every plan short of Enterprise. The scenario that breaks is concrete rather than academic: a customer disputes a notice you sent in March and you are looking in June. Nothing went wrong, the window simply closed. Streaming events into your own store from day one fixes it, and almost nobody does that until after the first time it bites. ### Templates, and who is allowed to edit them Postmark Postmark ships a template system with layouts, versioning inside the product and a small set of well-made starters. It is aimed at engineers and testable before you send. A non-engineer can change copy in it, but nobody would mistake it for a design tool, and the boundary is deliberate rather than an omission. Resend Resend's answer is React Email, an open-source library it maintains. Templates are components, they live in your repository, and a change goes through code review like anything else. For an engineering team that is a better model than any hosted editor. For a team whose marketer wants to reword a headline without opening a pull request, it is a worse one. ### Getting your traffic out again Postmark Postmark's API is its own, so leaving is a code change at every send site plus re-verifying your domains. The expensive parts are the ones nobody counts up front: the suppression list, the message streams you configured, and every webhook consumer written against their event shapes. Resend Resend sits on SES, which tempts people into thinking the account travels with them. It does not, because the account is Resend's. Leaving still means re-verifying domains elsewhere and rebuilding reputation that accrued to their IPs. The SDK surface is small enough that the code change really is cheaper than most, but the infrastructure underneath is no more portable than anyone else's. ### What it looks like when sending stops Postmark Postmark's support reputation is the quiet reason long-tenured customers stay put. When it does go wrong, what people report is a policy conversation about content, initiated by a human who explains the problem, rather than an unexplained stop discovered from a drop in signups. Resend Resend's recurring complaint in public reviews is suspension during a traffic spike, and it lands on precisely the mail you least want to lose: signups, password resets, receipts. It is not universal and it is not malice, it is a young platform on shared reputation being conservative. It is still the risk you are accepting. ## Pros and cons, side by side ### Postmark Strengths - A decade of operating its own mail network, with inbox placement treated as the thing being sold rather than as a property inherited from whatever runs underneath. - Bulk and transactional traffic travel on separate streams by construction, so a newsletter cannot quietly spend the standing that your password resets depend on. - The activity view holds the rendered message, so somebody in support answers did this arrive from a search box today, without a log pipeline needing to exist first. - Throughput is not a constraint anyone meets here, which removes an entire category of architectural decision from the project before it is made. Trade-offs - Address isolation is gated behind the higher plans with a monthly volume minimum attached, so a small team with a reputation problem has nothing available to buy its way out of it. - There is no campaign builder and the company has spent a decade declining to build one, which makes lifecycle marketing a second product and a second record of consent. - The template editor is aimed squarely at engineers. Somebody in marketing can change a line of copy in it and nobody would mistake it for a design tool. - The curve steepens past a few hundred thousand messages a month, and an account opened years ago is not sitting on the figures a new one gets quoted. ### Resend Strengths - React Email is first-party and actively maintained, so templates are components under code review in your repository rather than rows in a vendor's database. - Domain verification and a working integration complete in roughly the time DNS takes, and the delivery floor underneath is AWS's, which is a high floor to inherit for free. - A permanent free allowance exists, which is what makes a staging environment or a weekend project something that does not generate an invoice. - The product surface is small enough that nobody spends their first hour picking between four supported ways to accomplish one task. Trade-offs - Logs are purged at thirty days on every plan short of Enterprise, and the scenario that breaks is concrete: a customer disputes a notice from March and you are looking in June. - Two requests per second on every tier, unmoved by any upgrade, so a batch job becomes a drip you build, operate and never get to delete. - Suspension during a traffic spike is the complaint that recurs across its public reviews, and it lands on exactly the mail you least want to lose. - The account and the standing behind it belong to the vendor, so leaving means verifying elsewhere and earning reputation again from nothing. ## Pick in thirty seconds ### Choose Postmark if - Deliverability is the reason you are shopping rather than a tiebreaker at the end. Nothing else in this pair has a comparable record at inbox placement. - You send both transactional and broadcast mail and want the reputation separation enforced by the product rather than remembered by your team. - Support needs to answer whether a specific email arrived from a search box, today, without anyone building a log pipeline first. - Your volume sits in the tens of thousands a month, where the included allowance is competitive and the curve has not steepened yet. ### Choose Resend if - You write the templates yourself and want them to be React components in your repository, reviewed like the rest of your code. - Time to first sent email is the metric that matters — a new project, a prototype, a launch next week. - Traffic is steady request-response mail well under two per second and nothing in your system sends in batches. - You already intend to stream delivery events into your own warehouse, so the thirty-day window is a non-issue rather than a trap. ## What actually moves when you switch In roughly the order you would do it. The expensive parts of an email migration are never the send call. 1. Pick the direction on the constraint rather than on the price, because the two moves are not symmetrical. Going one way buys enforced stream separation and a stored message archive; going the other buys React Email and a free allowance and costs you retention. Only one of those is cheap to reverse once the identity has warmed. 2. Export the suppression record from every stream and every audience rather than from the main one. Postmark scopes suppressions per message stream and Resend keeps its own bounce and complaint record, so a single export in either direction is partial — and the addresses it omits are precisely the ones that must not be mailed. 3. Take the message archive with you if you are leaving the side that keeps one. Postmark stores rendered bodies and the other does not, so the activity view a support agent relied on stops existing on the morning of the cutover. Teams generally learn this during the dispute that needed it. 4. Rebuild the templates instead of converting them. Layouts and substitution syntax are evaluated on the vendor's side; components are evaluated on yours. In either direction the HTML travels and the logic does not, and rendering inside your own application is what makes the move after this one a code change. 5. Map the streams onto whatever the destination actually has, and be honest that it is less. The transactional and broadcast split is enforced on one side; on the other it is a convention you maintain with separate domains, which works exactly as reliably as somebody remembering to maintain it. 6. Test the traffic shape against a two-per-second ceiling before committing in that direction. There is no comparable limit on the other side, so a nightly batch that is unremarkable today becomes a queue you build and then own, and no plan removes it afterwards. 7. Re-point the webhooks and re-derive everything downstream. Both providers post signed payloads to a URL you nominate, and that surface resemblance is misleading: event names, bounce subtypes and payload shapes differ enough that a dashboard built against one produces wrong numbers when fed the other. 8. Ramp across subdomains rather than switching in an evening. Whichever direction you travel, you arrive as an identity with no history, and the placement you were enjoying was a property of the vendor's operation rather than of your domain. Start with digests, keep receipts last, and watch the numbers for weeks. ## Questions to ask before you sign Put these to a sales rep, or find the answer in the documentation before anyone quotes you a number. 1. When support asks whether a customer received a particular message, do they need the status or the content — and which of these two can still answer that in six months? 2. Does anybody send bulk mail from the same domain as our password resets today, and what specifically stops that continuing after the switch? 3. Is any of our traffic batch-shaped, and has somebody counted calls per second at peak rather than messages per month? 4. How long must we be able to prove what we sent, and is that a written obligation or a habit nobody has examined? 5. Who writes and edits our transactional copy, and does that person open pull requests as part of their normal week? 6. If sending stopped tomorrow morning, who would we contact, and would that person be able to tell us what triggered it? 7. Are we deciding on deliverability or on developer experience — and if it is deliverability, what evidence do we have that is not one of the two vendors' own pages? ## A third shape of answer Both vendors keep your delivery history on their terms and inside their window, and neither can fix that for you, because the record lives in their system rather than yours. If losing the history is the part of this decision that actually worries you, the third shape is to send through SES inside your own AWS account, so events land in your storage under your retention policy. Wraps is one way to do that with a platform layer on top. It is a worse answer than either vendor here if what you want is to send an email this afternoon: it needs an AWS account and SES production access, an approval on AWS's schedule rather than ours. Wraps publishes this page. We are not one of the two vendors being compared here, and this note is on it because the tension above is one owning the AWS account actually addresses — not because it is on every page. ## Common questions ### Is Resend just a wrapper around Amazon SES? Substantially yes, and Resend has never hidden it. What you are buying is the layer on top: the SDKs, the dashboard, React Email, domain verification that finishes in minutes. The consequence worth understanding is not quality, because SES has a high deliverability floor. It is that the AWS account belongs to Resend, so reputation and event history accrue to them rather than to you. ### Which one actually has better deliverability? Postmark, by reputation and by the length of its record, and the message-stream separation is a real mechanism rather than a slogan. That said, most teams' deliverability problems are self-inflicted: unverified domains, no DMARC policy, purchased lists, marketing sent from a transactional domain. Neither vendor repairs any of those, and both will suspend you for them. ### Can I use React Email with Postmark? Yes. React Email renders components to HTML and is not coupled to Resend's API, so you can render to a string and hand that to Postmark, or to anything else that accepts HTML. The first-party path is more polished on Resend, but the templates themselves are portable — which is a decent argument for authoring them that way whichever vendor you pick. ### What happens to my logs if I switch? You export whatever is still inside the retention window and you lose the rest. Neither vendor hands you a historical archive on the way out, and neither is unusual in that. If long-lived history matters to you, the time to start streaming events somewhere you control is while you are still a happy customer, not during a migration. ### Does Postmark do marketing email? It has broadcast message streams, which is enough to send a newsletter to a list, and it stops well short of a campaign builder, segmentation or automation. If you need lifecycle marketing, Postmark expects you to bring a separate tool and keep the transactional stream clean. On its own terms that is the right answer, but it does mean two vendors. ### How do I test either of them without sending real email? Both give you a sandbox or test mode that accepts the call and does not deliver, which is enough to prove your integration compiles and your template renders. Neither tells you anything about inbox placement, because placement is a property of reputation and content rather than of the API call. If you want to know how a message will actually land, send it to seed addresses at the major mailbox providers and look, or use a dedicated placement testing service. Treat a green response from either sandbox as a syntax check, not an outcome. ### Does Resend have anything like Postmark's message streams? Not as an enforced mechanism. You can achieve the same separation by sending marketing and transactional traffic from different domains or subdomains with their own DKIM keys, which is genuinely effective and is what a careful team does everywhere. The difference is that Postmark makes it structural and will argue with you about bulk mail on the transactional path, whereas everywhere else it is a convention. Conventions work until an engineer who was not in the original conversation adds a send call to the obvious place. ### Can either of these receive inbound mail? Postmark can, through an inbound stream that parses the message and posts structured fields to your webhook, with the same activity view over what arrived. Resend does not, and treats that as a scope decision rather than a gap. Teams needing replies alongside Resend generally put Cloudflare Email Routing or an SES receipt rule in front and parse the result themselves, which means a second system, a second set of credentials and an outgoing message tracked in a different place from the reply to it. ### Which one copes better with a sudden large send? Postmark, and not by a small margin, because the constraint on that side is the plan's included volume rather than a request rate. A burst costs money and completes. On Resend the same burst meets a fixed two-per-second ceiling that no tier lifts, so it becomes a queue that drains over hours. Batch endpoints accepting several recipients per call stretch that considerably, so the real answer depends on how your send loop is written — but it is an architectural constraint rather than a commercial one, which means you engineer around it rather than paying to remove it.