This is not a purchase decision so much as an exit assessment. Mandrill arrived in your stack because somebody already paid for Mailchimp and noticed a transactional product attached, and it has probably worked without complaint for years. Resend is the name that surfaces when you start asking whether it should stay. The comparison worth having is therefore not feature against feature — it is what you currently depend on that would have to be rebuilt, and whether the thing you are unhappy about is actually fixed by moving.
At a glance
| Mailchimp Transactional (Mandrill) | Resend | |
|---|---|---|
| What it is | Transactional add-on to Mailchimp | Developer-first email API built on SES |
| Published pricing | $20 per block of 25,000 emails — $0.80 per 1,000. Requires a paid Mailchimp Standard or Premium plan underneath. Dedicated IP $29.95/mo. | 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 | Teams already paying for Mailchimp who want transactional on the same account. | The fastest path from an empty project to a sent email, especially with React Email. |
| Watch out for | Not purchasable standalone, so the real price includes a Mailchimp plan you may not want. Eight times raw SES per email, with little recent investment. | 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 has to exist in your account for it to work
Mailchimp Transactional (Mandrill)
A paid Mailchimp plan, underneath, permanently. Mandrill is an add-on and cannot be bought alone, so the true cost of your transactional sending includes a marketing subscription that may be doing nothing else for you. If that subscription exists anyway because marketing runs campaigns in it, Mandrill is close to marginal cost. If transactional is the only reason it survives renewal, that line is part of the saving and part of the decision.
Resend
An account and a verified domain, and nothing else. There is no prerequisite product, no bundled platform and no dependency on a purchasing decision made by a different department. Whether that matters depends entirely on whether you are the department that would have to justify the Mailchimp renewal.
How much the product is likely to change
Mailchimp Transactional (Mandrill)
Slowly, and that cuts both ways. Mandrill is mature to the point of stasis: it works, it has worked for a long time, and visible investment has been modest for years. A sender that stopped changing is a sender that stopped breaking, which is a real virtue for something your receipts depend on. It is a poor bet if you are counting on the surrounding tooling to improve.
Resend
Quickly, and that also cuts both ways. Resend ships frequently and the product surface today is meaningfully different from two years ago. You get improvements you did not ask for and occasionally changes you have to react to, and the flip side of a young platform moving fast is that its operational record is shorter than the thing you are considering leaving.
The templating you would have to rewrite
Mailchimp Transactional (Mandrill)
Mailchimp's editor plus merge tags, a syntax inherited from a marketing product rather than designed for transactional mail. It is convenient if your marketing team already lives in that editor and slightly awkward if they do not, and in practice teams end up doing more of the conditional logic in application code than the feature list suggests.
Resend
React Email components in your repository, rendered at send time. It is a genuinely better authoring model for an engineering team and it is a full rewrite rather than an export — there is no path that carries merge-tag templates across. Budget for rebuilding every template by hand, and treat that as the largest single line in the migration estimate.
Addresses your provider has quietly decided not to mail
Mailchimp Transactional (Mandrill)
Mandrill keeps a rejection list of hard bounces, complaints and manual blocks, and it is stricter than people expect. An address can sit on it indefinitely, so a customer who fixed their mailbox six months ago still receives nothing, silently. Knowing the list exists and auditing it is part of operating Mandrill competently, and exporting it is the first thing you do if you leave.
Resend
Suppression works on the same principle with better surfacing, and Resend's dashboard makes the list something you look at rather than something you remember exists. The rule on arrival is the same regardless of direction: import the old list before the first send, because mailing addresses that previously hard-bounced is the fastest available way to damage a reputation you have not built yet.
How much you can push, and how fast
Mailchimp Transactional (Mandrill)
Capacity is bought in blocks covering a fixed number of messages, and the constraint you meet is the block rather than a request-rate ceiling. A batch job that emits a large burst is an ordinary thing to do here, and the arithmetic to work out your real per-message cost has to include the platform subscription underneath, which the pricing page will not do for you.
Resend
Two requests per second, on every plan, with no upgrade that lifts it. This is the single most common way a Mandrill-to-Resend migration goes wrong: the existing integration was written without a rate ceiling in mind, the cutover happens, and the nightly digest job starts collecting rejections at two in the morning. Queue and drip before you switch, not after.
Inbound mail and reply handling
Mailchimp Transactional (Mandrill)
Mandrill routes inbound mail to a webhook and has done so stably for a long time. If some part of your product parses replies — a support thread, a bounce handler you wrote yourself — that configuration is a dependency you may not have thought about recently, and it is one of the pieces most often forgotten in a migration plan.
Resend
Inbound is the narrower part of Resend and came much later than the send path. Before you commit, check whether your specific reply-handling requirement is genuinely covered, because this is the axis on which the newer product is least likely to be at parity with the old one.
Who actually operates the sending
Mailchimp Transactional (Mandrill)
Mailchimp's own infrastructure, inside a large company with its own abuse posture and its own IP pools. Your neighbours in that pool are Mailchimp's transactional customers. The account relationship is shared with the marketing side, which matters in the direction people do not expect: an account problem originating in campaigns is an account problem for your receipts.
Resend
Amazon SES with Resend's engineering on top. The deliverability floor is AWS's and it is high. The account is Resend's, so reputation accrues to their identities rather than yours, and the dependency chain has one more link in it than the comparison suggests.
What you can look up afterwards
Mailchimp Transactional (Mandrill)
Outbound activity with content and delivery state, searchable within a retention window, which is adequate and shows its age. A support person chasing one customer's missing receipt takes more steps than they should, but the information is there.
Resend
A clean activity view and a webhook stream, with a hard thirty-day purge on every plan below Enterprise. Read that against whatever your current Mandrill window is before you move, because a migration that quietly shortens how far back your support team can look is a migration that generates complaints from a direction nobody predicted.
What the cutover actually looks like
Mailchimp Transactional (Mandrill)
Leaving means exporting the rejection list, rebuilding every template, rewriting webhook consumers against different event shapes, and deciding what happens to the Mailchimp subscription. The part that bites is discovery: grep for the API key rather than the vendor name, because the integration nobody remembers was configured by hand on a server rather than committed to a repository.
Resend
Arriving means verifying domains, importing suppression before the first production send, putting a rate limiter in front of anything that bursts, and pointing the webhook somewhere durable on day one rather than after the first thirty-day window closes. Move one traffic class at a time and keep the mail customers would notice missing on the proven path until last.
Pros and cons, side by side
Mailchimp Transactional (Mandrill)
Strengths
- Subaccounts carry their own standing, their own ceiling and their own reporting, so one brand having a bad week does not quietly become another brand's delivery problem.
- The content of a sent message is kept and readable, so an agent can answer what the customer actually saw rather than what the template says they should have seen.
- Capacity is bought in blocks rather than metered against a plan, which means the invoice cannot exceed a number somebody already approved in advance.
- The API surface has not moved in years, so code written against it a long time ago still runs and has never once demanded an unplanned afternoon from anybody.
Trade-offs
- The transactional product is not sold by itself, so an honest per-message figure has to include a subscription that exists for a different department's reasons entirely.
- Its relay authenticates with the API key as the password, so the secret typed into an appliance by a contractor is the same secret that can administer your sending.
- The substitution syntax came out of a campaign editor, so conditionals are awkward enough that teams quietly move the logic into application code and stop using what they are paying for.
- Visible investment has been modest for a long stretch, which makes anything it does not do today a thing it will most likely never do.
Resend
Strengths
- Templates are components in your repository, reviewed in a pull request and deployed alongside the application, which is the better engineering story by a considerable distance.
- The product is visibly being built, so its surface a year from now is likely to contain things you asked for rather than things you learned to work around.
- There is no prerequisite product, so the sending relationship is one line on one invoice and it ends on the day you decide it does.
- Bulk mail sent through broadcasts carries an unsubscribe link by design, which takes a compliance decision off the list of things a busy team can quietly forget.
Trade-offs
- Two requests per second applies on every plan and no amount of money lifts it, so a batch-shaped workload is re-engineered rather than migrated.
- Logs are purged at thirty days on every plan short of Enterprise, so any answer about last quarter has to be one you arranged to keep in advance.
- There is no tenant primitive, so an account sending for several customers reconciles domains, keys and reporting inside something it built and now maintains.
- The sending identity belongs to the vendor rather than to you, so the standing you accumulate is an asset that cannot travel, and this migration is the shape of the next one.
Pick in thirty seconds
Choose Mailchimp Transactional (Mandrill) if
- Marketing already runs campaigns in Mailchimp, so the platform subscription exists regardless and transactional is marginal cost on it.
- The integration has run untouched for years, nothing is actually broken, and the migration has no funded owner.
- Your sending has burst shapes that a hard two-per-second ceiling would force you to re-engineer around.
- Inbound routing is load-bearing in your product and you would rather not re-verify that capability on a newer platform.
Choose Resend if
- You want templates in version control as components, reviewed and deployed like the rest of the codebase.
- The Mailchimp subscription exists only to make transactional sending possible, and removing it is a real saving.
- You are building new and want SDKs, current documentation and a product that is visibly being invested in.
- Your traffic is steady request-response mail that will never approach the rate ceiling.
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.
- Find everything authenticating over SMTP before you touch the API integration, then look at what those senders are using as a password. On one side the relay credential is the API key itself, so a printer in an office and a reporting tool a contractor installed are both holding the secret that administers your sending. Both products accept a relay connection, so the traffic can move; the credential model cannot, and arrival is the only moment where fixing it is free.
- Work out whether anything depends on subaccounts, because the destination has no object for them. Separate reputations, separate hourly ceilings and separate reporting per brand or per customer is a primitive on one side and a convention on the other — several domains, several keys and a reconciliation you write yourself. A single business with one brand loses nothing; anybody sending on behalf of other people loses the thing that was containing their worst customer.
- Render every template against real data on both sides and diff the results, because the two substitution models resolve conflicts differently. One applies a per-recipient value over an account-wide default according to a precedence rule that lives in documentation rather than in your code; the other resolves whatever your own function returns. Every template where a default and an override could both apply is a place they disagree, and nobody finds those by reading.
- Decide how you intend to slice the event stream afterwards and attach the dimension at send time, because neither product will infer it later. Both let you hang your own labels on a message and surface them on the resulting events, and the labels chosen in week one are the only ones any report can ever group by. Pick the handful that match how the business asks questions and set them inside a shared send helper rather than at each call site.
- Establish where campaign mail is going and what it will be required to carry. The destination's broadcast feature is built around an audience and writes an unsubscribe link into every message by design, which is correct and is also a change if bulk mail currently leaves through the transactional path with nothing attached. A team used to announcing something through the same call it uses for receipts finds out on the morning of the announcement.
- Decide what happens to the messages themselves rather than only to the record of them. One side keeps the content of what it sent and lets an agent read it back; the other keeps activity for a finite window and never the body. If somebody's job today involves opening a sent message to see what a customer received, that job changes, and the honest options are logging the rendered output yourself at send time or telling that person plainly that the capability has gone.
- Understand whose reputation you are borrowing on each side, because it is not yours in either case. One sends from a large marketing company's own pools; the other sends through infrastructure it rents from a cloud provider under identities it controls. Neither arrangement leaves standing attached to your domain in a form you could carry away, so the migration you are planning now is structurally the same one you will plan again later.
- Re-forecast the bill under a different failure mode rather than a different rate. Capacity purchased as blocks that expire means over-buying is money gone and under-buying is a hard stop; a plan ladder with automatic overage means neither of those and an invoice that can exceed what anybody approved. Work out which of those two surprises your finance team would rather receive, because that is the real difference and it is on neither pricing page.
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.
- What is authenticating over SMTP today, and is the password those systems hold the same secret that administers our account?
- Do we send under more than one brand or for more than one customer, and is anything currently keeping those reputations apart?
- How would we want to group our delivery events six months from now, and is anybody attaching that label at send time today?
- Does our bulk mail leave through the same call as our receipts, and what exactly is in its footer?
- When support needs to see what a customer actually received, do they open the vendor's interface or our own logs?
- Would our finance team rather over-buy capacity that expires, or approve an invoice that moved on its own?
- Who writes the words in our emails, and has anybody told them what happens to that on the other side of this decision?
A third shape of answer
Both sides of this comparison end with the same structural fact: the sending identity, the suppression list and the delivery history belong to the vendor, which is exactly why leaving Mandrill is a quarter of work rather than a config change. If the reason you are reading this is that you never want to do this migration again, the third shape is to send through SES inside your own AWS account, where the domain identities, the suppression list and the event stream are resources you own and a future vendor change is a library swap rather than a rebuild. Wraps is one way to run that with tooling on top. It is the wrong answer if you want the new integration finished this week: it needs an AWS account and SES production access, which is an approval on AWS's schedule and can be refused.
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 Mandrill being discontinued?
There has been no announcement to that effect and it continues to operate, so describing it as discontinued would be wrong. What is fair is that visible investment has been modest for a long stretch, which is a legitimate input when you are deciding where to put something your product depends on. If it works today, that is not a reason to migrate this quarter. It is a reason not to build new dependencies on features you are hoping will improve.
What do I have to export before I switch?
The rejection list first, because sending to previously bounced addresses on a brand-new sending identity is the fastest way to start badly. Then every template, since nothing carries across between these two paradigms. Then as much delivery history as your window still holds, because a dispute about a message sent last quarter will not wait for your migration to finish. Finally, write down every system that holds an API key — the cron job on the old box is the one that keeps sending from an account you thought you had closed.
Will my deliverability improve if I move to Resend?
Possibly, and not because of the vendor. Most deliverability problems belong to the sender: a stale list, a missing DMARC policy, marketing and transactional sharing a domain, content that trips filters. Moving relocates those problems intact. What does change is your reputation history, which resets — you start as a new sender on a new pool, and the first two weeks of a migration are exactly when a bad list does the most damage. Warm up deliberately and move your highest-engagement traffic first.
How do I handle the rate limit for a batch job?
Put a queue between your application and the API, and drain it at a rate safely under the ceiling with retry-with-backoff on rejections. For most teams this is a day of work using infrastructure they already run. The thing to avoid is a naive loop with a sleep in it, because it fails badly the moment two instances of the job run at once — the limit is per account, not per process, and nothing in your code will tell you that until the retries start.
Can I run both during the migration?
Yes, and you should. Route by traffic class rather than by percentage: move the least critical mail first, watch bounce and complaint rates on the new identity for a couple of weeks, and keep password resets and receipts on the old path until the new one has a record. Use a distinct subdomain for the new sender so its reputation is genuinely separate, and keep both webhook consumers running until you have confirmed no straggler is still calling the old key.
Does Mandrill's SMTP relay use my API key as the password?
Yes, and it is worth sitting with what that means before you plan anything else. Authenticating to the relay means presenting the API key as the SMTP password, so every system configured to send that way is holding a credential that is not scoped to relaying — it is the same key that can read your account, manage the rejection list and send anything it likes. Over a few years those credentials end up in appliance settings pages, in a contractor's configuration management, in a wiki article somebody wrote for the next person, and in at least one screenshot. Treat the migration as the rotation you have been postponing: issue fresh credentials per system on the destination, and once the old ones are dead, go back and remove the copies rather than assuming they stopped mattering.
What replaces subaccounts if I leave?
Several domains and a reconciliation you write, which is more work than it sounds and less than people fear. Subaccounts give each brand or customer an isolated reputation, its own sending ceiling and its own slice of reporting, all administered from one parent account. A product with no equivalent gives you verified domains sharing one account's standing, so the isolation has to come from separate domains, separate keys, and your own control plane joining the reporting back together for a per-customer view. For a single business with one brand this is a non-issue and you should not pay for an object you would never use. For a platform sending on behalf of customers it is usually the deciding fact, because the day one tenant imports a purchased list, the containment is the only thing standing between that and everyone else's mail.
Will my support team still be able to read a sent message?
Only if one of you keeps a copy, and the two products differ on whether the vendor does. Storing the rendered content of what was sent is a real feature with a real cost, and a product that offers it is offering your support team the ability to open a message and read exactly what a customer received, rather than inferring it from a template and a set of variables. A product that keeps activity but not content gives them a status and a timestamp. If a workflow depends on reading the body — a billing dispute, an accessibility complaint, a customer insisting the link was wrong — decide before the cutover whether you will log your own rendered output at send time. It is a few lines in the send helper and it is impossible to add retroactively for messages already gone.
What should I tag a send with, and when do I decide?
Decide before the first production send, because tags cannot be applied to events that already happened. Both products let you attach labels to a message that come back on the delivery, bounce and complaint events, and those labels are the only dimensions any later report can group by. The useful set is small and matches how your business asks questions rather than how your code is organised: the message type, the tenant or brand it went out for, the release or campaign it belonged to. Three or four well-chosen ones beat twenty invented over a year. Set them inside a single shared send function rather than at each call site, because tags applied at call sites drift within a quarter and then the reporting quietly stops adding up without anybody being able to say when it started.