# MailerSend vs Resend Source: https://wraps.dev/versus/mailersend-vs-resend Two modern transactional APIs that look alike from the outside and were built for opposite people. One assumes a marketer will open the template. The other assumes nobody but an engineer ever will. These two land on the same shortlist constantly, and the reason is a bad one: both are modern, both have clean APIs, both are cheaper than the incumbents. Look at what each one put at the centre of the product and they diverge immediately. MailerSend built a drag-and-drop builder and wrapped an API around it. Resend built an API and made the template a React component in your repository. Everything that follows — who files the ticket when the copy is wrong, how the two products meter you, what else they will sell you — comes out of that one decision. ## At a glance |   | MailerSend | Resend | | --- | --- | --- | | What it is | Email API with a drag-and-drop template builder | Developer-first email API built on SES | | Published pricing | Free 500/mo (100/day). Starter $35/mo at 50K ($31.50 annual). Professional $110/mo at 50K ($99 annual). Overage from $1.30 per 1,000, falling as plan size grows. | 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 | Mid-market teams who need a template builder a non-engineer can open. | The fastest path from an empty project to a sent email, especially with React Email. | | Watch out for | The free tier is only 500 emails a month, and Professional costs $75/mo more than Starter for identical volume — you are buying seats and retention, not sending. | 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 ### Where the template physically lives MailerSend In MailerSend's account, edited in a visual builder, with variables an engineer wires once and copy anybody can change afterwards. There is no deploy in the loop, which is the point. The cost is that your email templates are now state in somebody else's system: they are not in version control, a bad edit has no diff, and rolling one back means remembering what it used to say. Resend In your repository, as a React component, rendered by React Email at send time or build time. It diffs, it reviews, it rolls back with a revert, and it can be unit tested. The cost is symmetrical: every copy change is a pull request, and the person who wanted to soften a sentence in the welcome email now needs an engineer and a deploy window. ### The rate limit you will actually meet MailerSend MailerSend publishes per-endpoint API limits that rise with the plan, and it ships a bulk send endpoint specifically for pushing many messages in one call. A batch job is a supported shape rather than something you work around, and if you outgrow the entry limit the answer is a plan change rather than an architectural one. Resend Resend caps the API at two requests per second on every tier including the most expensive, and no amount of money removes it. For login codes and receipts that is ample. For a job that wants to emit ten thousand messages before the hour is out, you build a queue and a drip, which is ordinary work but it is work, and discovering it after you have written the integration is the common way to find out. ### What the free allowance is good for MailerSend A demonstration rather than an environment. The monthly free ceiling is low enough that a staging system with any real traffic will exhaust it, so plan on either a paid plan for non-production or a separate capture tool. That is easy to arrange deliberately and annoying to discover when a seeded test run eats the month on a Tuesday. Resend A small real environment, with a monthly allowance that is genuinely usable and a daily cap sitting underneath it. The daily cap is the part that surprises people: a load test or a bulk import can hit the ceiling for the day while the month still shows plenty of headroom, and the failure looks like an outage rather than a quota. ### What you can still answer three months from now MailerSend MailerSend keeps activity with a retention window that lengthens as you move up the plans, which makes retention a thing you can purchase rather than a fixed wall. Whether you should purchase it is a real question — for many teams the honest answer is that the second plan tier is being bought for history and seats rather than for sending. Resend Thirty days on every plan below Enterprise, then the record is gone. The scenario is not hypothetical: someone disputes a notification in March and you are looking in June. Streaming the webhook into your own store from the first week fixes it entirely and costs almost nothing, and virtually nobody does it until the first time the window closes on them. ### Receiving mail as well as sending it MailerSend Inbound routing is part of the product. You point a domain or subdomain at MailerSend, define routes, and parsed messages arrive at your webhook, which is enough to build reply-to-ticket handling on without a second vendor. The parsing handles the tedious parts — multipart bodies, attachments, quoted history — so your handler is a function rather than a MIME project. Resend Resend's centre of gravity is outbound, and inbound arrived later and stays deliberately narrower. If reply handling is load-bearing for your product rather than a nice extra, check the current shape of it against your actual requirement rather than assuming parity, because this is the axis where the two products are least comparable. ### Whose sending operation is underneath MailerSend MailerSend sits inside the same company as MailerLite and sends on infrastructure that company runs, with its own IP pools and its own abuse posture. The practical consequence is that the vendor you complain to is also the vendor that can fix it, and that the shared pool you sit in is populated by that company's other customers rather than by a hyperscaler's entire customer base. Resend Resend is a layer over Amazon SES, which it has never hidden. The deliverability floor underneath is AWS's and it is a high floor. It also means the AWS account is Resend's: the reputation you build accrues to their identities, and a policy decision made by AWS about their account is a policy decision about your sending. ### Channels other than email MailerSend MailerSend sells SMS alongside email on the same account, which matters if you are about to add one-time codes over a second channel and did not want a second vendor, a second contract and a second set of compliance questions. The depth is modest next to a dedicated messaging platform, and modest is usually what a verification code needs. Resend Email only, on purpose. Resend has stayed narrow and the product is better for it, but the narrowness is a real constraint the day somebody decides the checkout confirmation should also go by text. You will be adding a vendor, and the comparison you should run then is against a messaging provider rather than against MailerSend. ### What the higher plan is really selling MailerSend Seats, retention and support. The step up can cost substantially more than the entry plan for exactly the same sending volume, which reads as a mistake on the pricing page until you understand it as a per-organisation price. A solo developer should stay on the entry tier and stop reading; a team of six with a marketer and a support rota is the customer the upper plan was drawn for. Resend Headroom and a different risk posture. Resend splits into two ladders and identical volume costs materially different amounts depending which one you sit on, with the higher one aimed at teams whose sending is the business rather than a feature of it. Marketing contacts are metered separately from sends, so a list that grows raises the bill in a month you sent nothing to it. ### Bulk and campaign sending MailerSend There is real campaign capability here — lists, a scheduled send, the same builder — which suits the team that wanted one tool for the product emails and the occasional announcement. It is not a lifecycle platform and does not claim to be, but it clears the bar for a monthly product update without a second subscription. Resend Broadcasts exist and are deliberately simple: an audience, a React or HTML email, a send. For a changelog to people who asked for it that is the right amount of product. For segmentation on behaviour, branching journeys or anything a growth team would recognise as automation, you are buying a second tool and wiring the contacts across. ## Pros and cons, side by side ### MailerSend Strengths - The builder is the centre of the product, so whoever writes the words changes them without a deploy and without waiting for space on an engineer's week. - A bulk endpoint accepts the job and reports afterwards, which makes a batch a supported shape rather than a queue you assemble to get around a ceiling. - Inbound routing is mature and included rather than recent and narrow, so reply handling needs neither a second vendor nor a step up the plan ladder. - SMS lives on the same account, which turns sending verification codes by text into a settings change instead of a new contract and a new integration. Trade-offs - Templates become state inside somebody else's system: no diff, no review, and rolling one back means somebody remembering what it used to say. - A new account waits on a human review before it may send to arbitrary recipients — entirely sensible, and sitting on a queue that is not yours to prioritise. - The free allowance is a demonstration rather than an environment, so a staging system costs either a paid plan or a capture tool arranged on purpose. - The upper tier costs substantially more at identical volume because it sells seats, retention and support, which is a per-organisation price wearing a per-message costume. ### Resend Strengths - Templates are components in the repository: they diff, they get reviewed, they revert with a commit, and they can be unit tested like any other code. - A sending domain is created in a region you choose, so where mail is processed becomes a decision at setup rather than a question you have to put to the vendor. - Sends accept an idempotency key, so a retried call after a timeout does not deliver a second copy of the same receipt to a confused customer. - The floor underneath is AWS's, which is a high one to inherit for nothing, and the product surface is small enough that nobody spends an hour choosing between four ways to do one thing. Trade-offs - Two requests per second on every tier, permanently, so anything that bunches becomes a queue you build, operate and are never allowed to delete. - Logs purge at thirty days below Enterprise, and the dispute that needs you in June to look at March does eventually arrive. - Marketing contacts are metered apart from sending, so an audience that grows raises the invoice in a month when nobody sent anything to it. - Inbound arrived later and stays deliberately narrower, so reply handling is the axis on which these two products are least comparable to each other. ## Pick in thirty seconds ### Choose MailerSend if - Someone who does not write code needs to change email copy this week, and waiting for a deploy is the friction you are actually trying to remove. - Reply handling matters to your product, so inbound parsing needs to be a mature part of the vendor rather than a recent addition. - You are about to add SMS and would rather not run a second vendor relationship for one-time codes. - Your sending has burst shapes — an overnight digest, an import notification — and a hard two-per-second ceiling would mean building a queue you had not planned. ### Choose Resend if - Emails are part of the codebase to you: reviewed, versioned, tested, deployed with everything else. - Time from empty project to first sent message is the metric you are optimising, and React Email is already how you want to author. - Traffic is steady request-response mail well inside the rate ceiling, with nothing in the system that sends in batches. - You already intend to stream delivery events into your own warehouse, so a thirty-day vendor 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. Measure calls per second at peak rather than messages per month, because only one side carries a fixed ceiling. Two per second on every tier is not a limit anybody grows out of by spending more, and a batch endpoint that takes many messages per call is the mitigation rather than an exemption. Go and find the loops in your code that walk a list sending one at a time; those are what meet the limit on the very first run. 2. Replace the webhook verification, not merely the URL it points at. The two sign differently — one with its own scheme over the payload, the other through a third-party signing convention with its own headers and replay window — so the handler's security code is new work that belongs in a review rather than in a follow-up ticket. Verification skipped for now during a migration is verification that stays skipped for years. 3. Decide whether you want idempotent sends, because one side offers a key on the request and the other does not. If your send path retries on a timeout, and most of them do somewhere, the direction you are travelling determines whether a retry is safe or produces a second receipt. Moving toward the key is a chance to fix that properly; moving away from it means building the deduplication yourself and remembering why. 4. Choose the domain's region deliberately if you are moving toward the side that asks. A sending domain is created in one region and the choice is made at setup, so five careless minutes become a property of your infrastructure. If nobody in the company has a view, the defensible answer is wherever your recipients actually are, and it is worth writing down why in case somebody asks in a year. 5. Rebuild the templates and carry the variable contract across with them. A builder wires variables once and lets copy move freely; components make the contract explicit and checkable before anything ships. Moving toward components, the variables that were quietly optional are the ones that start rendering as empty blocks in production. Moving the other way, you are handing an artefact to somebody who cannot see a diff of what they changed. 6. Name the owner of email copy afterwards, because this pair changes who that person is far more reliably than it changes anything technical. Both arrangements are defensible and only one of them matches how your team already works. Skip the conversation and you ship a clean migration, then spend a year being asked either when the editor is coming back or when review will stop blocking a one-word fix. 7. Stand up the event pipeline before the retention window becomes your problem rather than after. One side lengthens history as you climb the plans; the other purges at thirty days on everything short of Enterprise. If any process downstream reads records older than a month, building that stream into storage you control belongs inside this project and not on the list of things after it. 8. Re-home the inbound path on its own schedule and verify rather than assume. Routing with matching on one side and a later, narrower capability on the other are not one integration with a different hostname, so test the current shape against your real requirement before designing for parity. A reply that lands nowhere raises no error anywhere — the customer simply concludes you ignored them. ## 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. What is our peak sends per second, measured rather than estimated, and does any code path loop over a list one message at a time? 2. Does our send path retry on a timeout, and what actually happens today when it succeeds twice? 3. Who changes the copy in our emails, and would we rather that be a pull request or a login? 4. Does anybody need to know which region our mail is processed in, and can we settle it at setup or only ask afterwards? 5. How far back do we ever look at a delivery, and is anything downstream reading records older than a month? 6. Is reply handling structural to the product or a convenience, and have we tested the current capability rather than read about it? 7. Are we adding SMS within the year, and would standing up a separate vendor for it be acceptable when we do? ## Common questions ### Can I use React Email with MailerSend? Yes. React Email renders components to an HTML string and is not coupled to any particular vendor's API, so you can render and hand the result to MailerSend's send endpoint exactly as you would to anything else. What you lose is the reason to choose MailerSend in the first place: if templates live in the repository, the builder is not doing anything for you and the comparison should be run against vendors that optimise for the code path instead. ### Is the two-requests-per-second limit really on every Resend plan? Yes, and it is the fact most likely to invalidate an otherwise sound evaluation. It is not a soft limit you grow out of by spending more. The workaround is standard — enqueue sends and drain the queue at a safe rate, with retries on the rejections — and it is perhaps a day of work. Budget the day, or confirm your traffic genuinely never bunches, before you commit the integration. ### Which of these has better deliverability? There is no honest general answer, and anybody giving you one is selling something. Resend inherits a high floor from AWS; MailerSend runs its own pools with its own abuse controls. Both are shared reputation, so your neighbours matter and you cannot audit them. What actually decides your placement is under your control anyway: authenticated domains with a DMARC policy, a separate subdomain for bulk mail, prompt suppression handling, and not sending to addresses that never asked. ### How do I let a marketer edit copy without giving up version control? Split the template from the content. Keep the layout, the variables and the structural HTML in code where they are reviewed, and put the handful of strings that actually change into a small content store the marketer can edit — a database table, a CMS entry, a feature-flag payload. It is more work than a hosted builder and less than it sounds, and it is the arrangement teams usually land on after trying both extremes and disliking each. ### What does migrating between these two actually cost? The send call is a small change. Everything around it is not. Templates have to be rebuilt in the other paradigm, which is a genuine rewrite rather than an export, and webhook consumers have to be rewritten against different event shapes. Export your suppression list and import it before the first send rather than after, or you will re-send to addresses that already bounced and damage a reputation you are still establishing. Then grep your infrastructure for the old API key rather than for the vendor name — the forgotten cron job on a box nobody logs into is what turns a one-week migration into a quarter of stragglers. ### Can we make sends idempotent so a retry does not duplicate? One of these accepts an idempotency key on the request, so a retried call after a network timeout is recognised rather than delivered again. The other does not, which means the responsibility sits with you. This matters more than it sounds, because almost every send path retries somewhere — an HTTP client with defaults nobody chose, a queue with at-least-once delivery, a background job that crashed after the call succeeded but before the row was written. If the vendor will not deduplicate for you, the pattern is to generate a stable key per logical message, record it before the call and check it after, which is a small piece of work that prevents a customer receiving the same receipt twice. ### How do we verify webhooks from each of these? Differently enough that the code is new on either side of the move. One vendor signs with its own scheme over the payload and hands you a secret to check against; the other delivers through a third-party signing convention with its own headers, its own timestamp and its own replay window. Both are perfectly good and neither handler will work against the other. Treat this as security work with a review rather than as a field-mapping chore, and resist the temptation to skip verification during the migration on the grounds that you will add it afterwards — the endpoint is public, and afterwards has a way of not arriving. ### Can we choose where our email is processed? On the developer-first side a sending domain is created in a region you select, which makes the residency answer a decision you take at setup. That is genuinely useful when somebody asks the question, and it is a decision you make once and live with rather than a setting you toggle later. It does not change who holds the account — the boundary still belongs to the vendor, so a compliance questionnaire that wants to name the ultimate processor gets a longer answer than the region alone provides. On the other side the footprint is what it is, documented and not configurable. Which of those satisfies your reviewer is worth establishing before anything technical starts. ### Which one can we safely run our staging environment on? Neither for free, if staging does anything realistic, and the reason differs on each side. One gives a monthly allowance low enough to be a demonstration rather than an environment. The other gives a more usable monthly figure with a daily cap sitting underneath it, which is the part that surprises people: a seeded test run or a load test exhausts the day while the month still shows plenty of headroom, and the failure looks like an outage rather than a quota. Decide deliberately — a cheap paid plan for non-production, or a capture tool that accepts everything and delivers nothing — rather than discovering the ceiling on a Tuesday afternoon.