Case Study · InboxPro

Building the infrastructurebehind modernemail deliverability.

InboxPro is the sending platform of EmailMarketing.com, the deliverability group behind EmailDeliverability.com and MailGenius. We built the infrastructure it sends on from scratch: KumoMTA on owned bare metal, its own egress IP estate, multi-tenant routing, warmup, ISP feedback loops and the observability that lets a small team run all of it.

Emails sent per month: 40MEmails sent per month
MTA deliverability uptime: 99.99%MTA deliverability uptime
Deliverability health score: 98%Deliverability health score

Engagement Overview

EmailMarketing.com is one of the best known names in email deliverability. The group around it, which also owns EmailDeliverability.com and MailGenius, has published more than $250M generated for its clients since 2020 and counts 640+ businesses on its deliverability software. Placement is the product. InboxPro is where the group sends from.

We were brought in to build that sending platform and to keep running it. A team of three: an infrastructure engineer, a delivery manager and a fullstack AI engineer, standing up KumoMTA on dedicated OVH bare metal with its own egress IP estate, multi-tenant routing, warmup, ISP feedback loops and a full observability layer over the lot. It carries around 40M emails a month and the repositories are still active.

The commercial reason for doing it that way is simple. On a shared ESP pool, reputation, capacity and cost per message all belong to the vendor. Owning the path end to end, from the GoHighLevel inject to the inbox provider that accepts the message, turns deliverability into an engineering variable the group controls, which is why its customers are moving onto InboxPro: better placement at a lower price than the rails they came from.

40M
Emails sent per month: 99.99%
MTA deliverability uptime: 98%
Deliverability health score

Engagement: Team as a Service / AI Consulting
Team: 1 Infrastructure Engineer1 Delivery Manager1 Fullstack AI Engineer
Focus: High-volume MTA and deliverability ops
Working model: Owned delivery, Client consulting

Stack

Mail transfer

KumoMTA
Lua policy
SMTP / port 25
SASL auth
SPF / DKIM / DMARC

Services

Node.js
Express
BullMQ
Python

Data & storage

PostgreSQL
SQLite
Redis
Loki TSDB

Infrastructure & DevOps

OVH dedicated bare metal
Terraform
Ansible
Ansible Vault
Docker
Caddy
UFW
Let’s Encrypt
GitHub

Observability

Prometheus
Grafana
Alertmanager
Loki

Deliverability integrations

Google Postmaster Tools
Microsoft SNDS
Yahoo Senders Hub
Cloudflare
GoHighLevel
Discord & Slack webhooks

Machines racked in a cabinet in a dim server room, network cables patched into their ports

The Challenge

The group needed to send at scale without living on somebody else’s pools. Put a deliverability business on a shared ESP and the three things that decide whether an email arrives, IP reputation, cost per message and account risk, all sit with the vendor. One noisy neighbour on the same pool, or one policy change upstream, and the product moves without anybody touching it.

Taking that in house is not a weekend of server scripts. Port 25 outbound, reputation per IP, DKIM alignment and hard isolation between customers all had to become first-party and operable by a small team. Warmup and ISP feedback, Gmail Postmaster, Microsoft SNDS, Yahoo’s complaint feedback loop, filter blocks, were part of the job from day one rather than something bolted on after the first incident.

And it had to keep scaling on the same three people. Bringing on a new sender could not mean rewriting mail policy for that customer, so onboarding had to be configuration. There was no in-house MTA platform to start from either, which meant the stack had to be built, documented and left in a state operators other than its author could run.

The Solution

One path, owned end to end: a message is injected from GoHighLevel, routed to a tenant, put on an egress IP the group owns, handed to the receiving provider’s MX, and then watched all the way back. Every piece below sits somewhere on that line.

Fibre optic patch cables plugged into a high density data centre switch, port indicator lights running in rows across the chassis

Owned iron, and every egress IP accounted for

The platform runs on two dedicated OVH bare-metal KumoMTA deployments rather than on a shared pool somebody else owns. Each node carries its own /24 egress block, held separate from the management IP, and the firewall is written so those egress addresses accept no inbound services at all. That separation is what makes reputation attributable: an address sends, it is not reachable, and what happens to its standing at an inbox provider is a consequence of the mail the platform chose to put on it.

OVH Bare Metal
KumoMTA
Dedicated /24 Egress
Firewall Hardened

A KumoMTA node dashboard showing message count, memory usage, Lua contexts, inbound SMTP transaction latency and the per-hook Lua event rate for smtp.inboxpro.io

Multi-tenant routing as data, not as code

Who sends, from where, and how hard is a lookup rather than a branch. A SASL user resolves to a tenant, a tenant to a tier, a tier to a pool, and a pool to a weighted source IP, with the layouts held as YAML and the credentials in Ansible Vault. That YAML is the source of truth for onboarding, so bringing a new sender on is an entry in a file and a run of the playbook instead of a rewrite of mail policy for that customer. The panels here are the platform answering those lookups live: get_egress_pool, get_egress_source and get_egress_path_config are the hooks this engagement wrote.

SASL → Tenant → Tier → Pool
Weighted Source IPs
Ansible Vault
YAML as Source of Truth

The KumoMTA Executive Deliverability dashboard showing a 98.0% success ratio, ready and scheduled queue depth, inbound connections, node and log health, and throughput by outcome

One screen an operator can actually run the send from

Above the mail tier sits a Prometheus, Grafana, Loki and Alertmanager loop, and above that a set of dashboards written for the job rather than for the metric: an executive deliverability view, warmup control, tenant operations, DNS authentication for SPF, DKIM and DMARC, SMTP and auth security, a firewall audit, and delivery failures pulled out of Loki. The screen here is the top of that stack. Success ratio, queue depth, inbound connections and node health in one place, which is the difference between knowing the platform is healthy and believing it is.

Prometheus & Grafana
Loki
Alertmanager
Purpose-Built Dashboards

The MTA tracking dashboard showing 1.51 million total opens, 991 thousand unique opens, a 65.8 percent unique to total ratio, and open rate broken down by tenant over 24 hours

Tracking and stats that belong to the sender

The engagement also shipped the services around the MTA, because a sender that owns its infrastructure and rents its numbers has only moved the dependency. Open and click tracking runs on HMAC-signed tokens against its own store, with hooks back into the automation platform. A domain stats API exchanges an API key for a JWT and serves Prometheus-backed Postmaster series to whatever asks. Both run under inboxpro.io hostnames on the same estate as the mail, so engagement data and delivery data come from the same place.

Open & Click Tracking
HMAC Tokens
Domain Stats API
API Key → JWT

And the operations around it

Sending infrastructure is not finished when the first message leaves. Six pieces of this engagement exist so that three people can keep running a platform this size, and so that the next three could take it over.

Warmup as a control tower
New addresses and new tenants ramp on a plan rather than on somebody's memory. Warmup has its own dashboard, so where every IP is in its schedule is a thing you look at instead of a thing you reconstruct after a block.
ISP feedback wired in from day one
Google Postmaster Tools, Microsoft SNDS and the Yahoo Senders Hub complaint feedback loop are pulled in continuously, not consulted after an incident. Reputation at each provider is a series on a graph with the rest of the platform.
Failure-classified daily reports
Delivery failures are pulled out of Loki, classified rather than counted, and delivered to Discord and Slack every day. An operator reads what went wrong and to whom instead of grepping raw logs for it.
Authentication under continuous audit
SPF, DKIM and DMARC alignment is monitored per sending domain on its own dashboard. Authentication drifts quietly when domains are added by other people, and drift is the failure mode nothing else surfaces.
A sending estate that is not a target
SMTP and auth security and a UFW firewall audit both have dashboards of their own. Egress addresses expose nothing inbound, credentials live in Vault, and the posture of the estate is something the team can check rather than assume.
Onboarding that is configuration
A new sender is a tenant entry, a tier, a pool and a warmup plan. Because those layouts are the source of truth rather than documentation of it, the platform grows without the mail policy underneath it forking per customer.

A Nortik engineer working at a laptop in a darkened room, lit by the screen

Business Impact

The MTA nodes are in production under inboxpro.io hostnames, one each for sending, tracking, stats and monitoring, with hundreds of configured egress addresses and dozens of tenants running on the primary layout. The group sends its own mail on its own hardware, on addresses whose reputation it built, and the engagement is still live: the MTA repositories are active into August 2026.

What changed for the people who operate it is smaller to describe and larger to live with. A delivery problem arrives as a failure-classified report in Discord or Slack in the morning, and the question after it gets answered on a dashboard built for that question: warmup, tenant operations, Postmaster, SNDS. Nobody starts from raw logs. That is what makes a platform this size tractable for a team this size.

And it is the commercial argument underneath the whole engagement. Because the path is owned from the GoHighLevel inject to the receiving provider’s MX, reputation and capacity are the group’s to manage rather than a vendor’s to allocate, and the cost of a message is the cost of running the estate. That is the offer its customers are moving onto InboxPro for: better placement than the shared pools they came from, at a lower price than the pools charged them for it.