Migrate from Mailgun to a sender-reputation-first European alternative

Honest answer: Mailgun's inbound routing is a genuine strength of the platform and our inbound is more limited. If you depend heavily on the routing rules engine, three options:

(1) Keep Mailgun for inbound only. Foundation plan at $35/month gives you the inbound routing while we handle outbound. The split-provider pattern is clean architecturally — outbound goes through us with our dedicated IPs and EU routing, inbound stays on Mailgun where the routing rules already work. (2) Migrate to a dedicated inbound service. CloudMailin and Postmark Inbound both offer rule-based inbound parsing comparable to Mailgun's. The migration involves rewriting your rules in the new provider's syntax. (3) Build on Postfix directly. If your inbound workflow is well-defined and you have engineering resources, running Postfix with custom processors is more flexible than any hosted inbound. Higher operational burden, but no per-message inbound costs.

We'll work through the right answer for your specific inbound workflow during the migration scoping. For most teams, option 1 (keep Mailgun for inbound only) is the lowest-friction path.

It actually makes migration easier rather than harder. Teams that landed on Mailgun's EU region already made the architectural decision that EU routing matters — they're past the residency question and just need an EU-native provider that doesn't gatekeep that decision at account creation. The migration runs identically; the dedicated IPs we provision are EU-native from day one.

The bigger consideration is for teams on the Mailgun US region who realized later they needed EU. Moving from Mailgun US to Mailgun EU causes the service disruption we mentioned (re-provision account, re-add domains, re-warm IPs). The same effort moving from Mailgun US to us gets you to the EU-jurisdictional infrastructure without the within-vendor migration overhead.

Domain reputation transfers; IP reputation doesn't. Sender reputation at receiving mailbox providers (Gmail, Yahoo, Microsoft) is largely tied to the combination of sending IP and From: domain. Your domain reputation stays attached to the domain — when emails start flowing through our new IPs but the same From: domain, receivers see "this domain has historical engagement, but the IP is new." That's the warmup signal they expect, and the 14-day ramp on new dedicated IPs handles it.

What we don't transfer: any historical IP-warmup data Mailgun built on the shared pools they used for your account. Independent tests showed Mailgun shared IP inbox placement around 71%, which is decent but a ceiling rather than a foundation — moving to dedicated IPs is what unlocks the next placement tier.

Amazon SES is the lowest-cost option at high volume, especially after the December 2025 Flex doubling made Mailgun's previously-cheap entry point less compelling. SES costs $0.10 per 1,000 emails vs Mailgun's $2/1K (Flex) or $0.70-$1.80 per 1K depending on plan tier. For teams sending 1M+ emails/month with AWS engineering already in-house, SES is genuinely competitive and Tenants (launched August 2025) addresses some historical scaling concerns.

Where we differ from SES: managed deliverability practice versus metered API. SES expects you to own warming, monitoring, complaint-rate management, list hygiene — all the operational work that Mailgun's Optimize suite and our platform handle. For teams without dedicated deliverability staff, our pricing typically beats SES + the cost of the internal deliverability lead. For teams that have that capability in-house, SES is a real alternative and we'd be honest about that.

Yes, and the per-tenant isolation model on our infrastructure is more flexible than Mailgun's. The Mailgun subaccount feature requires the Scale plan minimum ($90/month) and provides logical separation but tenants share underlying IP pools by default. Our model lets you allocate dedicated IPs per tenant on the higher plan tiers, which means a tenant's complaint rate doesn't contaminate other tenants' deliverability.

The migration mapping: Mailgun subaccount → AH subaccount with optional dedicated IP allocation per high-volume tenant. For agencies, white-label dashboards are available; the per-tenant API tokens, suppression scoping, and webhook isolation work the same way Mailgun's do.

Export before cancellation. Mailgun retains log data for 30 days on Scale plan and longer on higher tiers. Before cancelling the Mailgun account, we recommend exporting your last 30-90 days of event data via the Mailgun API (the /events endpoint) or the dashboard CSV export. Our dashboards cover the same event types Mailgun reports (delivered, opened, clicked, bounced, complained, unsubscribed, dropped, failed) plus per-IP reputation data and Postmaster Tools integration that requires dedicated IPs to be meaningful.

For teams that depend on Mailgun's analytics for product analytics workflows (passing event webhooks into Mixpanel, Segment, or a data warehouse), the webhook format compatibility means most of these integrations work unchanged after migration — the event taxonomy aligns and the payload structure is similar enough that schema mapping is a small effort rather than a rewrite.

Month-to-month on all standard plans with 30-day notice for cancellation. Annual contracts available with 10-15% discount if pricing certainty matters. No trial-then-paid-then-overage waterfall like SendGrid; no Flex-style pay-as-you-go that could double overnight. The plan you choose is the price you pay for the volume that plan covers, and overage discussions happen before they appear on a bill.

For migration projects specifically, the first 60 days are structured so that you can route back to Mailgun at any time if the new infrastructure doesn't meet your standards. We don't lock you in during the period when you're still validating.