This is breadth against focus. Mailgun wants to be the whole email surface of your application: outbound, inbound routing, address validation, searchable logs, all on one contract. Postmark wants to put transactional mail in the inbox and has spent years declining to become anything else. Teams cross-shop them because both answer a question phrased as we need a reliable email API, and then discover halfway through the trial that they were asking two different questions.
At a glance
| Mailgun | Postmark | |
|---|---|---|
| What it is | High-volume email API with routing and validation | Transactional email API, deliverability-first |
| 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. | Basic $15, Pro $16.50, Platform $18 per month — each including 10,000 emails. Overage runs $1.80, $1.30, and $1.20 per 1,000 respectively. Dedicated IP $50/mo on Pro and above, 300K/mo minimum. |
| Best for | High-volume sending where routing, validation, and log search need to come from one vendor. | Transactional email where inbox placement matters more than unit price. |
| 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. | The economics invert at volume — roughly $630 at 500K/mo against $50 of raw SES. Marketing tooling is deliberately thin, and the early-2026 repricing means long-standing accounts are not on these numbers. |
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
How wide the product is
Mailgun
Mailgun is an email platform in the fullest sense. Outbound sending is one surface among several: inbound routing with rule expressions, address validation, log retention and search, templates, and a reporting layer over the lot. The breadth is the pitch — one vendor, one invoice, one support relationship for everything email-shaped your application does.
Postmark
Postmark has a narrow perimeter and defends it. Transactional sending, message streams, activity search, templates, inbound parsing, webhooks. There is no validation service, no routing rule engine, no campaign tooling. When Postmark declines a feature request it is usually because the feature would compromise the deliverability posture the rest of the product is built around.
Inbound mail and routing
Mailgun
Mailgun's routing engine is a first-class product with match expressions, priorities and multiple actions per rule, which is why it shows up in support-desk and ticketing architectures. If your application needs to receive mail, parse it, fan it out to more than one destination and do that conditionally, this is the more capable of the two by a wide margin.
Postmark
Postmark's inbound is a parsing endpoint rather than a routing engine. Mail arrives at an address, gets parsed into structured JSON and is posted to your webhook. That is enough for reply-by-email on a support thread and it is not enough for conditional fan-out. Postmark expects the routing logic to live in your code, which is a defensible position and also more code.
The December 2025 repricing, and who it hurt
Mailgun
Mailgun's Flex plan closed to new signups in December 2025 and the legacy pay-as-you-go rate doubled. That is the single most important recent fact about Mailgun's pricing, because the low per-thousand rate people remember from years of blog posts is no longer available to a new account. The free tier that remains is a hard hundred a day, which is a demo, not a staging environment.
Postmark
Postmark repriced in early 2026 as well, and the practical consequence is the opposite one: long-standing accounts are not on the published numbers, so a recommendation from a colleague who has been a customer since 2021 is describing a contract you cannot buy. Check the current plan page rather than trusting a price you were told secondhand.
Dedicated IPs and when you can have one
Mailgun
Mailgun includes a dedicated IP from its mid plans upward, with additional IPs charged monthly. That threshold is low enough that a mid-sized sender can get isolation without negotiating, which matters if you send for multiple brands or want to warm an IP on your own schedule rather than sharing a pool's history.
Postmark
Postmark gates dedicated IPs behind its upper plans and attaches a monthly volume minimum, on the reasonable grounds that a badly warmed dedicated IP below that volume performs worse than their shared pool. It is honest advice and it is also a wall: a sender below the minimum with a reputation problem has no isolation available at any price.
Address validation
Mailgun
Mailgun sells list validation as part of the platform, which is an unusually direct answer to the most common cause of a bounce rate problem. Being able to screen an imported list before the first send, inside the same vendor that will suspend you for bouncing it, removes a whole category of self-inflicted incident.
Postmark
Postmark does not offer validation and its position is that you should not need it, because you should not be importing lists you did not collect. That posture is consistent with everything else about the product and it is unhelpful the day you inherit a list from an acquisition. You buy validation elsewhere or you clean it by hand.
Debugging a specific message
Mailgun
Mailgun's logs are searchable and retained according to plan, and the search is built for volume — filter by event type, recipient, tag, time window. At high throughput that is the right shape of tool. It is also a log viewer rather than a support tool: you are reading events, not reading the email your customer read.
Postmark
Postmark's activity view shows the rendered message itself alongside the delivery path and the raw bounce text. For a support agent chasing one customer's missing receipt, that is a materially better experience than filtering an event log, and it is the difference people mean when they say Postmark feels more finished at small scale.
Reputation of the support relationship
Mailgun
Mailgun is part of a larger communications group, and the pattern in its public reviews is the one that usually follows: capable platform, slower support, and account suspensions that arrive with less explanation than the sender thinks the situation warranted. Budget for that if your sending is spiky or your content is unusual.
Postmark
Postmark's support is the thing customers volunteer without being asked, and it is a real part of what the higher per-message price buys. The trade is that the same team will also tell you no, firmly, about content and list practices that another vendor would have let through until it became a deliverability problem.
Tagging, and finding a cohort of messages later
Mailgun
Mailgun lets you tag outbound messages and then slice reporting by tag, which is how teams separate receipts from digests from notifications inside one account without spinning up separate domains. It is a small feature that quietly determines whether your analytics are usable at volume, and it is better developed here than on most of the field.
Postmark
Postmark's equivalent is the message stream plus a tag on the message, and streams are the stronger of the two concepts because they carry reputation separation rather than only reporting. The consequence is a nudge toward modelling your traffic types properly up front, which is more work on day one and much less work the first time one category of mail starts bouncing.
Pros and cons, side by side
Mailgun
Strengths
- Routing is a genuine rules engine with match expressions, priorities and several actions per rule, which is why it keeps turning up inside ticketing and support-desk architectures.
- List validation comes from the same vendor that will later form an opinion about your bounce rate, so an inherited list can be screened before it becomes an incident.
- Credentials, suppressions, routes and tracking settings all hang off a sending domain, which is a clean boundary for a company operating several brands out of one account.
- Log search is built for throughput — filter by event, recipient, tag and window — which is the correct shape of tool once nobody is reading messages one at a time any more.
Trade-offs
- Flex closed to new signups in December 2025 and the legacy rate then doubled, so the cheapness this product is remembered for is not something a new account can buy.
- The free allowance is a hard hundred a day, which is a demonstration rather than an environment, and it disappears halfway through the first seeded test run.
- The pattern across public reviews is act first and explain afterwards, which belongs in the plan if your sending is spiky or your content is unusual in any way.
- What you get is an event log rather than a support tool: you are reading states and timestamps, never the email your customer actually opened.
Postmark
Strengths
- Streams make the split between bulk and transactional standing a product concept, so a newsletter cannot spend the reputation a login code is relying on.
- The activity view carries the rendered message, the delivery path and the verbatim rejection text, so a support agent ends the conversation instead of escalating it to an engineer.
- A Server is a real boundary with its own token, its own settings and its own streams, so a second brand or a second environment is an object rather than a naming convention.
- Inbound mail arrives already parsed into structured fields, which turns reply handling into application logic instead of a MIME project nobody volunteered for.
Trade-offs
- There is no validation and the stated position is that you should not need any, which is coherent right up to the afternoon you inherit a list from an acquisition.
- Inbound is a parsing endpoint rather than a routing engine — one destination, no conditional fan-out — so the matching logic becomes code you write and maintain.
- Dedicated addresses sit behind the upper plans with a monthly volume floor attached, so a small sender with a placement problem has nothing available to purchase.
- The rate card is the steeper of the two past a few hundred thousand a month, and an account opened years ago is not on the numbers a new one gets quoted.
Pick in thirty seconds
Choose Mailgun if
- Your application receives mail as well as sending it, and the receiving side needs conditional routing rather than one webhook.
- You are importing or inheriting lists and want validation from the same vendor that will judge your bounce rate.
- Volume is high enough that per-message price dominates the decision and log search at scale matters more than log presentation.
- You want a dedicated IP without negotiating a plan upgrade you do not otherwise need.
Choose Postmark if
- Transactional mail arriving in the inbox is the requirement, and you are willing to pay a higher unit price to stop thinking about it.
- Your support team debugs individual messages often enough that seeing the rendered email beats filtering an event stream.
- You send marketing as well, and you want the product to keep those streams apart rather than trusting a convention.
- Your volume is modest and the included allowance covers it, which is where Postmark's pricing is at its most competitive.
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.
- Redraw the account layout first, because these two organise around different nouns. Credentials, suppressions, routes and tracking settings hang off a sending domain on one side; on the other they hang off a Server, with standing separated again by stream inside it. Neither maps onto the other cleanly, so sketch the destination's object graph before exporting anything — an account that grew one domain at a time usually turns out to want fewer Servers and more streams.
- Reduce the tagging scheme to what survives the crossing. One side accepts several tags on a message and lets you slice reporting across them; the other takes a single tag plus a small metadata map returned on the webhook. Any report that groups by two tags at once has to be re-expressed, and the real choice is between picking the one dimension that matters and pushing the rest into metadata to aggregate yourself downstream.
- Export suppression from every domain rather than from the busiest one. Bounces, unsubscribes and complaints are three separate lists kept per domain, so an account with six sending domains has eighteen exports to do, not three. On arrival they are re-scoped again by stream, and an address that belonged on a broadcast list must not end up silently blocking a receipt.
- Replace the routing rules with software and say plainly that it is a replacement. Match expressions with priorities and several actions per rule collapse into one parsed payload arriving at one endpoint, with every routing decision moved into your application. That is a defensible design and it is also a program somebody now owns, with tests, in a repository, on a rota.
- Have the awkward conversation about where your addresses came from. The destination's stated position is that validation is unnecessary because you should not be importing lists you did not collect, and its support team will say exactly that. If part of your list arrived through an acquisition or a partner feed, decide now whether you are cleaning it somewhere else first or whether you intend to become a difficult customer in month one.
- Re-author the templates and take the layout concept seriously rather than porting file by file. Substitution evaluated on one side becomes layouts plus templates on the other, where a layout wraps every message in a stream and a template drops into it. Teams that migrate template by template end up with the header duplicated forty times and rediscover what layouts were for the first time legal rewrites the footer.
- Split the credentials before the cutover, not after, because the token models differ in scope. One issues a key per sending domain; the other issues a token per Server, with a separate account-level token for domain and sender administration. A deployment holding a single key for everything needs unpicking first, and the administrative token is the one that ends up pasted into a script it should never have been near.
- Model the invoice at the volume you expect rather than the volume you have, because these curves cross. Per-message pricing on one side and plan-plus-overage on the other meet somewhere in the low hundreds of thousands a month, and a migration justified on this year's spend can be the more expensive answer by the time it finishes. Find your crossover point and write the number down where the next person will see 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.
- How many sending domains do we run today, and would each of them want its own Server or merely its own stream?
- Does any report anybody actually looks at group messages by more than one tag at the same time?
- What does our inbound path do beyond delivering one message to one endpoint, and who would own that logic afterwards?
- Where did the addresses on our list come from, and can we say that out loud to a vendor's compliance team?
- At roughly what monthly volume do the two pricing curves cross for us, and where will we be in eighteen months?
- Does anyone hold a single credential that reaches every domain we send from, and what breaks when it is rotated?
- When support is asked whether one customer received one specific message, what do they actually do today?
Common questions
Is Mailgun still the cheap option?
Not for a new account. The reputation for cheapness comes from the Flex pay-as-you-go plan, which closed to new signups in December 2025, and from a legacy rate that has since doubled. Compare the current plan pages rather than a blog post from 2023 — on the plans you can actually buy today the gap between these two is much narrower than the folklore suggests.
Can I run both, transactional on one and bulk on the other?
Yes, and splitting by traffic type across two vendors is a reasonable architecture. Be deliberate about domains: use a subdomain per sender so reputation, DMARC alignment and DKIM keys stay separable. The cost is that you now have two suppression lists, two sets of webhooks and two dashboards, and nobody reconciles them until something has already gone wrong.
Which one is better for inbound email parsing?
Mailgun, clearly, if you need routing decisions made before the mail reaches your code. Postmark parses inbound mail into structured JSON and posts it to a single webhook, which covers reply-by-email on a thread. Anything involving several destinations, conditional matching or priorities is a rules engine, and only one of these two has one.
Does either of them suspend accounts without warning?
Both can, and both do, because shared sending reputation means one customer's bad list is everyone's problem. The difference reported in public reviews is tone and speed: Postmark tends to open a conversation, Mailgun tends to act first. Neither is safe from it, and the only real mitigation on either platform is not to give them a reason.
What does migrating between them actually involve?
Re-verifying domains and rotating DKIM keys, rewriting the send calls, re-pointing webhooks at a different event shape, and importing your suppression list so you do not immediately re-mail addresses that already bounced. The last one is the step teams forget, and it is the one that starts the new account off with a bounce rate that looks like a bad sender.
Do I need a dedicated IP at all?
Below a few hundred thousand messages a month, usually not, and taking one early makes things worse rather than better. A dedicated IP has no reputation of its own on day one, so you inherit nothing and have to warm it by ramping volume over weeks. A well-run shared pool will outperform a cold dedicated IP for months. The cases where you genuinely want one are consistent high volume, sending on behalf of several distinct brands, or a compliance requirement that names it. Otherwise the money is better spent on list hygiene.
How do Servers and streams map onto our sending domains?
They do not map, and trying to force a one-to-one correspondence is the most common way this migration produces a mess. A sending domain is where credentials, suppressions and settings live on one side. A Server is where the token and the settings live on the other, and a stream inside it is where reputation is separated. So a company with three brands and both transactional and marketing traffic is probably looking at three Servers with two streams each, rather than six of anything. Draw the destination before you export, because reorganising after reputation has accumulated is considerably more annoying than getting it right on a whiteboard.
What happens to our tags and custom variables?
They compress, and you should decide how rather than discovering it. Several tags per message plus arbitrary custom variables surfaced on the webhook is a richer scheme than a single tag plus a small metadata map, so anything that currently groups by two tags at once needs re-expressing. The two workable answers are to nominate the one dimension your reporting genuinely turns on and make that the tag, or to keep a minimal tag and push the rest of the structure into metadata that you aggregate in your own warehouse. What does not work is assuming the reports will look the same afterwards, because somebody will notice in the first month that a familiar number is missing.
At what volume does the cheaper option flip?
Somewhere in the low hundreds of thousands of messages a month, and the exact point depends on which plans each vendor will actually sell you today rather than on the folklore. The shape is consistent though: an included allowance with capability-graded tiers is competitive at modest volume and steepens above it, while per-message pricing with a low unit rate wins at scale and has less to offer a small sender. Model your projected volume rather than your current one. A migration justified on this year's invoice that finishes after the crossover has been paid for twice and saved nothing.