# Mailgun vs Mailchimp Transactional (Mandrill) Source: https://wraps.dev/versus/mailgun-vs-mandrill Two transactional products that both live inside something larger — one inside a communications group, one inside a marketing platform you have to buy first. That parentage explains more about each than their feature lists do. Neither of these is a young product and neither is independent. Mandrill is an add-on to a marketing platform and cannot be bought without it. Mailgun is a piece of Sinch, a large communications group, and has changed hands more than once. Teams compare them because both send transactional mail at volume and both parse inbound, which is a narrower overlap than it looks. The decision usually turns on two things that are not features: what you have to purchase to get it, and how much you expect it to change. ## At a glance |   | Mailgun | Mailchimp Transactional (Mandrill) | | --- | --- | --- | | What it is | High-volume email API with routing and validation | Transactional add-on to Mailchimp | | Published pricing | 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. | $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. | | Best for | High-volume sending where routing, validation, and log search need to come from one vendor. | Teams already paying for Mailchimp who want transactional on the same account. | | Watch out for | 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. | 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. | 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 ### The prerequisite purchase Mailgun None. Mailgun is bought on its own, priced on its own plan ladder, and depends on no decision made by another department. Whether that matters to you depends on whether anybody else in your organisation is already paying for the alternative's parent product. Mailchimp Transactional (Mandrill) A paid Mailchimp plan, permanently, underneath. Mandrill is an add-on and cannot be purchased alone, so the true cost of transactional sending includes a marketing subscription. For a company already running campaigns there it is close to marginal cost. For everybody else it is the single fact that ends the evaluation, and it belongs at the top of your arithmetic rather than in a footnote. ### How much investment each is still receiving Mailgun Active but turbulent. Mailgun continues to ship, and it has also changed ownership and repriced — Flex closed to new signups in December 2025 and the legacy rate doubled. You are betting on a product that is being managed commercially, which cuts both ways: it improves, and the terms change under you. Mailchimp Transactional (Mandrill) Stable to the point of stasis. Mandrill works, has worked for years, and visible investment has been modest for a long stretch. A transactional sender that stopped changing is a transactional sender that stopped breaking, which is a real virtue. It is a poor bet if your plan depends on the surrounding tooling getting better. ### What each does with mail arriving at your domain Mailgun Routes are a rule engine: match expressions against recipient, sender and headers, ordered by priority, with actions attached, so one inbound domain can fan out to different destinations under different conditions. For anything where receiving mail is part of the product rather than a reply path, this is the stronger half of the pair by a wide margin. Mailchimp Transactional (Mandrill) Inbound routing forwards parsed messages to a webhook and has done so stably for a very long time. It covers reply handling and bounce parsing well, and it is forwarding rather than conditional fan-out. If your existing Mandrill inbound configuration is load-bearing, inventory it carefully before assuming any replacement is at parity. ### Addresses your provider has stopped mailing Mailgun Suppression lists cover bounces, complaints and unsubscribes, exposed through the API so you can audit and manage them programmatically. That programmatic access is the part that matters operationally: you can reconcile the vendor's view against your own database on a schedule rather than trusting a dashboard. Mailchimp Transactional (Mandrill) The rejection list is stricter than people expect. An address that hard-bounced once can remain on it indefinitely, so a customer who fixed their mailbox months ago silently receives nothing. Auditing that list is part of operating Mandrill competently, and it is the first thing to export if you ever leave. ### Checking an address before it becomes a bounce Mailgun Validation is a separate Mailgun product with its own API, backed by a very large sending operation's observation data, usable at signup time rather than only on an import. For a product acquiring addresses through forms, rejecting a typo at the point of entry is measurably better than discovering it as a hard bounce a week later. Mailchimp Transactional (Mandrill) There is no equivalent. Mandrill will tell you that an address bounced and will add it to the rejection list; it will not help you avoid sending to it in the first place. If list quality is your live problem, that is a real gap and it has to be filled with a separate service or with your own confirmation flow. ### How the templates are written and by whom Mailgun A handlebars-style templating syntax stored vendor-side and versioned there, aimed at developers. It is competent and it is not a design surface, so a marketer wanting to change a subject line is filing a ticket or learning the syntax. Mailchimp Transactional (Mandrill) Mailchimp's editor with merge tags, a syntax inherited from a marketing product. Convenient if your marketing team already lives in that editor, 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. There is no export path that carries these templates anywhere else. ### Finding a cohort of messages later Mailgun Tags and custom variables let you attach your own dimensions at send time and filter the event stream by them afterwards, which is how you answer a question about a campaign or a release rather than about one message. Log retention is a tier attribute and the entry plans are short, so check the number on the plan you are actually buying. Mailchimp Transactional (Mandrill) Outbound activity with content and delivery state, searchable within a retention window, adequate and visibly aged. A support person chasing one customer's missing receipt takes more steps than they should, and slicing by a dimension you defined is not really what the interface is for. ### How the money is counted Mailgun A named plan ladder with included volume and published overage, plus dedicated IPs included from the mid plans and extras at a monthly rate. It is easy to forecast, and since December 2025 the cheap pay-as-you-go entry point people remember is not available to new signups. Mailchimp Transactional (Mandrill) Blocks of messages bought at a time, plus a dedicated address as a monthly extra, plus the mandatory platform subscription underneath. Working out a true per-message cost requires arithmetic the pricing page does not do for you, and the honest number is materially higher than the block price suggests. ### What happens when an account is questioned Mailgun Suspensions recur in Mailgun's public reviews often enough to treat as a planning input. Large platforms are conservative about shared reputation and act first when a sending pattern looks unusual, which means spiky traffic deserves a warm fallback path and somebody who knows how to reach support. Mailchimp Transactional (Mandrill) The account relationship is shared with the marketing side, and that matters in the direction people do not expect: a problem originating in campaigns is a problem for the account your receipts depend on. Separating the two is not something you can arrange within the product, because the dependency is the product. ## Pros and cons, side by side ### Mailgun Strengths - Nothing else has to survive a renewal for your receipts to keep going out. The sending stands on its own invoice, and no colleague in another department can end it by cancelling a product that has nothing to do with email. - The credential arrives as a header on an authenticated request against a key scoped to one sending domain, so an over-enthusiastic log line leaks a request rather than the keys to an account. - Future delivery is a parameter on the send call rather than a subsystem, so a digest queued for a specific hour tomorrow is one field instead of a job runner somebody has to operate. - It is still being built. A capability you need in two years has some chance of arriving, which is a claim the other half of this pair cannot honestly make about itself. Trade-offs - Flex closed to new signups in December 2025 and the legacy per-thousand rate doubled, so the inexpensive entry point that every older recommendation rests on is not something you can sign up for. - Suspensions recur in its public reviews with the impersonality large platforms are known for, and bursty traffic is exactly the pattern that draws one. - A domain's region is fixed at creation and the API hostname changes with it, so a domain created hastily in the wrong one is a rebuild and a re-warm rather than a setting somebody corrects. - Ownership has changed more than once and the commercial decisions are taken at group level, so the terms you signed hold until somebody outside the product revises them. ### Mailchimp Transactional (Mandrill) Strengths - For a company already running campaigns on the parent platform, transactional arrives as a block of messages rather than as a new vendor, a new security review and a new invoice to defend. - It stopped changing years ago, and for something receipts depend on that is a virtue: no deprecation notices to track, no migration forced on you by somebody else's roadmap. - Inbound forwarding has behaved identically for a very long time, so an integration somebody wrote against it a decade ago still does what its author expected it to do. - Whoever already works in the marketing editor every day can change the wording of a transactional email without learning a second tool or being given a second licence. Trade-offs - It cannot be bought alone, and the plan underneath is priced on how many contacts the marketing side stores — so your transactional bill grows for reasons that have nothing to do with sending. - The API key travels inside the JSON body of every request rather than in a header, which means anything that captured a request payload for debugging has captured a credential. - The hourly ceiling is derived from a reputation score the platform calculates about you, so how much you may send changes without a plan change and without anybody telling you. - Links are rewritten through a hostname shared across the vendor's customers unless you publish a tracking record of your own, and almost nobody does until a corporate filter starts mangling them. ## Pick in thirty seconds ### Choose Mailgun if - You need conditional inbound routing rather than a single forwarding webhook. - Address validation at the point of signup would measurably improve your bounce rate. - You want to buy transactional sending on its own terms, with no other subscription required to make it work. - Slicing your own send dimensions out of the event stream is how your team answers questions about email. ### Choose Mailchimp Transactional (Mandrill) if - Marketing already runs campaigns in Mailchimp, so the platform subscription exists regardless and transactional is marginal cost. - The integration has run untouched for years, nothing is broken, and no one has funded a migration. - Your marketing team owns the templates and already works in that editor every day. - You would rather depend on a product that has stopped changing than on one whose terms were repriced last year. ## 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. Price the prerequisite against the marketing audience rather than against your message volume. The plan that makes the add-on purchasable is billed on how many contacts another team is storing, so a transactional forecast built from send counts is missing the half of the invoice that grows while you do nothing. Ask that team what their contact number is expected to do this year before you write anything down. 2. Get the credential out of the request body on the way in and out of your log store on the way out. Carrying an API key as a field inside every JSON payload means any proxy log, error report or request-capturing middleware you have ever enabled is holding one. Rotate on arrival, then search your logging platform for the old key rather than assuming the exposure ended when the account did. 3. Compare a reputation-derived hourly ceiling against a published plan allowance and decide which shape your traffic actually wants. One side raises and lowers what you may emit per hour according to a score it keeps about you; the other publishes an included volume and an overage rate you can read in advance. A three-in-the-morning batch behaves very differently under those two regimes. 4. Treat the inbound half as a change to the receiving domain's MX records rather than as an endpoint swap. Both sides want mail addressed to you arriving at their own hosts first, and if you receive on the apex that is the same record your staff's mail depends on. The defensible answer is usually a dedicated subdomain for machine-received mail, chosen now rather than after somebody's meeting invitations stop appearing. 5. Publish your own click-tracking host before the cutover instead of after it. A default that rewrites links through a hostname thousands of unrelated senders also use is the arrangement most likely to be rewritten again, stripped or blocked by a recipient's own filter. Leave the outgoing vendor's tracking record published until mail already sitting in inboxes has genuinely stopped being clicked. 6. Rebuild the templates and expect the conditionals to be the expensive half. Merge tags inherited from a campaign editor and a handlebars-style syntax evaluated on the vendor's side are not two spellings of one idea, and neither raises an error when a name fails to resolve — it renders nothing at all. Diff both outputs against real data per template rather than reading the two syntaxes side by side and assuming. 7. Rewrite the event consumer around a different transport as well as a different vocabulary. One posts a form-encoded field containing a JSON array, signed with a key you set per endpoint; the other posts its own payload signed over a timestamp and token pair. Parsing, signature checking and event naming are three separate pieces of new code, and the signature check is the one that gets postponed indefinitely. 8. Export the addresses each side has quietly stopped mailing and reconcile them by hand, because the two disagree about what a bounce means and for how long. One keeps hard bounces, complaints and manual blocks in a single collection that holds entries indefinitely; the other exposes each category through an API you can diff against your own records on a schedule. Load both into the destination before the first production send, then check the result against your own database rather than the dashboard. ## 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 the marketing side's contact count expected to do this year, and does anybody realise our transactional price moves with it? 2. Does anything in our logging or error reporting capture request bodies, and has anyone checked whether a sending credential is sitting in them today? 3. What is the largest burst we emit inside a single hour, and do we know what either provider would do with it unattended at three in the morning? 4. Do we receive mail on the same domain our staff use, and is anybody willing to change that domain's MX records for this? 5. Whose hostname is rewriting the links in our email right now, and has a customer ever reported one of them arriving broken? 6. If sending stopped tomorrow, is our fallback a second account we already hold, or a signup form we would start filling in that morning? 7. Are we choosing the product that will gain features or the one that will not change, and which of those two risks can this team actually absorb? ## Common questions ### Can I buy Mandrill without a Mailchimp plan? No. It is an add-on requiring an active paid Mailchimp plan, and that requirement ends more evaluations than any feature gap does. When you compare per-message costs, include the subscription underneath in the total. A transactional product that looks inexpensive per message can be the more expensive option overall once its prerequisite is counted, and the prerequisite does not go away at any volume. ### Which one is the safer long-term dependency? They fail differently, which is why there is no single answer. Mandrill's risk is stagnation: it keeps working and stops gaining, so a feature you need in two years may never arrive. Mailgun's risk is change: it gains features and it also reprices and changes hands, as December 2025 demonstrated. Pick based on which you can absorb. A team with no appetite for migration work should fear repricing; a team building something that will need more from its email vendor should fear stagnation. ### What is the hardest part of moving off either one? Inbound, if you use it, followed by templates. Outbound sending is a small code change and inbound is a re-architecture whenever you are moving between a rule engine and simple forwarding in either direction. Templates cross no paradigm boundary and must be rebuilt by hand. After that comes discovery: grep your infrastructure for the API credential rather than the vendor name, because the integration nobody remembers was configured by hand on a server rather than committed to a repository, and it will keep sending happily from an account you thought you had closed. ### Do either of these separate marketing from transactional mail? Not as a product concept the way message streams do elsewhere. On both, keeping a newsletter's reputation away from your password resets is something you arrange: a separate sending subdomain for bulk mail, separate credentials, and the discipline to keep them apart forever. It works and it depends on every future engineer understanding why the rule exists, which is a weaker guarantee than a vendor that refuses to let the two share. ### What should I export before leaving either? The suppression or rejection list first, because sending to previously bounced addresses from a brand-new identity is the fastest way to damage a reputation you have not yet built. Then templates, which nothing carries across. Then as much delivery history as the window still holds, since a dispute about last quarter will not wait for your migration. And on Mandrill specifically, decide what happens to the Mailchimp subscription — if transactional was the only reason it survived renewal, cancelling it is part of the saving and should be in the business case. ### Why does Mandrill want the API key inside the request body? Because the API was designed that way a long time ago and has not been redesigned since. Every call is a POST whose JSON payload carries a key field alongside the message, rather than an Authorization header the way a newer API would. Functionally it works; operationally it is a hazard, because the conventions that protect credentials have grown up around headers. Request-body logging is a default in several popular frameworks, error trackers attach payloads to exception reports, and a proxy configured to record traffic for debugging records the key with it. If you are staying, audit those three places and make sure none of them retains bodies. If you are leaving, rotate the key on the way out and then search your log store for the old one, because the exposure does not end when the account does. ### How does Mandrill decide how much I can send in an hour? It keeps a reputation score for your account and derives an hourly quota from it, which rises as you send clean mail and falls when bounces and complaints climb. The score is visible in the interface and the quota moves without a plan change, without a purchase and without a notification. The practical consequence is that capacity planning is not a matter of reading the pricing page: your ceiling this week is a function of your behaviour last week. A team whose traffic is even and whose list is clean rarely notices. A team that imports a stale list, or that emits everything in one overnight burst, can find the hour it needed most is the hour it was throttled in. Mailgun's arrangement is the opposite shape — a published plan allowance with a published overage rate — which is easier to forecast and does not reward you for behaving well. ### Do I need my own click-tracking domain? If you track clicks at all, yes, and it is one of the cheapest improvements available. By default both products can rewrite the links in your messages through a hostname the vendor owns and shares with everyone else using the feature. That shared host is what a recipient's security appliance sees, what a corporate filter scores, and what an end user sees if they hover over a link — so a link in your mail points somewhere that is visibly not you. Publishing a CNAME so links are rewritten through a subdomain of your own fixes the appearance and separates your reputation from the shared host's. The only real operational care is retirement: a tracking record pulled too early breaks every link inside mail already delivered, so leave the old one published until your longest-lived campaign has stopped generating clicks. ### Can both providers send from the same domain while I migrate? Yes, and running them in parallel is the sane way to do this. DKIM is not exclusive — each vendor publishes under its own selector, so two sets of keys coexist on one domain without either interfering with the other. The record to watch is SPF, which permits at most ten DNS lookups when it is evaluated, and adding a second provider's include while the first is still there is a common way to breach that limit quietly. Check the count before you publish rather than after, because an overflowing SPF record fails evaluation entirely rather than degrading, and the symptom is placement getting worse for both senders at once. Beyond DNS, the genuinely useful discipline is to split by traffic class rather than by percentage: move the mail nobody would miss first, keep receipts and password resets on the proven path, and leave both consumers running until you can prove nothing is still calling the old key.