# Mailgun vs SendGrid

Source: https://wraps.dev/versus/mailgun-vs-sendgrid

Two large, mature sending platforms, each owned by a bigger communications company. At volume the differences are procurement, marketing tooling and how each one handles an account it does not like.

Nobody picks between these two for the developer experience. They are the incumbents: both a decade old, both absorbed into larger communications companies, both capable of five hundred thousand messages a month without anyone thinking about it. The decision is procurement-shaped. What does the contract cover, what is sold separately, what does the free tier look like now, and what happens on the morning your account is paused. That last one is the question that should decide it and usually gets asked last.

## At a glance

|   | Mailgun | SendGrid |
| --- | --- | --- |
| What it is | High-volume email API with routing and validation | Twilio's email platform — API, SMTP, and marketing |
| 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. | Essentials $19.95 at 50K and $34.95 at 100K. Pro $89.95 at 100K, $249 at 300K, $499 at 700K. Dedicated IP is Pro and above; extra IPs $30/mo. Marketing Campaigns is priced as its own plan, not an add-on. |
| Best for | High-volume sending where routing, validation, and log search need to come from one vendor. | Enterprises wanting one procurement relationship, SMTP everywhere, and marketing in the same console. |
| 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 free tier died on 27 May 2025, replaced by a 60-day trial at 100/day. Support latency and abrupt account suspensions dominate 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

### Who owns them, and where you can see it

Mailgun

Mailgun sits inside a larger communications group, and the visible effect is roadmap gravity: the sending product is stable and well-maintained rather than fast-moving, and it is increasingly presented alongside sibling messaging products. That is fine if you want a durable supplier. It is less good if you were hoping for the pace of a company whose only product this is.

SendGrid

SendGrid is Twilio's email arm, and it is a genuinely different experience depending on which door you come through. A self-serve account gets a mature but crowded console; an account attached to a Twilio enterprise agreement gets account management, consolidated billing across SMS and voice, and procurement leverage. If your company already buys Twilio, that is most of the argument.

### How the volume ladders are shaped

Mailgun

Mailgun's ladder has a low entry plan and then two parallel families above it, where the higher one buys throughput, retention and support rather than a lower unit rate. The jump that catches people is the one in the middle, where a dedicated IP becomes included — that is the step where the effective per-message cost changes direction rather than continuing to fall.

SendGrid

SendGrid's ladder is the more granular of the two, with distinct price points running well past half a million a month on the higher tier. The trap is different: Marketing Campaigns is priced as its own plan, not as an add-on to your sending plan, so the number you compared against Mailgun covers less surface than you assumed if you also send campaigns.

### Marketing tooling: included, or a second purchase

Mailgun

Mailgun keeps campaign tooling thin and sells the marketing product separately in the group's portfolio. In practice most Mailgun customers are sending application mail and running marketing somewhere else entirely, which is a cleaner architecture than it sounds, because the suppression and reputation concerns of the two traffic types genuinely differ.

SendGrid

SendGrid's whole positioning is one console for both, and the console does exist — a designer, a contact database, automations. But it is a separate plan on a separate meter, so the consolidation is in the vendor relationship and the login, not in the invoice. Teams that chose SendGrid specifically to avoid a second marketing tool often end up with two SendGrid plans instead.

### SMTP as a first-class path

Mailgun

Mailgun's SMTP relay is solid and widely used for appliances, legacy applications and anything that already speaks SMTP and is never going to be rewritten. Credentials per domain, sensible defaults, and the same logs as the API path. If half your sending comes from software you did not write, this matters more than any SDK.

SendGrid

SendGrid's SMTP relay is the most widely deployed of any vendor here, which is a real advantage for an unglamorous reason: whatever obscure appliance or CMS plugin you need to configure, someone has already written the instructions for pointing it at SendGrid. Compatibility that broad is not a feature anyone designs, it accumulates.

### Dedicated IPs and warm-up

Mailgun

Mailgun includes a dedicated IP from its mid plans and charges monthly for additional ones, so a multi-brand sender can isolate per brand without an enterprise conversation. Warm-up is your responsibility, with the usual consequence that a new IP pushed hard on day one performs worse than the shared pool would have.

SendGrid

SendGrid reserves dedicated IPs for its upper tier and charges monthly for extras. It does provide automated warm-up, which is a meaningful difference for a team that has never warmed an IP before and does not want to learn on production traffic. The catch is the plan floor: you are buying the tier to get the IP, whether or not you needed the rest of the tier.

### The free tier, and what replaced it

Mailgun

Mailgun's free allowance is a hard hundred a day. That is a demo. It is not a staging environment, and a CI pipeline that sends verification mail on every pull request will exhaust it before lunch. Plan on paying for a non-production account or on a separate test-capture tool.

SendGrid

SendGrid's free tier ended on 27 May 2025 and was replaced by a sixty-day trial capped at a hundred a day. The practical effect on an architecture decision is that neither vendor now offers a durable free environment, so any comparison that treats one of them as the free option is working from stale information.

### Support latency, and the suspension pattern

Mailgun

The complaint that recurs about Mailgun is response time on the lower plans, and account actions that arrive with less context than the sender expected. It is a shared-reputation platform operating at scale, and the enforcement is automated before it is human.

SendGrid

The complaint that recurs about SendGrid is the same one, with more volume behind it: support latency and abrupt suspensions dominate its public reviews. If your traffic is spiky, or your content is in a category compliance teams look at twice, this is not a tiebreaker consideration. It is the consideration, and it applies to both.

## Pros and cons, side by side

### Mailgun

Strengths

-   Inbound Routes and address validation are both first-party, so the two capabilities a sending platform usually leaves to somebody else arrive inside the relationship you are already buying.
-   A dedicated address is included from the middle plans rather than reserved for the top of the ladder, which lets a multi-brand sender isolate per brand without an enterprise conversation first.
-   Log search shows the receiving server's SMTP response on the relay path as well as the API path, so an appliance nobody owns is as debuggable as code somebody wrote.
-   Marketing stays deliberately out of the way, which keeps the sending account's purpose unambiguous and its suppression semantics about one kind of traffic.

Trade-offs

-   Flex closed to new signups in December 2025 and the legacy pay-as-you-go rate doubled, so any cost model assembled from remembered numbers is wrong by a factor that changes the decision.
-   The free allowance is a hard hundred a day, which is a demo rather than a staging environment and will not survive a CI pipeline that sends verification mail per pull request.
-   Response time on the lower plans is the complaint that recurs, and account actions tend to arrive carrying less explanation than the sender expected.
-   Roadmap gravity follows the parent group's portfolio, so the product is durable and slow rather than responsive to anything you might ask for.

### SendGrid

Strengths

-   The broadest relay compatibility surface in the category, which matters precisely at the moment the sender is a system nobody is allowed to rewrite and nobody wants to own.
-   Automated IP warm-up, which is a genuine difference for a team that has never warmed an address and would rather not learn the schedule on production traffic.
-   A Twilio relationship consolidates email alongside SMS and voice under one agreement, which is procurement leverage rather than a product feature and is often the whole argument.
-   Subusers give per-tenant credentials, reputation and reporting, which is the structural answer for anybody sending on behalf of customers rather than only for themselves.

Trade-offs

-   The free tier ended in May 2025 and became a sixty-day trial at the same daily cap, so neither vendor in this pair now offers anything a staging environment could live on.
-   Marketing Campaigns runs on its own plan and its own meter, so a quote compared against the other side covers less product than it appears to and the gap only shows up at renewal.
-   Dedicated addresses are reserved for the upper tier, so you buy the tier to reach the address whether or not anything else in that tier was wanted.
-   Support latency and abrupt suspension dominate its public reviews with more volume behind them than any other vendor in this comparison, which is a planning input rather than a rumour.

## Pick in thirty seconds

### Choose Mailgun if

-   You want routing, validation and log search from the same vendor as your outbound, and you are not buying marketing tooling from them.
-   You need dedicated IPs per brand without stepping up to an enterprise tier to get them.
-   Your traffic is application mail with a long tail of SMTP senders, and per-message cost at volume is the number being optimised.
-   You would rather have a stable, slow-moving supplier than a fast-moving one.
-   Tag-based reporting across several traffic types inside one account is how your analytics are already structured.

### Choose SendGrid if

-   Your company already has a Twilio relationship, and consolidating email into it buys real procurement leverage.
-   You need an unusually wide compatibility surface — odd appliances, legacy CMS plugins, vendors who only know how to configure one relay.
-   You want automated IP warm-up rather than running the schedule yourself.
-   Marketing and transactional genuinely need to be in one console and you have budgeted for both plans, not one.

## 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 entire surface on both sides before writing a number down, because the plan page is not the invoice. Campaign tooling is a separate meter on one side and largely absent on the other, additional dedicated addresses are monthly on both, and the two quotes being compared routinely cover different amounts of product.
2.  Inventory the SMTP senders first, because they are the long pole on a migration between two incumbents. Application code is a configuration change; an appliance, a CMS plugin or a partner system that only knows how to be pointed at one relay is a ticket on somebody else's calendar, and there are always more of them than the first count found.
3.  Map subusers onto subaccounts, or establish early that you cannot. Per-tenant credentials, reputation and reporting are structured differently on the two sides, and an agency or platform leaning on that isolation needs to confirm the destination's equivalent before anything else in the plan matters.
4.  Export suppression state from every construct that holds it. Unsubscribe groups, bounces, spam reports and blocks are separate collections rather than one list, and a migration that imports the unsubscribes and forgets the complaints produces a complaint rate on an identity with no history to absorb it.
5.  Re-implement the templates rather than exporting them. Both vendors evaluate their own substitution syntax on their own side, so the HTML is portable and the logic is not. Teams that use the occasion to move rendering into the application make the migration after this one a code change instead of a project.
6.  Rewrite the event consumer and then re-derive everything downstream of it. Payload shapes, event names and batching behaviour all differ, so every dashboard, alert and finance report built on the old vocabulary is quietly wrong until somebody has re-derived it against the new one.
7.  Reproduce inbound deliberately if you use it. Routes on one side and Inbound Parse on the other are similar in intent and different in matching syntax, in what arrives at your endpoint and in how a failure surfaces, so treat it as a re-implementation with its own test plan rather than as a change of hostname.
8.  Plan the reputation ramp as a quarter rather than a sprint. The dedicated IP does not travel and neither does its warm-up, so the standard approach is both vendors running in parallel with a percentage of traffic shifting weekly — which means two invoices for a while, and that number belongs in the business case rather than in a surprise.

## 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 the quote in front of us include campaign tooling, or is that a second plan on a second meter that nobody folded into the comparison?
2.  How many of our senders are systems we cannot modify, and has somebody enumerated them rather than estimated from memory?
3.  Which tier do we have to buy to get a dedicated address, and do we actually want the rest of what that tier contains?
4.  Do we need per-tenant isolation, and does the destination structure it the way the thing we depend on today is structured?
5.  What response commitment comes with the plan we are buying, and what comes with the one above it — because that difference is what a bad day costs?
6.  How spiky is our traffic, and has anybody considered what that pattern looks like to an enforcement system that acts before a human reads anything?
7.  How many weeks of paying both vendors are in the budget, and who signs off when the ramp takes longer than the plan said?

## A third shape of answer

Both of these send from their own infrastructure, on shared reputation they manage, and both are well represented in public reviews by people whose accounts stopped without much warning. That specific risk is structural rather than a service-quality problem: when the sending identity belongs to the vendor, an enforcement decision about someone else's traffic can reach yours. The other shape is to send through SES in an AWS account you own, where the identity, the reputation and the enforcement relationship are yours. Wraps builds that out and runs the platform layer on top. It is not a free lunch: SES production access is an AWS approval that takes anywhere from an hour to three days, and it is not ours to grant.

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

### Which is cheaper at half a million emails a month?

Close enough that it should not decide the question, and both have repriced recently enough that any figure you remember is suspect. Price the exact volume on both current plan pages, then add the things sold separately — marketing campaigns on one side, additional dedicated IPs on either — because that second list is usually where the real difference between the two quotes appears.

### Do either of them still have a usable free tier?

No. SendGrid's free tier ended in May 2025 and became a sixty-day trial at a hundred a day; Mailgun's free allowance is a hard hundred a day. Neither is a staging environment. If you need one, budget for a paid non-production account or route test traffic to a capture tool instead of a real sender.

### How likely is a suspension, really?

Unlikely if you send consistent volume to addresses that opted in, and materially more likely if your volume is spiky, your list was imported, or your content sits in a category that gets extra scrutiny. Both vendors enforce automatically before a human reads anything. The mitigation is the same on either: warm gradually, watch your complaint rate, and never send marketing from your transactional domain.

### Can I keep my dedicated IP when I move between them?

No. The IP belongs to the vendor, not to you, and so does the reputation it accumulated. A migration means warming a new address from scratch, which is weeks of gradually increasing volume, not a switch you flip. This is the single most underestimated cost of changing sending platforms at volume.

### Is one better for high-volume marketing sends?

SendGrid has the more complete campaign product, but it is a separate plan, so compare it against a dedicated marketing platform rather than against Mailgun. Mailgun's answer is that marketing belongs in a different tool, which is an architecturally cleaner position and one more vendor. Neither product is where a marketing team would choose to work if the choice were theirs.

### How long does an enterprise migration between these take?

Plan a quarter, not a sprint, and expect the calendar to be driven by reputation rather than by code. The engineering is a few weeks: rewrite the send path, re-point webhooks, re-verify domains, import suppressions. Then comes the part nobody can compress, which is ramping volume on new infrastructure while watching complaint and bounce rates at each step. Running both vendors in parallel and shifting a percentage of traffic weekly is the standard approach, and it means paying two bills for a while. Budget for that overlap explicitly or it will arrive as a surprise.

### How do Mailgun Routes and SendGrid Inbound Parse compare?

They answer the same question differently. Routes use an expression syntax matching on recipient, sender or header, and can forward to a URL, an address or storage. Inbound Parse binds a hostname you point MX records at and posts the parsed message to one endpoint. Routes are the more expressive of the two and Inbound Parse is the simpler to set up. Neither maps onto the other mechanically, so treat a move between them as a small re-implementation with its own tests rather than as a configuration change.

### Does Mailgun have an equivalent to SendGrid subusers?

It has subaccounts, which serve the same purpose — isolating one customer's sending, suppression and reporting from another's underneath one parent — and they are structured differently enough that a migration is a modelling exercise rather than a mapping. The questions to settle before committing are whether reputation is genuinely isolated per tenant or only reporting is, how credentials are scoped, and whether a parent-level view exists across all of them. Get those three answers in writing, because an agency's whole operating model sits on top of them.

### Can we keep our category and tag reporting across a move?

The mechanism survives and the reports do not. Both vendors let you attach a label to a message and slice delivery statistics by it, so the dimension you have been analysing by continues to exist. What does not continue is the aggregation: the console's charts, the saved views and any historical series behind them stay with the vendor you left, so year-on-year comparisons acquire a seam at the migration date. Snapshot whatever anybody cites regularly before the account closes, and rebuild the dashboard as part of the project rather than after it.
