Guest Post: The Race to the Bottom Runs Straight Past the Inbox

Editor's note: Today I've invited a contribution from Jakub Olexa, CEO of Mailkit and Omnivery. Jakub's a good guy, part of the collaborative spirit that works together to protect the email ecosystem from within, and I was curious about and intrigued by what he's doing with Omnivery – so I invited him to share thoughts and details. Enjoy! -- Al Iverson

I've spent close to twenty years in email, most of it running Mailkit, an ESP I started in the Czech Republic - long enough to watch the industry take a wrong turn, and to care enough about it that I started a second company, Omnivery, to push back on it.

The wrong turn is the race to the bottom.

We commoditized the most important thing we run

Somewhere along the way, the industry decided that email is a commodity to be priced per thousand. Open any sending provider's homepage and the conversation is about the same three things: volume, price, and how fast you can sign up. Free tier, credit card optional, sending in five minutes. The entire pitch is built around removing friction between a stranger and a live sending IP.

I understand how we got here. Volume is easy to measure, easy to compare, and easy to sell. "Cheaper per thousand" fits on a landing page. But it has quietly trained the whole market to treat a password reset the same way it treats a promotional blast - as a message, a unit, a line item - when the two things could not be more different in what they actually carry.

Because here's what we've lost sight of while competing on price: email stopped being a marketing channel a long time ago. It became infrastructure.

Communication is now business continuity

Think about what actually moves through a sending platform on any given day. A verification code that stands between a customer and their own account. A fraud alert that's the only thing between someone and a drained balance. A payment confirmation. A shipping update. An appointment reminder that determines whether a clinic slot gets used or wasted. A one-time password without which there is no secure login at all.

None of those are messages in the way a newsletter is a message. Each one is a promise moving through a system. When it arrives on time, the customer feels nothing - which is exactly right, because trust is supposed to be invisible. When it fails, the customer doesn't think "the SMTP relay had a bad night" or "the DMARC record was misaligned." They think the bank failed them. The retailer failed them. The hospital failed them. They blame the brand they trusted, never the infrastructure they never see.

That's the shift I think a lot of the industry has missed. For most digital businesses, communication is no longer downstream of the experience. It is the experience. Without the code, there's no login. Without the alert, there's no protection. Take the email away and large parts of the product simply cease to function. That makes deliverability a business-continuity problem, not a marketing-ops one.

And business continuity is not something you want running on the cheapest possible bid.

The cost of failure is hidden, which is why nobody budgets for it

The reason the race to the bottom works - the reason it's so hard to resist - is that the price of sending is visible and the cost of failure is not. The invoice from your provider shows up every month in one clean number. The cost of a delayed OTP shows up somewhere else entirely: as an abandoned signup, a support ticket, a chargeback, a churned customer, a fraud loss, a one-star review. Those costs are real and often far larger, but they're scattered across five other departments' budgets, so no one connects them back to the decision to save a few cents per thousand.

So companies optimize the number they can see and quietly absorb the losses they can't. A retailer saves on sending and spends triple that on customer service during peak season when order confirmations don't land. A fintech shaves its email budget and eats the fraud exposure when alerts arrive late. The savings are obvious. The damage is disguised.

Once you've been on the receiving end of email - and I have, I ran a freemail service with half a million mailboxes before I ever built a sending platform - you stop asking "what's the cheapest way to send this?" and start asking "what does it cost when this fails?" For a promotional email, failure is tolerable. For the messages that carry identity, money, or health, failure changes the relationship. That question is the one Omnivery is built around, and it's the reason we made choices that look, on a pricing page, like disadvantages.

Why the "disadvantages" are the point

We don't let just anyone sign up. There's no free tier, no instant self-service on-ramp to a warm IP. Every customer is vetted before they get a contract, and every sending domain is approved before it goes live. In a market that competes on frictionlessness, deliberately adding friction sounds insane. But reputation in this business is collective - one bad sender in a shared neighborhood degrades deliverability for everyone standing next to them, first at the IP level, then the network, eventually the whole AS. Vetting isn't bureaucracy. It's how we protect the senders who actually deserve to be trusted from the ones who don't.

We also run our own infrastructure. Not "dedicated servers in someone else's cloud" - actual independent infrastructure, from the routers and the fiber between our data centers down to individual machines. We never boarded the cloud train, which at the time looked like stubbornness and now looks like foresight. It means when a financial institution asks us who our sub-processors are, the honest answer is: there aren't any. It means we can tell a customer exactly where their data physically sits, and set up as many storage locations as they need - including on their own premises. For the kind of customer whose communication cannot fail, "we don't actually know which region your data landed in" is not an acceptable answer, and increasingly they know it.

None of this makes us cheaper. All of it makes us the opposite of a commodity. That was the whole idea.

We built a whole industry to work around a problem we could have prevented

Here's the part that fascinates me the most, in the way a slow-motion mistake fascinates us. The race to the bottom didn't just push prices down. It spawned an entire industry devoted to managing the damage that open doors create.

Follow the logic. If you let anyone sign up, you inevitably let bad actors in. So now you need machinery to contain them: senders sliced into separate IP pools and sub-pools so one bad neighbor doesn't poison the rest, elaborate warmup schemes, reputation monitoring, suppression tooling, throttling, quarantine flows. And on top of all that, a professional-services layer - deliverability consulting, managed onboarding, remediation packages - very often sold as an upsell, to help senders climb out of the holes the open-door policy dropped them into in the first place. A good chunk of the modern deliverability-services economy exists to clean up a mess that better gatekeeping would have prevented.

Dedicated IPs are the cleanest example of how a technical fix quietly becomes a revenue stream. Isolating a sender's reputation on its own IP is a legitimate tool — it started as exactly that, a way to separate one sender's reputation from everyone else's. But somewhere along the line it turned into a default upsell, a monthly line item marketed as the serious sender's choice and sold to almost anyone. There's nothing wrong with a dedicated IP when a sender genuinely needs one. Most don't. A dedicated IP only builds and holds reputation on steady, predictable volume, and the majority of senders simply don't have a consistent enough sending pattern to keep one warm. Put them on a dedicated IP anyway and you've often made their deliverability worse, not better — while charging them extra for the privilege. For most senders, a clean shared pool of well-vetted neighbors will serve them far better than an underfed IP of their own.

I don't think the solution is more sophisticated containment. It's the opposite instinct entirely: close the door on the bad actors, and help the ones who genuinely want to get better. Vet at the front, keep the network pristine, and you spend far less of your life firefighting reputation problems - because you never let them onto the platform.

That's the logic behind our strict vetting, and it's also why our hands-on deliverability support is simply part of the service, not a premium tier. When your network is clean, helping a good sender do email properly isn't a costly rescue operation you have to charge extra for. It's just what the relationship is for. I'd rather spend that effort making a good sender better than selling remediation to a bad one.

Then AI showed up and raised the stakes

Everything I've described is getting more urgent, not less, because of AI - and here I want to be careful, because AI in email is drowning in hype and I don't want to add to it.

AI is going to dramatically increase the volume, speed, and complexity of what flows through sending systems. AI Agents will trigger messages. Applications will communicate autonomously. Journeys will adapt in real time. That's coming whether we like it or not, and it makes trustworthy infrastructure more important, because the tolerance for bad data drops to zero when machines are making the decisions.

This is the part the industry needs to sit with. Everyone is racing to bolt AI onto engagement data - opens, clicks, "engagement scores" - to automate targeting and sending decisions. But we all know those signals are polluted. Opens are distorted by privacy proxies. Clicks are fired by security scanners and bots that look human to any system not built to tell the difference. If you train an intelligent system on that, you get confident, automated, wrong decisions at scale. Intelligence built on illusion is worse than no intelligence at all, because it fails faster and with more certainty.

So yes, we use AI. But I want to be precise about how, because I think the deliverability community in particular will understand the distinction. We use AI to increase our own efficiency and to chase the long tail - the patterns across millions of sends that no human has time to eyeball. What we do not do is use it to replace the humans.

Deliverability needs more humans, not fewer

This is the conviction I'd most want to leave with the readers of this blog, because it runs against the direction almost everyone else is heading.

Deliverability is, at its core, a trust-and-relationships problem. It always has been. Trust between senders and mailbox providers. Relationships that get built at conferences and in postmaster channels and over years of behaving well. You cannot automate your way into a good reputation, and you cannot chatbot your way out of an incident. When something goes wrong at three in the morning during peak season, what matters is whether a competent human who knows your setup is watching and picks up the phone.

And yet I keep watching companies do the opposite. Layoff announcements land, and the deliverability people are among the first out the door - treated as a cost center, a nice-to-have, overhead you trim when the quarter looks rough. It's painful to watch, because in almost every one of those businesses the deliverability team is the single most important line on the payroll for whether the company actually succeeds. They're the reason the revenue email reaches the inbox instead of the spam folder. Cut them and nobody notices for a quarter or two - right up until the reputation erodes, the inbox placement collapses, and the people who could have prevented it are gone. You don't feel their absence immediately. You feel it exactly when it's most expensive to fix.

So while much of the market is using AI as a reason to shrink its human teams, we're doing the opposite. We're expanding ours. We're hiring more technical account managers whose actual job is to talk to customers on a regular basis - not to upsell them, but to look at how they're sending, catch problems before they become incidents, and find ways to help. The goal is that a customer never discovers an issue before we do. AI helps those people see more and act earlier. It doesn't replace them, because the thing they're actually building - trust - is not a thing a model can hold on your behalf.

I think this is where the industry's fork in the road really is. One path uses automation to send more, cheaper, to more strangers, faster. The other uses it to serve fewer, better, with more human judgment in the loop. The first path is the race to the bottom, and it ends where races to the bottom always end.

This is really about responsibility

What I want isn't a smaller market. It's a more responsible one - providers that treat critical communication like the infrastructure it has become, that compete on whether you can be relied on rather than on how little you can charge, and that keep humans in the loop precisely because trust is a human thing.

I didn't start Omnivery because the world needed another place to send email. I started it because the messages that hold the digital economy together deserve infrastructure built for the reality of their importance, and too much of the market had decided that was a race not worth running. When communication matters, it has to work. Not usually. Not when conditions are favorable. When it matters.

And no, you can't put it on a price-comparison spreadsheet

I'll be blunt about the commercial reality, because it follows directly from everything above: Omnivery can't be judged against other providers on price alone, because price is a single line in a much larger picture.

Start with migration - usually the thing that keeps people tied to a cheaper provider. We didn't build a proprietary API and dare you to rewrite your integration to leave it. Our API is compatible with the ones you're probably already using: SendGrid, Mailgun, SparkPost. In most cases, moving to Omnivery means changing an endpoint and a set of credentials, not touching a line of code. Plain old SMTP works too. We'd rather earn the business than trap it.

Then there's everything a cost-per-thousand figure can't show you. We run our own infrastructure end to end, which means no third-party sub-processors and full control over where your data physically lives - we can stand up data locations wherever you need them, down to your own premises. For senders handling sensitive data, we offer full PII obfuscation: identifiable data is stripped once a message goes out, before anything reaches your webhooks. Message content isn't stored at all. And we hold the certifications regulated customers actually ask for - ISO 27001, ISO 27701, and HIPAA - because for those buyers "we're compliant" is a claim, and a certificate is proof.

None of that fits in a per-thousand comparison, and that's rather the point. When you're buying infrastructure for communication that cannot fail, the cheapest quote is almost never the full picture. More often it's the most expensive decision you'll make - just billed to a different department.

So I'll end not with a hard sell but with an invitation. If you're already sending through SendGrid, Mailgun, or SparkPost, seeing the difference isn't a migration project - it's an afternoon. Point your integration at a new endpoint, swap the credentials, and you're sending. No rewrite, no rip-and-replace, no months-long integration to schedule. The switch really is that small.

What rides on it isn't. Every one of those messages - the reset, the code, the alert, the receipt - is a promise your customer is trusting you to keep. The move takes an afternoon. The trust took years to earn. It's worth putting on infrastructure built to protect it.

-- Jakub Olexa, founder & CEO, Omnivery (and still Mailkit)