Built an adaptive UI-based management layer for KumoMTA focused on automating deliverability & ESP operations.

Showcase
,
1

Hey everyone,

Over the past few years we ended up building an internal operations/deliverability platform around our MTA infrastructure focused on automating a lot of the operational overhead that usually becomes manual as ESP volume scales.

Some of the things it currently handles:

  • Automated bounce intelligence & provider-aware actions

  • ISP-aware throttling/backoff automation

  • Dynamic IP warmup engine

  • Reputation-based IP pool management

  • Traffic shaping & queue orchestration

  • Bounce/FBL driven routing decisions

  • ISP intelligence & analytics dashboards

  • Multi-tenant operational tooling

  • Automated suppression / retries / throttling workflows

  • Centralized monitoring, logs, and policy control

The goal was not to replace deliverability operators, but to systemize a lot of repetitive operational workflows while still keeping everything configurable when needed.

A few screenshots + short demo video below:

YouTube: Here is a video showcasing the platform.

A few notes:

  • currently closed-source

  • likely commercial/paid

  • pricing model not finalized yet

Mainly posting to see if other Kumo/MTA operators would actually find something like this useful interesting operationally.

Would genuinely appreciate feedback/questions from people running ESP infrastructure at scale.

2

Hi Ankit, This sounds like a very exciting porject. I am happy to explore synergies since this is very fit match for something we have built - postmta.com

3

That’s super impressive!!

4

Thank you very much :slight_smile:

5

Hey Dave
Let’s setup a call Meeting with Ankit - Ankit Srivastava

Thanks

6

Great work! Ankit, — curious how you’re handling the relationship between IP pool reputation scores and automated routing decisions when a pool is mid-warmup. Are you treating warmup pools as completely isolated from reputation-based routing or is there bleed-through?

Cheers!

8

Your question assumes warmup is a binary state, which I don’t think is accurate.

Reputation capacity scales continuously with historical trust, consistency, engagement quality, and time. “IP warmed up” does not mean unlimited sending capacity.

An IP sending 50k/day consistently for 2 months is not trusted the same way as an IP sending 5M/day consistently for 2 years.

So reputation is better modeled as a moving trust ceiling rather than:

  • cold

  • warmed

  • done

That’s why I think long-term velocity shaping and consistency matter far more than whether a pool is technically considered -in warmup.

9

Ah! That makes sense — trust ceiling as a continuous function rather than a state machine.

It sure changes design approach to routing logic during ramp-up.

Appreciate the perspective.

10

You are welcome.

If anyone is interested in purchasing the kumo management ui layer, email me at ankitsrivastava0193@gmail.com