Mailgun Routes and inbound both turn incoming email into application requests. Compare how you route messages, retrieve files, keep conversation state, and recover failed deliveries before moving a working integration.
Stay with Mailgun when your application depends on its recipient or header expressions, regex matching, route priorities, or forward/store/stop actions. Keeping receiving beside an existing Mailgun API or SMTP sending integration can also reduce migration work.
Consider inbound when the application needs address-level routing, a parsed JSON webhook, stored thread resources, and a reply endpoint in one workflow. Mailgun also supports JSON Route delivery, announced in September 2026; JSON alone is not a reason to switch.
Mailgun delivers form data or multipart data by default, and JSON when the forwarding destination ends in json. Its current HTTP documentation describes Base64 attachment content inside that JSON payload. inbound sends parsed bodies and attachment metadata with authenticated download URLs.
Mailgun documents temporary route storage for up to three days and HTTP delivery retries over eight hours, subject to response-code rules. inbound records delivery failures but does not retry automatically; use POST /api/e2/emails/:id/retry after fixing the endpoint. Build recovery into the migration, rather than carrying over assumptions about retries.
inbound plans start at $9/month, with sending and receiving metered separately. Mailgun's route entitlements depend on the plan, including a route on its Free plan. How Mailgun bills receiving that only forwards to HTTP is described in their docs; an outbound sending allowance doesn't tell you how inbound is billed.
Turn a fixed-recipient Mailgun route into an inbound email address linked to an endpoint. Use a domain catch-all for unmatched addresses. Inventory header expressions, priorities, and stop actions separately: address routing is not a direct translation of Mailgun's rule language.
Normalize both providers into your application's message model. Keep the SMTP envelope separate from visible To headers, and preserve original message headers for existing conversations.
Run inbound on a separate receiving subdomain while Mailgun handles the current hostname. Parallel rehearsal means separate test destinations or controlled message copies; publishing both providers' MX records does not mirror delivery to both.
| inbound | Mailgun | |
|---|---|---|
| Receiving model | Domain and address routing to application endpoints; received messages available through the API. | Routes with matching expressions and forward, store, and stop actions. |
| Payload format | JSON email.received event with parsed text and HTML in email.parsedData. | Form/multipart by default; opt-in JSON delivery for destinations ending in json. |
| Attachments | Metadata and API-key-authenticated download URLs. | Multipart files, or Base64 content in the JSON attachments array. |
| Threading and replies | Thread list/get APIs and reply by email or thread ID; reply headers set for you. | Route payload includes headers; the reviewed workflow leaves conversation mapping to the application. |
| Custom domains and routing | Custom MX domains, individual address endpoints, and domain catch-all. | Custom MX domains, recipient/header matching, regex, priorities, and catch-all rules. |
| Sending | Send API plus a dedicated reply endpoint. | API and SMTP sending. |
| How pricing works | Plans start at $9/month; separate sent and received allowances. See pricing for current terms. | Route entitlements vary by plan. Exact HTTP-only receiving metering: see their docs. |
| Failed webhook delivery | Recorded failures; manual retry API. No automatic retries. | Documented HTTP retries over eight hours, with response-code exceptions. |
Compared using public documentation as of September 2026. Check Mailgun's current Routes and HTTP payload docs before migrating: https://documentation.mailgun.com/docs/mailgun/user-manual/receive-forward-store/routes and https://documentation.mailgun.com/docs/mailgun/user-manual/receive-forward-store/receive-http. Check current plan entitlements at https://www.mailgun.com/pricing/.
Yes. A Mailgun route can send a parsed message to an HTTP endpoint, and routes also support temporary storage. Forwarding to HTTP is application ingestion, not just forwarding to another mailbox. inbound offers an address-to-webhook workflow with message and thread APIs.
Check the route destination and the request's Content-Type first. Default routes with attachments use multipart/form-data; JSON destinations carry Base64 attachment content. A handler expecting only URL-encoded fields can miss uploaded files. Inspect the delivery response and your server's request-size limit before changing providers.
See their docs for the currently supported route and storage options; do not assume a route removes attachment bytes. inbound provides authenticated attachment download URLs, so application workers can retrieve files separately. Its raw MIME can still include attachment content; inbound does not promise an attachment-free webhook body.
Add a domain, point an address at your webhook, and get structured JSON for every message.
Get started