# MailerSend vs Mailgun Source: https://wraps.dev/versus/mailersend-vs-mailgun A focused product with a builder at its centre against a high-volume platform whose centre is a routing engine. Both send email competently. Only one of them is trying to be infrastructure. These two are both called email APIs and the label does more harm than good. MailerSend is a product: a builder, a clean dashboard, an API around the outside, sized for a team that wants email handled. Mailgun is closer to infrastructure: routing rules with filter expressions, address validation as its own product, subaccounts for tenant isolation, and log retention you buy by the tier. You are usually choosing between wanting less to think about and wanting more control over how mail moves through your system. ## At a glance |   | MailerSend | Mailgun | | --- | --- | --- | | What it is | Email API with a drag-and-drop template builder | High-volume email API with routing and validation | | 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. | Basic $15 at 10K. Foundation $35 at 50K and $75 at 100K. Scale $90 at 100K rising to $400 at 500K. Dedicated IP included from the $75/mo plans; extra IPs $59/mo each. | | Best for | Mid-market teams who need a template builder a non-engineer can open. | High-volume sending where routing, validation, and log search need to come from one vendor. | | 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. | Flex closed to new signups in December 2025 and the legacy rate doubled to $2 per 1,000. The free tier is a hard 100/day cap, and suspensions recur in 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 happens to mail arriving at your domain MailerSend Inbound routes deliver parsed messages to a webhook, which covers the common case — replies to a support address land in your application — without a plan step or much configuration. It is a forwarding feature done well, and it stops where forwarding stops. Mailgun Routes are a rule engine. You write match expressions against recipient, sender and headers, attach actions, and order the rules by priority, so a single inbound domain can fan out to several destinations under different conditions. If you are building something that receives mail as a real part of the product rather than as a reply path, this is the largest single gap between these two. ### Checking an address before you send to it MailerSend Verification tooling is available for screening a list before an import, which is the direct answer to the most common cause of a bounce-rate incident. Screening inside the same vendor that will judge you for the bounces removes a category of self-inflicted damage, and the depth is appropriate to the size of sender this product is for. Mailgun Validation is a product in its own right at Mailgun, with its own API, backed by the observation data of a very large sending operation and usable independently of whether you send through them. For a team that acquires addresses through forms at any real rate, the ability to reject a typo at signup rather than discover it as a hard bounce a week later is a meaningful, measurable improvement. ### Sending on behalf of other people MailerSend The model is flat: several verified domains on one account, sharing one reputation and one suppression list. For a single company with a handful of domains that is a correct and simple model. For an agency or a platform sending for many customers, the absence of real separation becomes a problem the first time one of those customers imports a purchased list. Mailgun Subaccounts give each tenant its own sending identity, its own suppression and its own reporting under one parent relationship, so one tenant's bad list is contained. If you are a platform rather than a company, this feature frequently decides the evaluation before anything else is compared, and it is genuinely hard to replicate by convention. ### Who is expected to write the email MailerSend A marketer, in a drag-and-drop builder that is the centre of the product rather than a feature on the list. Variables get wired once by an engineer, copy changes afterwards without a deploy, and for a small team that removes a recurring interruption. The trade is that templates become state in a vendor's system, outside version control and without a diff. Mailgun An engineer, in a handlebars-style templating syntax stored with the vendor and versioned there. It is competent and it is not a design surface, so the marketer who wants to reword a subject line is filing a ticket or learning the syntax. That is a reasonable answer for an infrastructure product and a poor one if template editing is the friction you were trying to remove. ### How long the logs live MailerSend Retention lengthens as you move up the plans, which makes history a purchasable quantity rather than a fixed wall. The practical upshot for a small team is that the upper tier is often being bought for retention and seats rather than for sending volume, and it is worth being honest with yourself about which one you need. Mailgun Retention is explicitly a tier attribute at Mailgun and the entry plans are short. This is the detail most likely to bite after a migration: your support team's ability to answer a question about last quarter changes silently with the plan, and nobody notices until somebody asks. Check the number on the plan you are actually buying rather than the one in the comparison table. ### The December 2025 repricing and who it moved MailerSend MailerSend's structure has been stable: an entry plan, a higher plan that sells seats and retention rather than volume, and overage published per thousand. Nothing about it recently forced a cohort of customers to re-evaluate, which is worth something on its own when you are choosing where to put a five-year dependency. Mailgun Flex closed to new signups in December 2025 and the legacy rate for existing users doubled, which is the event that put a large number of small Mailgun accounts into the market for the first time in years. Read any Mailgun comparison written before that date as describing different economics, and price the plan you can actually sign up for today. ### European handling MailerSend MailerSend is a European company, and for organisations whose requirement is really about who they are contracting with and under which regime, that is a simpler story than a region toggle inside a US platform. It is not a substitute for reading the data processing agreement, and it does shorten the conversation. Mailgun Mailgun operates an EU region you select at domain creation, and the selection is not reversible afterwards — a domain created in the wrong region has to be recreated. The capability is real and the footgun is real, and it is exactly the kind of detail that surfaces during a compliance review six months after somebody set the account up quickly. ### Dedicated addresses and the arithmetic around them MailerSend Dedicated sending is available and, at the volumes this product is usually bought at, shared is the better answer anyway — an IP without consistent volume behind it warms badly. The thing to understand is that isolation is not a lever you can pull on a bad week if your volume does not support it. Mailgun Dedicated IPs are included from the mid plans and additional ones are a published monthly line, which makes Mailgun one of the more straightforward vendors to price a multi-IP setup with. That matters if you genuinely send enough to warm several addresses and want to separate traffic classes across them rather than across subdomains. ### Who owns the company, and what that implies MailerSend MailerSend sits alongside MailerLite under one owner, which means the sending operation, the abuse posture and the roadmap all belong to a company whose entire business is email for small and mid-size senders. The pool you share is populated by that company's customers. Mailgun Mailgun is part of Sinch, a large communications group, and it has been through several ownership changes. The upside is the scale of the operation behind it and a genuinely deep feature surface. The downside is what a large group does to a product: pricing changes decided elsewhere, and suspensions that recur in public reviews with the impersonality large platforms are known for. ## Pros and cons, side by side ### MailerSend Strengths - The builder is the product rather than an item on a feature list, so somebody reworks the wording on a Tuesday afternoon and nobody has to open a repository to let them. - Variables are declared in the template and enforced on the request, so a field that quietly stopped being sent becomes a rejected call rather than a blank space in a customer's inbox. - Pricing here has been structurally stable, which counts for something when the dependency is meant to last five years and the other half of this pair repriced its entry tier last winter. - Text messaging sits on the same account, so a one-time code and a receipt come from one supplier on one invoice instead of two procurement conversations a year apart. Trade-offs - There is no tenant object at all, so an agency reproducing per-customer isolation is administering several accounts and reconciling them inside something it built and maintains. - Bulk sending is a job you submit and then poll, so a failure affecting one recipient arrives later and somewhere else rather than in the response your code is already holding. - Inbound matching has no notion of precedence, so a catch-all and a specific mailbox cannot be ordered against one another anywhere inside the product. - The upper plan mostly sells seats and retention, so a team buying it for history is buying the seats as well whether or not anyone will ever log into them. ### Mailgun Strengths - Routes evaluate in an order you set and a rule can stop the ones behind it, which is the difference between describing a mail flow and re-implementing one inside your own endpoint. - The assembled message is retained for a period and fetchable from a URL in the event payload, so a dispute about exactly what somebody received has an answer rather than a reconstruction. - Address verification is a separate product on its own meter, callable from an account that sends nothing, so a signup form can keep using it after the sending itself moves elsewhere. - Subaccounts carry per-tenant credentials, suppression and reporting, which is genuinely hard to reproduce by convention the first time one customer imports a list they bought. Trade-offs - Log retention is a tier attribute and the entry plans are short, so how far back a support agent can reach is a plan decision nobody framed as one when they chose it. - Deliverability tooling is a separate subscription, which means the sending plan in your comparison is a smaller amount of product than the figure it is sitting next to. - Flex closed to new signups in December 2025 and the legacy per-thousand rate doubled, which is the event that put a cohort of small accounts into the market in the first place. - Almost everything above the send call is sold as another product — verification, deliverability tooling, extra addresses — so the invoice climbs in steps a message-count forecast will never predict. ## Pick in thirty seconds ### Choose MailerSend if - A non-engineer needs to edit email copy without a deploy, and the builder being good is the requirement. - You are one company with a few domains, so tenant-level reputation isolation is something you do not need and should not pay for. - You want product email and the occasional campaign on one subscription rather than assembling them. - A simpler European contracting story is worth more to you than a region toggle you have to configure correctly. ### Choose Mailgun if - Inbound mail is part of the product and you need conditional routing rather than a single forwarding destination. - You send on behalf of customers and need per-tenant credentials, suppression and reporting. - Address validation at the point of signup would measurably reduce your bounce rate, and you want it from the same vendor. - You send enough to justify multiple dedicated addresses and want the per-IP price published rather than negotiated. ## 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. Decide whether anybody depends on retrieving the message itself rather than its status. One side keeps the assembled MIME for a period and puts a URL to fetch it inside the event payload; the other reports on a message without keeping a copy you can pull back. A support workflow that quotes the exact bytes somebody received, or a compliance answer that has to produce them, stops being possible the morning that URL is no longer in the payload, and nothing recreates it afterwards. 2. Write down what each inbound rule is for, then check whether the destination evaluates rules in any order at all. A priority-ordered chain where an earlier rule can stop later ones from running expresses things a flat set of address matches cannot: a catch-all that must not fire for six named mailboxes, a rule that both stores and forwards, a rule that rejects outright. Flattening that moves the precedence logic into your endpoint and gives somebody the standing job of maintaining it. 3. Notice that the verification product need not move with the sending. It is billed on its own meter and can be called from an account that sends nothing at all, so a team leaving for the sake of the template experience can keep the signup form calling exactly the endpoint it calls today. That is frequently the cheapest resolution of this whole comparison, and nobody proposes it because it means living with two invoices. 4. Compare how far ahead each side will hold a scheduled message, because the caps are different numbers and the failure is a rejection rather than a queue. Both accept a send time on the request and both refuse one too distant. Anything in your system that schedules further out than the shorter of the two caps needs a queue of its own, which is ordinary work that goes uncosted because scheduling looked like somebody else's solved problem. 5. Find out which of your senders is using the relay rather than the API, because both sides offer one and the credentials are shaped differently. A relay user issued per domain and a relay user issued per account stop being interchangeable the moment you have a fleet of small senders, and the systems on SMTP are precisely the ones whose configuration lives in a screenshot on a wiki rather than in anything a deploy would update. 6. Enumerate the variables each template expects before anybody rebuilds one, because the two products disagree about who declares them. A builder wires the names once and the send call must supply exactly those; a syntax evaluated on the vendor's side resolves what it is given and renders nothing for the rest. Travelling from the forgiving model to the strict one converts a quietly optional field into a rejected request, which is better and which arrives all at once. 7. Separate the two questions your reporting answers, because the destination may only answer one of them well. An aggregated endpoint tells you how many of last week's messages bounced; a per-message view tells you what happened to the one a customer is complaining about right now. Teams migrate the dashboards and forget the second question until an agent asks it, and the plan containing that view is regularly not the plan somebody picked on volume. 8. Price the deliverability tooling apart from the sending on whichever side sells it that way. Inbox placement testing, blocklist monitoring and seed-list reporting are a distinct subscription on one side and largely absent on the other, so two sending plans placed side by side are two different amounts of product. Establish whether anybody here would open that tooling monthly before you either pay for it or spend a year missing it. ## 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. Does anybody ever need the exact bytes a customer received, or only confirmation that something arrived? 2. Do our inbound rules depend on one rule stopping the others from running, and who would own that precedence if the product stopped expressing it? 3. Could we keep calling the verification endpoint after the sending moves, and is living with two invoices acceptable to whoever signs them? 4. How far ahead does anything in our system schedule a message, and does that exceed the shorter of the two caps? 5. Which of our senders speaks SMTP rather than the API, and whose wiki page is currently the only record of how they are configured? 6. When a template variable goes missing, would we rather find a blank space in production or a rejected call in staging? 7. Would anybody here genuinely open a deliverability dashboard once a month, and if not, why is one inside the price we are comparing? ## A third shape of answer Both of these price the things around sending — retention, validation, tenant isolation, dedicated addresses — as plan steps, which is why the bill on either side climbs faster than the message count does. If what you actually want is the routing and the history under your own control rather than rented by the tier, the third shape is to run SES in your own AWS account, where event streams land in your storage on your retention policy and tenant separation is a configuration set you define rather than a product feature you unlock. Wraps is one way to operate that with a platform layer on top. It is the wrong answer if you want validation and a rule engine out of the box this week: it needs an AWS account and SES production access, an application AWS can refuse. 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 ### What replaced Mailgun's Flex plan? Flex closed to new signups in December 2025, and accounts that remained on the legacy arrangement saw the per-thousand rate double. New customers choose from the named plans instead. The practical consequence for anyone reading older comparisons is that the cheap pay-as-you-go entry point people remember is not available to sign up for, so any recommendation resting on it is describing a product that no longer exists at that price. ### Do I need subaccounts or will separate domains do? Separate domains give you separate reputations and nothing else. Subaccounts give you separate credentials, separate suppression lists and separate reporting, which is what you actually need when a tenant can do something bad. The test is simple: if one customer imports a purchased list, does that harm any other customer's mail and can you see which customer did it? If the answer is yes and no, domains are not enough. ### Is address validation worth paying for? It depends entirely on how addresses enter your system. If they come from a form that a human types into, validation catches typos and disposable domains before they become hard bounces, and hard bounce rate is the number most likely to get your sending restricted. If your addresses come from authenticated accounts that already confirmed by email, you have validated them the only way that truly works and a validation service adds little. Nothing verifies that a valid mailbox belongs to somebody who wants your mail, which is what complaint rate actually measures. ### Can I move an existing domain between regions? Not on Mailgun — the region is fixed when the domain is created, and changing it means creating a new domain in the correct region and migrating to it, including re-publishing DNS records and re-warming reputation. Treat the region choice as a decision to make with whoever owns your compliance answer, before the first send, rather than something to tidy up later. It is a small step taken at the right time and a genuinely annoying project taken at the wrong one. ### How do I estimate the real cost of moving between these two? Count four things, not one. Rebuilding templates, which cross no paradigm boundary and have to be redone by hand. Rewriting webhook consumers against different event payloads. Rebuilding inbound routing, which is the piece most likely to be underestimated if you are moving away from a rule engine toward simple forwarding. And exporting and importing suppression before the first production send, never after. Then check the log retention on the plan you are landing on, because a shorter window is a support regression your team will discover the hard way. ### Can I keep using Mailgun's validation if I send somewhere else? Yes, and it is the option most people evaluating this pair never consider. Validation is a distinct product with its own API and its own meter, and nothing about it requires the messages themselves to leave through the same account. A team whose actual complaint is the template experience, or the price of the sending plan after the December 2025 repricing, can move the sending and leave the signup form pointed exactly where it is. You end up with two suppliers and two invoices, which is the reason nobody suggests it, and you also keep the thing that was genuinely reducing your bounce rate instead of replacing it with a lighter equivalent and hoping. Price both arrangements before assuming the comparison has to be settled as one decision. ### Can I get the original message back after it has been sent? On one side, for a while, and that difference matters more often than people expect. Mailgun retains the assembled message for a period and includes a storage URL in the event payload, so code that recorded the URL can fetch back exactly what left the building — headers, both bodies, attachments as they actually were. Most email products report on a message rather than keeping it, so once the send has happened all you have is the record your own application wrote, which is a reconstruction of what you asked for rather than evidence of what was produced. If a dispute ever turns on the precise content of a message, or if an auditor might ask, work out which of those two situations you are in before you switch, because the storage window is short and nothing recreates a message after it closes. ### My inbound setup is a catch-all with several exceptions — does it survive? Only if the destination understands ordering. A chain where rules are evaluated by priority and an earlier one can halt the rest expresses that pattern directly: the six named mailboxes match first and stop, the catch-all picks up everything else. A product whose inbound routing is a flat set of address matches has no way to say first this, otherwise that, so the whole arrangement collapses into one destination receiving everything and your endpoint deciding what to do with it. That is perfectly workable and it is a program: a mapping table, tests, and a person who remembers why the third exception exists. The mistake is planning it as a configuration change and discovering it is software after the migration date has been given to somebody. ### What is the difference between analytics and activity? Analytics is aggregate and activity is per message, and a support team needs the second one while a manager usually only asks for the first. Aggregate reporting answers how many messages bounced last week, what the open rate was on a domain, whether complaints moved. Activity answers what happened to the message this specific customer says never arrived, which requires the record of that one send to still exist and be searchable by recipient. The trap in both of these products is that the second capability is bounded by retention and retention is bounded by plan, so a plan chosen against a monthly volume figure can be a plan that cannot answer a question from six weeks ago. Check the retention number on the exact rung you intend to buy, not on the one in the comparison table.