Mailgun Migration Service

Mailgun built a loyal developer following on a clean API and pay-as-you-go simplicity, and that same pay-as-you-go model is now a big reason teams are leaving. The per-email price scales straight up with volume, the entry-tier logs vanish after a few days, the useful extras are add-ons, and Microsoft-inbox placement and account stability draw recurring complaints. Migrating off it is appealing — but, as with any infrastructure move, doing it carelessly trades a billing annoyance for a deliverability crash. This page is about why senders leave Mailgun, whether you should, and how to move onto controlled Canadian infrastructure without losing the inbox.

Why are senders leaving Mailgun?

The departures cluster around cost structure and a handful of operational frictions. The biggest is the pricing model: Mailgun charges per email, so your bill grows linearly with volume, and the pay-as-you-go Flex rate roughly doubled to about $2 per 1,000 emails in late 2025 — which pushed many teams that started on Mailgun for its simplicity to start comparing. Dedicated IPs are gated to higher tiers at around $59 per IP per month, and email validation is metered separately, so the real bill carries line items beyond the headline. Operationally, three complaints recur: log retention is only about 5 days on entry tiers, which is painful when a delivery problem takes longer than that to diagnose; deliverability to Microsoft inboxes is weaker than senders want; and the anti-abuse posture sometimes flags or suspends legitimate bulk senders with little warning, costing revenue mid-campaign. Sinch’s ownership and a slower feature pace since the acquisition complete the picture. The pattern is consistent: senders leave over per-email economics, short logs, add-on costs, Microsoft placement, and account stability — not over the API being bad. The per-email shape matters most at scale: a program sending into the millions per month pays a bill that rises with every send, where flat infrastructure does not — which is why the senders most motivated to leave tend to be the higher-volume ones rather than the small projects Mailgun originally won over.

Is Mailgun actually the problem?

It is worth being fair, because an honest migration decision depends on it: Mailgun is a capable product. The API is genuinely good, the documentation is thorough, and features like inbound email routing and the large-scale validation API are real differentiators that most competitors do not bundle — it processes hundreds of billions of emails a year and is a defensible choice at mid-scale. The frustrations that drive migrations are about per-email pricing that scales linearly, short log retention, metered add-ons, Microsoft-inbox placement, and occasional account-stability surprises — real problems, but not a failing platform. So leaving Mailgun is usually an economics-and-control decision, not an escape from disaster. If the pricing fits your volume and none of those frictions hurt you, staying is reasonable. The case to migrate is strongest when your volume makes per-email pricing expensive, when 5-day logs cannot cover your debugging, when add-on costs accumulate, or when you want owned IPs and a chosen jurisdiction instead of a shared pool on a multinational platform. Migrating for the wrong reason just swaps one set of trade-offs for another.

What carries over from Mailgun, and what doesn’t

The reputation split decides the pacing, and it is the same everywhere. Your domain reputation carries over — it is tied to your sending domain, so the trust your domain has built travels with you. Mailgun’s IP reputation does not carry over: if you were on shared IPs, that reputation belonged to the pool, not to you, and even a Mailgun dedicated IP stays with Mailgun. Moving to your own dedicated IPs means warming from zero — which is the start of reputation that is yours alone, isolated from other senders’ behaviour. The practical consequence is the familiar one: the new IPs must be warmed gradually, and the move has to be parallel rather than instant. There is one Mailgun-specific item to plan around: if you use the validation API or inbound routing, those are not reputation but functionality, and they need an explicit migration plan rather than being assumed to come across. Knowing exactly what moves and what is rebuilt is what keeps the timeline realistic.

How the migration actually runs

Migrating off Mailgun follows the same disciplined pattern as any infrastructure migration, and the discipline is what protects your inbox. You keep Mailgun live throughout — it is your fallback, not something to cancel on day one. You stand up the new Canadian infrastructure with SPF, DKIM and DMARC configured and verified before a single send, holding DMARC at p=none through the transition. You export your suppression data from Mailgun — every unsubscribe, bounce and complaint — and load it first, so opt-outs survive. Then you warm the new dedicated IPs on a proper ramp, starting with your most engaged recipients at low volume, shifting traffic from Mailgun to the new infrastructure gradually over two to four weeks while watching reputation on both sides. Only once the new infrastructure is stable do you decommission Mailgun. Rushing any of this is the single most common cause of a post-migration crash, which is why the service is built around pacing rather than speed.

The technical switch versus the deliverability migration

Two things get bundled together, and separating them clarifies the work. The integration change — swapping your application from Mailgun’s API or SMTP to the new infrastructure — is usually modest, because Mailgun uses a RESTful API, SMTP relay, and webhooks, and the destination offers the same primitives; in practice it means changing keys and endpoints or re-pointing SMTP, then reconciling webhook schemas and template differences, which is measured in days, and SMTP-only senders have it easiest. Mailgun’s distinctive features need explicit handling: if you use inbound routing to process replies, that maps to your own routing; if you use the validation API, that becomes a separate verification step. The deliverability migration is the longer, more delicate side — exporting suppression, re-publishing authentication, holding DMARC steady, warming new IPs over weeks. The mistake is treating the whole migration as just the integration swap, finishing the easy part fast, then crashing because the deliverability side was never paced. We run both deliberately, so the quick switch does not turn into a slow incident.

What dedicated Canadian infrastructure changes

Moving from Mailgun’s per-email model to dedicated Canadian infrastructure changes four things. First, cost shape: you pay a flat infrastructure cost rather than a per-email rate that scales linearly, so at sustained high volume the bill stops climbing with every send — the exact pain that drives many Mailgun departures. Second, reputation control: on dedicated IPs your sender reputation is yours alone, with no shared-pool variability and no separate add-on fee to get a dedicated IP. Third, observability: full log retention rather than a 5-day window, so a delivery issue that surfaces across a billing cycle is still debuggable. Fourth, jurisdiction: because the infrastructure is Canadian, your email data resides in Canada under Canadian law — PIPEDA residency, outside US-style data-access reach — which a US-rooted multinational platform structurally cannot offer. The honest trade-off is that dedicated infrastructure needs warming and steady volume to stay warm, so a small or sporadic sender genuinely better served by a shared pool should not move. For a steady, growing sender, it is a real upgrade rather than a lateral one.

How we run your Mailgun migration

With MCSNET, your move off Mailgun is run as the parallel project it should be, onto dedicated Canadian infrastructure in Toronto. We start by auditing what you actually use on Mailgun — API, SMTP, webhooks, inbound routing, validation, suppression — so nothing is silently lost, especially the inbound and validation features that need rebuilding rather than copying. We stand up your new dedicated IPs with authentication configured and verified, export and load your Mailgun suppression so opt-outs persist, and keep Mailgun running as your live fallback. We warm the new IPs starting with your most engaged recipients, shift traffic gradually while watching reputation on both platforms, and decommission Mailgun only once the new infrastructure is proven. We handle the integration cutover and the deliverability migration together, so the technical switch and the warming stay coordinated. And because the destination is Canadian, you finish on infrastructure with flat cost, owned reputation, full log retention, and PIPEDA residency — the things the move was for. We will tell you honestly if Mailgun is the better fit for your volume; if it is not, this is how you leave it cleanly.

# mailgun migration · pre-move audit · brand.ca
integration   api / smtp relay / webhooks  mapped
inbound       routing rules → rebuild on new infra
validation    metered api → separate verify step
suppression   export unsubs + bounces + complaints  load first
auth          spf include + dkim keys before send
new ips       dedicated · canadian · warm from zero
logs          full retention vs mailgun 5-day window
cutover       gradual 2–4wk · mailgun live until stable

Why work with us?

Because we treat leaving Mailgun as a deliverability project, not a billing swap. Plenty of comparison pages will tell you to export your list and sign up somewhere with a lower per-email rate; far fewer will warm your new dedicated IPs properly, rebuild your inbound routing and validation, hold DMARC steady, keep Mailgun live as a fallback, and pace the move so your placement survives it. We do that, onto dedicated Canadian infrastructure in Toronto, so you also gain flat cost, full observability and jurisdiction in the move. We are honest about whether you should migrate at all — Mailgun is a capable platform, and for some senders it is the right one — but if the per-email economics, the short logs, or the lack of control have made it the wrong fit, the careful migration onto infrastructure you own is exactly what we run.

Who this is for, and who it is not

It is for steady, growing senders frustrated with Mailgun’s per-email pricing, short log retention, add-on costs, Microsoft-inbox placement, or account stability, who want their sending on dedicated infrastructure and in a jurisdiction they control — and who cannot afford a deliverability crash in the process. It is for teams who understand the move is gradual and want it run with warming, authentication, and rollback discipline, including a real plan for inbound routing and validation if they use them. It is not for a small or sporadic sender genuinely better served by a shared pool and low fixed cost, for whom dedicated infrastructure would be overkill, and it is not a way to skip IP warming — nothing is. A Mailgun migration is one instance of the broader infrastructure migration discipline, a sibling to the SendGrid move, landing on Canadian infrastructure with dedicated IPs warmed through a proper ramp. Run as a parallel project, leaving Mailgun stops being a deliverability gamble and becomes a controlled upgrade to infrastructure that is yours.