The CloudMailin alternative with the inbox already built
CloudMailin posts the message to your app and stops there. Inboundr keeps it: retained messages, threads, fetchable attachments and an inbox your agents can call.
CloudMailin’s documentation and pricing last read 30 July 2026
The short version
- CloudMailin stops at the POST: your endpoint gets the message, and the mail table, the thread model and the internal API behind it are yours to build.
- Here the message stays addressable — retained, threaded, with attachments fetchable by link, by API or by an agent tool call.
- Filtering runs before delivery, so unwanted mail never becomes an invocation you pay for and discard.
- One predictable JSON payload every time means no per-address format decisions and no MIME parser in your codebase.
The same premise, a decade apart
CloudMailin exists because applications need to receive email, and it has existed for that reason for well over a decade. That is the same premise this product starts from, so the comparison is not about whether inbound deserves its own service — both of us think it does.
It is about where the line sits. Their model stops at the POST: the message reaches your endpoint, attachments go to a bucket you own, and from that moment the mail is your application’s problem. This product carries on past that line — retained messages, threads, fetchable attachments, filtering rules and an inbox an agent can call — because that is where most of the work actually lives.
What happens after the POST
Their model assumes your application is the system of record: mail arrives, your endpoint takes it, attachments go to your bucket, and from then on the message is yours. It is a clean division. It also leaves three services on your side of the line:
- The message store.If you want to re-read what arrived last Tuesday, that is your database and your schema — envelope, bodies, headers, attachment keys, migrations for all of it. Here the message is retained for the plan’s window and queryable over REST without you having modelled anything.
- The thread.Grouping messages into conversations, and writing In-Reply-To and References on the way back out, is work you do in both products’ worlds — except that a
get_threadcall and aninReplyToparameter are what that work looks like here. - Anything an agent talks to. With the mail in your database, an agent needs an API you wrote, with auth you designed, described in a tool schema you maintain. That is a week of work to reach the starting line, and it is a week you skip if the inbox already speaks MCP.
Three services you do not write
A mail table with migrations, a thread model, and an internal API with credentials and a tool schema for anything autonomous to talk to. Teams that already own all three are being asked to pay for a store they will not use — everyone else is being asked to build it before the feature they actually wanted can ship.
Side by side
Both products get the message to your endpoint. The rows worth your attention are the ones about what is still there tomorrow.
| What you need | Inboundr | CloudMailin |
|---|---|---|
| One predictable payload for every message | The same JSON shape every time, whatever the sender did. Nothing to choose, nothing to configure per address, and no MIME parser in your codebase. | JSON, multipart or raw MIME, chosen per address. More flexible, and raw means the parsing is back with you. |
| Attachments kept out of the request | Stored on arrival and handed out as short-lived links, from the payload, the REST API, or a get_attachment tool call. | They can drop attachments straight into your own S3, Google Cloud Storage or Azure bucket, which keeps the bytes under your control and out of the POST entirely. |
| Fetch the message body later | Every message is stored and listable over REST or MCP for the plan's retention window, so a consumer that was down catches up afterwards. | Delivery attempts and errors are visible in their dashboard. Possession of the message itself is expected to be yours — the storage they emphasise is your bucket, and the mail table behind it is your schema. |
| Retries you can see | Exponential backoff with every attempt and status recorded against the message. | Retries with the error your server returned kept alongside them, so you can see what failed and when it finally landed. Genuinely good operational visibility. |
| Filtering before delivery | Rules on sender, recipient, subject or spam verdict drop or divert a message before it becomes a request, with a list of what was blocked. | Spam and authentication results come through with the message, and addresses can be pointed at different targets. The accept-or-drop decision is one your endpoint makes. |
| A threaded reply from code | Name the message you are answering and the threading headers are written for you, in the same account that received it. | Sending is supported over their API and SMTP, so replies are a first-class thing — but In-Reply-To and References are yours to assemble. |
| An agent that works its own inbox over MCP | A hosted MCP server on the same API key: list, read, thread, send, fetch attachments, manage filtering rules. | No first-party MCP server documented at the date checked. An agent reaches their inbound mail through whatever HTTP surface you put in front of it. |
One predictable payload for every message
- Inboundr
- The same JSON shape every time, whatever the sender did. Nothing to choose, nothing to configure per address, and no MIME parser in your codebase.
- CloudMailin
- JSON, multipart or raw MIME, chosen per address. More flexible, and raw means the parsing is back with you.
Attachments kept out of the request
- Inboundr
- Stored on arrival and handed out as short-lived links, from the payload, the REST API, or a get_attachment tool call.
- CloudMailin
- They can drop attachments straight into your own S3, Google Cloud Storage or Azure bucket, which keeps the bytes under your control and out of the POST entirely.
Fetch the message body later
- Inboundr
- Every message is stored and listable over REST or MCP for the plan's retention window, so a consumer that was down catches up afterwards.
- CloudMailin
- Delivery attempts and errors are visible in their dashboard. Possession of the message itself is expected to be yours — the storage they emphasise is your bucket, and the mail table behind it is your schema.
Retries you can see
- Inboundr
- Exponential backoff with every attempt and status recorded against the message.
- CloudMailin
- Retries with the error your server returned kept alongside them, so you can see what failed and when it finally landed. Genuinely good operational visibility.
Filtering before delivery
- Inboundr
- Rules on sender, recipient, subject or spam verdict drop or divert a message before it becomes a request, with a list of what was blocked.
- CloudMailin
- Spam and authentication results come through with the message, and addresses can be pointed at different targets. The accept-or-drop decision is one your endpoint makes.
A threaded reply from code
- Inboundr
- Name the message you are answering and the threading headers are written for you, in the same account that received it.
- CloudMailin
- Sending is supported over their API and SMTP, so replies are a first-class thing — but In-Reply-To and References are yours to assemble.
An agent that works its own inbox over MCP
- Inboundr
- A hosted MCP server on the same API key: list, read, thread, send, fetch attachments, manage filtering rules.
- CloudMailin
- No first-party MCP server documented at the date checked. An agent reaches their inbound mail through whatever HTTP surface you put in front of it.
When CloudMailin is the better choice
- You need raw MIME, or a format we do not offer. Per-address choice of JSON, multipart or raw is theirs alone. If your pipeline already parses MIME, or an auditor requires the original bytes, that decides it.
- Files may never sit with a vendor. Writing attachments straight into your own bucket is stricter than short-lived links, and sometimes strict is the requirement.
The case where the two diverge most
The clearest difference is an agent. Both products can hand a message to code. Only one of them can be the thing an agent talks to, because that requires the mail to still be somewhere addressable, threaded, and reachable with the same credential:
# One endpoint, the same API key.
https://inboundr.net/api/mcp
list_emails newest first; filter by address, thread or direction
get_email full bodies, attachment metadata, auth verdicts
get_thread the whole conversation, oldest first
get_attachment the bytes, while the message is retained
send_email pass inReplyTo to answer inside the threadWith mail in your own database the equivalent is an internal API, scoped credentials for it, a tool schema, and the ongoing job of keeping all three in step. Worth doing if the agent is your product; hard to justify if the agent is one feature. See how to give an agent its own address for what that looks like end to end.
What each one costs
No numbers here — both change them, and a stale figure is worse than none. Check theirs at the source and ours here.
Both meter messages received rather than domains or addresses, so the line items compare directly. What differs is what the meter buys: theirs leans on your storage and your schema, ours includes retention, filtering, the read APIs and the agent interface on top of delivery. Compare like for like by adding what you would build on their side into the column — the bucket, the mail table, the thread model and the internal API are not free just because they are not invoiced.
Moving an address across
- Add the domain in the Inboundr console and publish the DKIM record it shows you. If you receive on one of their addresses rather than your own domain, this is also the moment you pick the domain you want to own.
- Create the addresses and endpoints matching your current targets. An address can point at more than one endpoint, which is the easy way to run the new pipeline beside the old one.
- Adapt the handler. If you take their JSON format the shapes are close; if you take raw MIME today, this is where the parser you maintain stops being necessary.
- Add the signature check — an HMAC header over the body and a timestamp — before the endpoint goes live.
- Swap the MX record, TTL lowered an hour beforehand, and send a test message with an attachment.
- Decide what to do about history. Anything already in your own database or bucket stays exactly where it is; nothing backfills into this account, because we only see mail that arrives after the MX change.
Questions people ask
Can I get the raw MIME message here?
No — the payload is parsed JSON, every time. For most teams that is the feature: no format decision per address and no MIME parser to maintain. If you specifically need the original bytes, that is a real reason to choose them.
Can attachments go to my own bucket?
Not directly. Attachments are stored on arrival and handed out as short-lived links, so copying them into your own storage is a fetch in your handler rather than something the provider does for you. Their direct-to-bucket arrangement is the better answer when the files must never sit with a vendor.
What does retention actually get me?
Replay after a bug, showing a user the message a ticket came from, an agent reading on its own schedule, an attachment requested next month, and a consumer that was down catching up — all without a mail table, a migration or a backup policy of your own.
Do both handle SPF, DKIM and spam checks?
Both surface authentication and spam results with the message. The difference is that here a rule can act on the verdict before delivery, so the message never becomes a request you pay for and then discard.
Claims about CloudMailin were checked against their public developer documentation, their email receiving service pages and their pricing page. Where this page says something is not documented, that is a statement about the documentation as it stood. Read on 30 July 2026. If something here is out of date, tell us and we will correct it.