Inboundr compared with inbound.new
The closest thing to the same product: an inbox, threads, attachments and an MCP server on both sides. The differences are in how volume is counted and what a rule can do.
inbound.new’s documentation and pricing last read 10 August 2026
The short version
- This is the closest comparison on the site: both are inbound-first, with an inbox, threads, attachments and a hosted MCP server.
- Inboundr counts received and sent mail as two separate allotments, so a month of heavy receiving cannot consume the ability to reply.
- A matching rule here can route or quarantine a message, not only drop it — filtering that redirects rather than deletes.
- inbound.new is ahead on scheduled sending, on being open source, and on generating filter rules from a description. If those decide it, they should.
The short version
Most of the pages in this section open by pointing out that inbound mail is a side feature of the product being compared. That argument is not available here and it would be dishonest to reach for it. inbound.new is an inbound-first email API with an inbox, threads, attachment downloads, filter rules and a hosted MCP server — the same list this product leads with. If you are choosing between the two on category, there is nothing to choose.
What is left is narrower, and worth being precise about rather than inflating: how your volume is counted, what a rule is allowed to do when it matches a message, and which commitments are written down. If none of those three decide it for you, the honest answer is that either will do the job — and the one you are already running is probably the right one, because migrating working email infrastructure costs more than the difference.
How the volume is counted
This is the difference most likely to show up on an invoice. Inboundr sizes a plan with two numbers — mail received and mail sent — and they do not draw on each other. inbound.new publishes plans sized by one monthly email figure for the account.
Which is better depends entirely on the shape of your traffic, and it is not a rout in either direction. A single pool is simpler to reason about and more forgiving if your traffic is lopsided in a direction you cannot predict: unused capacity is not stranded on the wrong side of a line. Two allotments are better when the two directions have genuinely different volumes — an agent that reads a great deal and replies occasionally, or a support address that receives far more than it answers — because a month of heavy receiving cannot quietly consume the ability to reply to any of it.
The failure mode worth picturing
A newsletter blast or a scraped-address run arrives at a catch-all. With one pool, that inbound spike is spending the same budget your outbound replies come from, and the first symptom is a reply that will not send. With two, the receiving side absorbs it and the sending side is untouched. Whether that matters to you is a question about your traffic, not about either product.
What a rule can do when it matches
Both products can decide that a message is unwanted before it reaches your code. The difference is what happens next.
- Blocking versus routing. A Shield rule here can allow, block, or send the message to different endpoints than the address normally uses — so “everything from this sender goes to the archive endpoint instead of waking the agent” is a rule rather than a branch in your handler. A route rule with no endpoint attached quarantines instead: the message is held and visible, not dropped.
- Where inbound.new is ahead on ergonomics. Their rules can be generated from a natural-language description of what you want filtered, which is a genuinely better way to write the first draft of a rule than any form. If the thing standing between you and filtering is that writing conditions is tedious, that is a real answer to a real problem.
- Spam specifically. Their documented options for spam are to reject, flag or accept it, decided in mailbox settings. Here the spam verdict is one more condition a rule can match on, alongside sender, recipient and subject — so it composes with everything else rather than being a separate switch.
Side by side
Read the bottom three rows first. They are the ones where the answer goes against us, and they are the reason this table is worth trusting on the rows above them.
| What you need | Inboundr | inbound.new |
|---|---|---|
| Receive mail on a domain you own | One MX record and one DKIM record on the domain or subdomain you choose, then every address on it resolves, catch-all included. | The same shape: point your MX records at them and any address on the domain receives, with unlimited mailboxes and no per-address setup. |
| The whole message, kept and fetchable | Messages are retained for the same window on every plan, including Free, and stay readable over REST and MCP for its whole length. | Received mail is stored and readable by id, with threads and attachment downloads in the API. How long it is kept is not something their public documentation states. |
| Threads, not just individual messages | Threads are first-class: fetch a conversation oldest-first, and replies are written into it. | Also first-class. Their inbox API lists threads with cursor pagination and is documented as the endpoint for building an inbox UI. |
| An MCP server an agent can drive | A hosted MCP endpoint over streamable HTTP, same bearer token as the REST API. | A hosted MCP server too, documented for Claude, Cursor and OpenCode. Neither side is the only one an agent can talk to. |
| Inbound and outbound counted separately | Two allotments per plan, one for mail received and one for mail sent. A month of heavy receiving cannot exhaust the ability to reply. | Their published plans are sized by a single monthly email figure covering activity on the account, so receiving and sending draw on the same number. |
| A rule that redirects rather than only drops | A matching rule can allow, block, or route the message to different endpoints — and a route rule with no endpoint quarantines it, so it is held rather than lost. | Filter rules exist and can be generated from a natural-language description, which is genuinely nice. Spam handling is documented as reject, flag or accept; sending a matched message somewhere else is not part of what is described. |
| A tier that costs nothing | A free plan with its own monthly allotment, one domain and the same retention as every other plan. It blocks at the limit rather than billing. | Every plan on their pricing page is paid; there is no free tier listed on it. |
| Scheduled sending | Mail goes when you call the API. There is no scheduled_at and nothing to cancel. | Send now or schedule for later, with an endpoint to cancel a scheduled message before it goes. |
| Read the implementation | Closed source. What is public is the documentation and the API. | The project is on GitHub, so the behaviour behind the API is something you can go and read rather than infer. |
Receive mail on a domain you own
- Inboundr
- One MX record and one DKIM record on the domain or subdomain you choose, then every address on it resolves, catch-all included.
- inbound.new
- The same shape: point your MX records at them and any address on the domain receives, with unlimited mailboxes and no per-address setup.
The whole message, kept and fetchable
- Inboundr
- Messages are retained for the same window on every plan, including Free, and stay readable over REST and MCP for its whole length.
- inbound.new
- Received mail is stored and readable by id, with threads and attachment downloads in the API. How long it is kept is not something their public documentation states.
Threads, not just individual messages
- Inboundr
- Threads are first-class: fetch a conversation oldest-first, and replies are written into it.
- inbound.new
- Also first-class. Their inbox API lists threads with cursor pagination and is documented as the endpoint for building an inbox UI.
An MCP server an agent can drive
- Inboundr
- A hosted MCP endpoint over streamable HTTP, same bearer token as the REST API.
- inbound.new
- A hosted MCP server too, documented for Claude, Cursor and OpenCode. Neither side is the only one an agent can talk to.
Inbound and outbound counted separately
- Inboundr
- Two allotments per plan, one for mail received and one for mail sent. A month of heavy receiving cannot exhaust the ability to reply.
- inbound.new
- Their published plans are sized by a single monthly email figure covering activity on the account, so receiving and sending draw on the same number.
A rule that redirects rather than only drops
- Inboundr
- A matching rule can allow, block, or route the message to different endpoints — and a route rule with no endpoint quarantines it, so it is held rather than lost.
- inbound.new
- Filter rules exist and can be generated from a natural-language description, which is genuinely nice. Spam handling is documented as reject, flag or accept; sending a matched message somewhere else is not part of what is described.
A tier that costs nothing
- Inboundr
- A free plan with its own monthly allotment, one domain and the same retention as every other plan. It blocks at the limit rather than billing.
- inbound.new
- Every plan on their pricing page is paid; there is no free tier listed on it.
Scheduled sending
- Inboundr
- Mail goes when you call the API. There is no scheduled_at and nothing to cancel.
- inbound.new
- Send now or schedule for later, with an endpoint to cancel a scheduled message before it goes.
Read the implementation
- Inboundr
- Closed source. What is public is the documentation and the API.
- inbound.new
- The project is on GitHub, so the behaviour behind the API is something you can go and read rather than infer.
When inbound.new is the better choice
- You want to read the source. Their project is public. For infrastructure that sits in the path of every message a business receives, being able to read the implementation — rather than infer it from documentation and behaviour — is a legitimate requirement, and one this product does not meet at all.
- You need to schedule mail. They can send later and cancel before it goes. Here, mail sends when you call the API, and scheduling is something you would build and operate yourself.
- Your traffic is lopsided in a direction you cannot predict. One pool that either direction can draw on is the more forgiving design when the mix moves around, and it is one less number to understand.
- You want rules written for you. Describing a filter in a sentence and having the rule generated is a nicer first draft than filling in conditions, and there is no equivalent here.
- You are already running it and it works. This is the most likely one, and it deserves stating plainly. Moving inbound email means changing MX records, re-pointing handlers and re-testing every path that mattered. The differences on this page are real but narrow, and none of them is worth that on its own unless one of them is actively costing you something.
If you do decide to move
The mechanics are the same as any receiving change, and the order is what keeps mail from falling on the floor:
- Add the domain here and publish the DKIM record. Nothing changes for live mail: until the MX record moves, every message still goes where it goes today.
- Create the addresses you actually use and point them at an endpoint. If you were relying on a catch-all, set that instead — it covers every address on the domain at once.
- Test against the endpoint before cutting over, and confirm your handler reads this payload shape. Both products send the parsed message to a webhook, but the field names are not the same and your signature check is against a different secret.
- Move the MX record. Receiving switches over as DNS propagates; messages already delivered on the other side stay there, so keep that account open for as long as its retention window matters to you.
Questions people ask
Is this page going to tell me they are worse?
No, and it would not survive contact with anyone who has used both. inbound.new does the same job, has an inbox, threads, attachments and an MCP server, and is ahead on scheduling, on being readable source, and on how rules get written. The differences that favour Inboundr are the two allotments, what a matched rule is allowed to do, a free tier, and retention being stated up front. That is the whole of it.
Which one should an AI agent use?
Both expose a hosted MCP server, so an agent can drive either without you writing a wrapper. Pick on the surrounding details: whether the agent’s reading volume should be able to exhaust its ability to reply, and whether you want a rule to be able to divert mail away from the agent rather than only drop it. Those decide it far more than the tool list does.
Why is there no price comparison on this page?
Because it would be wrong within a quarter. Their plans are published on their pricing page and ours are on ours; both change. What is worth comparing is the shape rather than the number: they meter one combined email figure per month and bill additional domains separately, while Inboundr counts the two directions apart, includes domains in the plan, and charges past the allotment only if you opt into it.
Can I run both at once?
Yes, on different domains or subdomains. A domain’s MX record can only point at one receiver, so the split has to be by domain — but running a live workload on each is the only comparison that settles anything this page cannot.
Claims about inbound.new were checked against their public documentation index, their API reference for threads, attachments, filter rules and scheduled sending, their MCP integration guide, and their pricing page. Read on 10 August 2026. If something here is out of date, tell us and we will correct it.