My friend Dan Stevens (who founded email verification platform Kickbox and hired me there once upon a time) has rejoined the email community! After seeing him announce unMTA, I invited him to author a guest post here to share thoughts about his new venture and what his goals are. Take it away, Dan!
Here's what pisses me off about traditional ESP pricing: it's built for the generic sender… circa 2009. If there are two things I've learned in my years in email, it's that not all senders are the same, and it's not 2009 anymore.
Seventeen years ago, the cost of operating an ESP at scale was legitimately expensive. Hardware was expensive. Bandwidth was expensive. The pricing models reflected that. But infrastructure costs have come down dramatically, and the pricing hasn't followed. The margins on per-message fees at most ESPs are, frankly, obscene.
The worst part is what that model actually subsidizes. Running a shared sending platform means dealing with senders who cut corners, buy lists, or "accidentally" mail a segment they shouldn't have. That costs the platform in reputation, in remediation, in support. And who pays for that? The good senders, through inflated per-message pricing that has to cover the operational cost of cleaning up after the bad ones. You're not just paying to send your mail. You're paying for the platform's abuse desk.
Meanwhile, shared sending infrastructure means your reputation is tangled up with whoever else happens to be on the same IPs. You can do everything right and still take a deliverability hit because your neighbor decided to blast a purchased list on a Tuesday afternoon.
These aren't new complaints. But I got tired of just complaining about them.
Infrastructure is the hard part
A Mail Transfer Agent (MTA), even a great one, is just an MTA. It's the infrastructure around it that transforms it into an ESP.
unMTA is built on KumoMTA, which handles the core MTA piece incredibly well. It's fast, flexible, and free. But a great MTA and a full ESP are still very different things.
BYOIP and BGP. PTR records across hundreds of IPs. DKIM management. IPv6 configuration. Per-customer isolation. IP warming. Bounce processing. Monitoring. DNS architecture for SPF, DKIM, and DMARC. Feedback loop processing. The list goes on, and every item on it is load-bearing. Miss one and your deliverability suffers.
Email infrastructure is a pain no matter how you slice it. I've done it. It's a full-time job, and that's if you already know what you're doing. If you're a sender evaluating build vs. buy, the build side is almost always more expensive and time-consuming than you expect going in. I've watched teams burn six figures and six months trying to stand up what they thought would be a straightforward sending operation.
unMTA sits on the buy side of that equation. You get the control and isolation of running your own infrastructure without the operational burden of actually running it.
What unMTA is
Every unMTA customer gets their own dedicated MTA (or MTA cluster), running on modern, fast hardware and networks.
The IPs are unMTA's, purpose-acquired address space, not inherited from some previous webhost tenant. Full IPv6 support. Proper authentication configured from the start. Nobody else is on your IPs.
That said, dedicated IPs within a shared CIDR aren't invisible to each other. Mailbox providers evaluate reputation at the range level, not just the individual IP. Dedicated IPs are better isolation than a shared sending pool, but they're not the same as having your own ASN and disconnected address space. This is why we're choosy about who we let on the network. The unMTA team manages and monitors who sends on our infrastructure the same way we manage the network itself. If your next-door neighbor is blasting a crypto scam, dedicated IPs don't help, so we don't let that neighbor on in the first place.
The pricing is flat-rate, unmetered. Just like it would be if you were running this in your own data center: nobody is charging you per message. Your throughput is limited by the hardware (which is fast) and the speed the receiving mail servers will accept your mail. That's it.
Who this is for
unMTA is for senders doing hundreds of thousands to hundreds of millions of messages per month who've hit the ceiling of shared infrastructure. Maybe you're on a major ESP and you're tired of your reputation being influenced by other senders on the platform. Maybe you've looked at building your own and realized the operational cost doesn't make sense. Maybe you're an agency and you need to put clients on isolated infrastructure without standing it up yourself.
This is not a platform for lead gen. It's not for cold outreach to purchased lists. It's not for anyone who thinks "unmetered" means "send whatever I want to whoever I want." That's not us being picky for the sake of it. It's a direct consequence of the architecture.
What I expect to learn
The unmetered model is something I believe in, and it's also something I know could be a Pandora's box if not managed carefully.
When you remove the per-message cost lever, you change sender behavior. Much of that change is positive. But some of it requires guardrails. Unmetered doesn't mean unmanaged. We're building this for senders who already have good practices, not for people who need the threat of a bill to keep them honest.
I'm also curious what the market teaches me about where the real pain points are. I've been in this industry long enough to have strong opinions, but also long enough to know that strong opinions need to get tested against reality. Some of my assumptions will be right. Some won't. I'd rather build in the open and adapt than pretend I've got it all figured out from day one.
If any of this resonates, I'd love to hear from you. You can find us at unmta.com.
My friend Dan Stevens (who founded email verification platform Kickbox and hired me there once upon a time) has rejoined the email community! After seeing him announce unMTA, I invited him to author a guest post here to share thoughts about his new venture and what his goals are. Take it away, Dan!
Here's what pisses me off about traditional ESP pricing: it's built for the generic sender… circa 2009. If there are two things I've learned in my years in email, it's that not all senders are the same, and it's not 2009 anymore.
Seventeen years ago, the cost of operating an ESP at scale was legitimately expensive. Hardware was expensive. Bandwidth was expensive. The pricing models reflected that. But infrastructure costs have come down dramatically, and the pricing hasn't followed. The margins on per-message fees at most ESPs are, frankly, obscene.
The worst part is what that model actually subsidizes. Running a shared sending platform means dealing with senders who cut corners, buy lists, or "accidentally" mail a segment they shouldn't have. That costs the platform in reputation, in remediation, in support. And who pays for that? The good senders, through inflated per-message pricing that has to cover the operational cost of cleaning up after the bad ones. You're not just paying to send your mail. You're paying for the platform's abuse desk.
Meanwhile, shared sending infrastructure means your reputation is tangled up with whoever else happens to be on the same IPs. You can do everything right and still take a deliverability hit because your neighbor decided to blast a purchased list on a Tuesday afternoon.
These aren't new complaints. But I got tired of just complaining about them.
Infrastructure is the hard part
A Mail Transfer Agent (MTA), even a great one, is just an MTA. It's the infrastructure around it that transforms it into an ESP.unMTA is built on KumoMTA, which handles the core MTA piece incredibly well. It's fast, flexible, and free. But a great MTA and a full ESP are still very different things.
BYOIP and BGP. PTR records across hundreds of IPs. DKIM management. IPv6 configuration. Per-customer isolation. IP warming. Bounce processing. Monitoring. DNS architecture for SPF, DKIM, and DMARC. Feedback loop processing. The list goes on, and every item on it is load-bearing. Miss one and your deliverability suffers.
Email infrastructure is a pain no matter how you slice it. I've done it. It's a full-time job, and that's if you already know what you're doing. If you're a sender evaluating build vs. buy, the build side is almost always more expensive and time-consuming than you expect going in. I've watched teams burn six figures and six months trying to stand up what they thought would be a straightforward sending operation.
unMTA sits on the buy side of that equation. You get the control and isolation of running your own infrastructure without the operational burden of actually running it.
What unMTA is
Every unMTA customer gets their own dedicated MTA (or MTA cluster), running on modern, fast hardware and networks.The IPs are unMTA's, purpose-acquired address space, not inherited from some previous webhost tenant. Full IPv6 support. Proper authentication configured from the start. Nobody else is on your IPs.
That said, dedicated IPs within a shared CIDR aren't invisible to each other. Mailbox providers evaluate reputation at the range level, not just the individual IP. Dedicated IPs are better isolation than a shared sending pool, but they're not the same as having your own ASN and disconnected address space. This is why we're choosy about who we let on the network. The unMTA team manages and monitors who sends on our infrastructure the same way we manage the network itself. If your next-door neighbor is blasting a crypto scam, dedicated IPs don't help, so we don't let that neighbor on in the first place.
The pricing is flat-rate, unmetered. Just like it would be if you were running this in your own data center: nobody is charging you per message. Your throughput is limited by the hardware (which is fast) and the speed the receiving mail servers will accept your mail. That's it.
Who this is for
unMTA is for senders doing hundreds of thousands to hundreds of millions of messages per month who've hit the ceiling of shared infrastructure. Maybe you're on a major ESP and you're tired of your reputation being influenced by other senders on the platform. Maybe you've looked at building your own and realized the operational cost doesn't make sense. Maybe you're an agency and you need to put clients on isolated infrastructure without standing it up yourself.This is not a platform for lead gen. It's not for cold outreach to purchased lists. It's not for anyone who thinks "unmetered" means "send whatever I want to whoever I want." That's not us being picky for the sake of it. It's a direct consequence of the architecture.
What I expect to learn
The unmetered model is something I believe in, and it's also something I know could be a Pandora's box if not managed carefully.When you remove the per-message cost lever, you change sender behavior. Much of that change is positive. But some of it requires guardrails. Unmetered doesn't mean unmanaged. We're building this for senders who already have good practices, not for people who need the threat of a bill to keep them honest.
I'm also curious what the market teaches me about where the real pain points are. I've been in this industry long enough to have strong opinions, but also long enough to know that strong opinions need to get tested against reality. Some of my assumptions will be right. Some won't. I'd rather build in the open and adapt than pretend I've got it all figured out from day one.
If any of this resonates, I'd love to hear from you. You can find us at unmta.com.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.