A Mailgun Routes alternative for inbound mail

Different shapes of the same job

Mailgun Routes are filter expressions attached to a domain. You write a match — match_recipient(".*@your-domain.com") — and a list of actions such as forward(), store() or stop(), ordered by priority. It is powerful and it is expressed as strings in a form field.

MXcatch models the same job as aliases with actions. The address is a first-class object with a list of things that happen to its mail, and rules handle the cases where the address alone is not enough.

Neither is wrong. Which fits depends on whether you think in expressions or in addresses — and on what else you need from the provider.

The webhook difference

This is the most practical distinction. A Mailgun Route that forwards to a URL delivers the message as multipart form fields, with attachments inlined in the same request. Your handler parses a multipart body, and a message with a 20 MB attachment is a 20 MB request.

MXcatch POSTs JSON. Attachments are not inlined — each arrives as a pre-signed URL valid for 60 minutes, with its filename, MIME type, byte size and SHA-256:

"attachments": [{
  "name": "receipt.pdf",
  "mime": "application/pdf",
  "size": 49152,
  "sha256": "9f8e7d6c...",
  "url": "https://ams3.digitaloceanspaces.com/..."
}]

The payload stays small and predictable, you fetch only the files you actually want, and the digest lets you verify what you downloaded. Full schema in the webhook reference.

Paying for the direction you use

Mailgun's plans are built around messages sent. Inbound routing comes along with them, which is efficient if you send a lot and incidental if you send nothing — a team that only wants to receive ends up on a sending plan for the inbound feature.

MXcatch charges a fixed monthly price with a daily ceiling. Free covers one domain and 50 messages a day; the other tiers are on the pricing page. There is no per-message component, so a burst of traffic does not produce an invoice.

Somewhere to look

Mailgun's store() keeps a message for later retrieval over the API — it is storage, not a mailbox. MXcatch includes a webmail inbox on every plan, which changes debugging: when a webhook does not fire you can open the message, see its parsed body and attachments, and read the per-action status rather than reconstructing it from logs.

Reasons to stay on Mailgun

• You send with Mailgun. Keeping both directions in one account, with one set of logs and analytics, is worth real money in operational simplicity.
• You need high inbound volume. Mailgun's ceilings are far above what MXcatch's plans are sized for.
• You need mature deliverability tooling. Suppressions, bounce classification, dedicated IPs, detailed analytics — MXcatch has none of that, because it does not send.

Running both is normal: Mailgun for outbound, MXcatch for inbound. They use different DNS records and do not conflict.

Moving the inbound half

1. List your existing routes and note what each one matches and does.
2. Recreate them as aliases in MXcatch — a match_recipient(".*@domain") route becomes a catch-all; a specific recipient becomes a named alias.
3. Move header and body matching into routing rules.
4. Update your handler to read JSON instead of multipart, and to verify X-MXcatch-Signature.
5. Swap the MX records — per-provider steps — and test before removing the Mailgun routes.

Other comparisons

ImprovMX for straightforward forwarding, and Cloudflare Email Routing if your DNS is already at Cloudflare.