The Mailgun Routes alternative whose mailbox doesn't expire

Mailgun receives on your domain and evaluates a list of routes against each message. A route has a priority, a filter expression — match_recipient with a regular expression, match_header, or catch_all — and one or more actions: forward() to an address or a URL, store() to keep a copy and optionally notify you, and stop() to prevent lower-priority routes from running.

It is a capable inbound webhook: the POST is parsed rather than raw, it carries a signature you can verify, and failures are retried. Two things about it decide whether it is the right home for mail your business depends on — how long the mailbox lasts, and what it takes to change where mail goes.

store()is described in their own documentation as temporary: messages are kept for around three days, extending to about seven depending on your plan and the domain’s settings. You fetch one through the Messages API using a storage URL that comes from the event log.

Three days is plenty for the job it was designed for — bridging a webhook failure, or letting a worker pick a message up asynchronously. It is not enough for the things people reach for storage for:

• Replaying after a bug you found late. A parsing error noticed on Monday and traced back over a fortnight cannot be re-run against mail that was stored for three days.
• Showing a user the original message. “Here is the email this ticket came from” is a feature request that arrives eventually, and it turns a temporary store into a permanent one — in your database, with your attachment bucket, on your backup schedule.
• An agent catching up on a quiet inbox. An assistant that reads its mail twice a week is asking for something that expired on Wednesday.

The second difference is how you say where mail should go. A route is an ordered rule with a filter expression and actions, evaluated top-down. An address here is a thing that exists, with endpoints attached to it.

# Routes: ordered expressions, evaluated per message.
priority 0  match_recipient("^support@yourdomain\.com$")
            forward("https://app.example.com/hooks/support"), stop()
priority 1  match_recipient("^billing@yourdomain\.com$")
            forward("https://app.example.com/hooks/billing"), stop()
priority 2  catch_all()
            store(notify="https://app.example.com/hooks/catchall")

# Addresses: objects with endpoints attached.
support@yourdomain.com   → webhook "app-support" + forward to team inbox
billing@yourdomain.com   → webhook "app-billing"
*@yourdomain.com         → store only

Expressions are more powerful — matching on a header is a one-liner there and not expressible here. Objects are the ones you can be confident about at 3am: no priority order to reason about, no stop() to forget, and no regular expression quietly matching support@yourdomain.company because somebody did not escape a dot.

The practical difference is who can safely change it. Adding an address and pointing it somewhere is a thing a support lead can do in the console. Editing an ordered list of regular expressions that route production mail is not.

The rows that decide it are storage, routing and what an agent finds behind the tools.

No price table — the numbers change and a stale one is worse than none. Check theirs at the source and ours here.

• Mailgun meters sending volume, with inbound routes and a short store included alongside it, and log retention that varies by plan. If most of your mail goes out, receiving costs you close to nothing extra.
• Inboundr meters messages received, with an allowance then overage at one flat rate, and the same retention window whichever plan you are on. Domains and addresses are not billable units.

The thing to compare is not the line item but what you would build around it: if you would end up copying every stored message into your own bucket before it expires, that job — and the bucket, and its lifecycle rules — belongs in the comparison.

Routes translate into addresses fairly mechanically:

1. 1List your routes in priority order. Each match_recipient that names one address becomes one address here; a catch_all becomes the catch-all. Anything matching a header is the part that needs thought — that is usually a filtering rule here, or a branch in your handler.
2. 2Add the domain in the Inboundr console, publish the DKIM record it shows you, and leave the MX records alone. Verification does not affect delivery, so this is safe with routes still live.
3. 3Recreate the destinations as endpoints, then adapt your handler: JSON instead of form fields, an HMAC header instead of timestamp/token/signature, and attachment links instead of parts.
4. 4Swap the MX records, TTL lowered an hour beforehand. Mail in flight follows the old records and still hits your routes, which should stay in place.
5. 5Copy anything you still need out of store() before it expires. This is the step with a deadline — the window is days, not weeks.
6. 6Send a test with an attachment and a reply in a thread, then return a 500 deliberately and watch the retry land. Confirm the behaviour rather than assuming it.