Migrating from Mailgun to an EU-hosted email provider: a practical guide

If you're reading this, your legal or procurement team has probably raised EU data residency as a concern, or your CFO has noticed Mailgun's bill climbing. Either reason is valid. This guide is the practical version of "how do we actually move?"

First: is moving worth it?

Before migration planning, confirm the payoff.

You should move if:

• You're based in the EU (or handle EU customer data) and your DPO is tired of Standard Contractual Clauses.
• You pay for Mailgun add-ons (Inbound Parse, Validations, Dedicated IPs) separately and would prefer one consolidated bill.
• Your EU deliverability (to German, French, Scandinavian inboxes) is visibly weaker than your US deliverability.

You should stay if:

• Your customers are 90% US and you have no EU-specific legal obligations.
• You use Mailgun's Marketing Campaigns (Postscale doesn't offer broadcasts).
• You've negotiated an aggressive volume-tier Mailgun deal that an EU provider can't match.

Most EU-headquartered SaaS teams fall into the "move" category. If you're unsure, spend 30 minutes reading our EU-hosted email APIs GDPR guide first.

What doesn't change

A lot. This reassures people.

• Your sending domain stays the same. No change to your From: address, no re-warming of domain reputation.
• Your templates are portable. If you store them as HTML strings, they work unchanged. If you use Mailgun's template API, migration is a CSV export/import.
• Your subscribers and suppression lists are CSV-exportable and re-importable.
• Your SMTP integration just needs a host + credentials swap.
• Your reputation metrics (opens, clicks, bounces, complaints) restart — but your domain reputation carries.

What does change

1. DNS records

Mailgun uses its own DKIM, SPF-include, and tracking-CNAME pattern. You add new records from the destination provider and verify them alongside the Mailgun ones. Once both pass, you can deprecate Mailgun's.

For Postscale specifically:

• Two DKIM CNAMEs (ps1, ps2)
• One SPF include (or combine with your existing SPF record)
• Optional: MX record pointing at mx.postscale.io if you're also moving inbound

TTL down to 300 seconds a day before migration so you can cut over quickly and roll back quickly.

2. API endpoint

s/api.mailgun.net/api.postscale.io/ — almost literally.

# Mailgun
POST https://api.mailgun.net/v3/example.com/messages

# Postscale
POST https://api.postscale.io/v1/send

The request body shape is close enough that your sending wrapper needs minor renames rather than a rewrite. Mailgun uses multipart/form-data heavily; Postscale prefers JSON but accepts both. If your integration goes through an SDK, the SDK change is often a one-line import.

3. Event webhooks

Event names mostly align:

Payload shapes differ in field names but carry equivalent data. Your webhook handler needs a shim for the first few weeks (or permanently if you're allergic to touching working code).

4. Inbound and validations

If you used Mailgun's Inbound Parse, Postscale's Inbound Email API replaces it with one key and one webhook endpoint — no extra billing line. The payload is MIME-parsed JSON in both systems.

If you used Mailgun's Email Validations API, Postscale validates at send time (invalid addresses fail-fast rather than deliver). If you need batch pre-validation, that's a separate discussion — we don't sell it as an add-on.

The migration week

A realistic timeline, small-to-mid team, no Big Bang Friday drama:

Monday — reduce DNS TTLs, provision accounts

• Postscale signup, domain verification kickoff.
• Drop TTLs on Mailgun DNS to 300s.
• Export Mailgun suppressions (bounces, spam complaints, unsubscribes) as CSV.

Tuesday — staging cutover

• Import suppressions into Postscale.
• Swap your staging app's SMTP/API credentials to Postscale.
• Run your normal test suite; send 20–50 real messages to a seed list.
• Verify DKIM/SPF/DMARC alignment using a tool like mail-tester.com.

Wednesday — 10% production cutover

• Add a traffic-split flag so 10% of production messages route to Postscale.
• Monitor: delivered rate, bounce rate, complaint rate (should all be identical to Mailgun's numbers).
• Watch webhooks arrive; confirm your shim handles both shapes.

Thursday — 50% cutover

• If Wednesday's metrics are clean, double to 50%.
• At this point any divergence vs. Mailgun is real signal, not noise. Pause and investigate if numbers diverge.

Friday — DO NOT cut over further. Never complete a migration on a Friday. Monitor over the weekend at 50%.

Next Monday — 100%

• Route all traffic to Postscale.
• Leave Mailgun account active for 7 days as rollback insurance.
• Remove the webhook shim once everything is stable.

Week 3 — clean up

• Remove Mailgun DNS records.
• Cancel Mailgun subscription.
• Raise TTLs back to normal values.

What can go wrong

• DKIM signature breaks on certain ESPs. Rare but happens if your template modifier adds headers between send call and wire. Test with mail-tester.com specifically to Gmail + Yahoo + Outlook.com + GMX + Apple iCloud.
• Complaint rate spikes briefly during cutover because subscribers haven't seen your From: name recently. Use identical From: names on both sides to minimize.
• Bounce handling gaps — if your app updates user state from Mailgun bounce webhooks, and during migration some messages bounce via Postscale with different payload shapes, user state can go stale. The shim should unify both before updating the DB.
• Outbound DNS misconfiguration. If you forget to remove Mailgun's SPF include after cutover, your SPF record is wasteful but not broken. If you remove Postscale's include accidentally, every message fails SPF. Double-check before deleting anything.

Done. Now what?

Once you're on a consolidated EU provider, a few new capabilities are there for the taking:

• Move inbound to the same key. If you were on Mailgun Inbound Parse, swap the MX and you have support inboxes, reply threading, etc. on one pipeline.
• Masked addresses. If your product has a privacy angle (referrals, signup forms, marketplace DMs), Postscale Shield gives you the Apple-style "Hide My Email" primitive on your own domain.
• DMARC reporting. Wire a rua= record pointing at Postscale and start getting structured reports on who's sending as your domain.

Migration is annoying. But once it's done, the compounding compliance and billing benefits make it worth it — and you've removed a US data processor from your DPA list.

If you're comparing vendors specifically, see our Postscale vs Mailgun page for the feature-by-feature comparison.