Email infrastructure
KumoMTA serversOpen-source MTA, Rust + Lua, no per-message feesPowerMTA serversLicensed, VirtualMTA pools, vendor supportDeliverabilityWarm-up, DMARC alignment, feedback loopsServers
Bare metal — AMD EPYCSingle-tenant Turin / Genoa, up to 192 coresGPU & AI serversNVIDIA Blackwell B200 / H200, PCIe Gen5VPSPer-core instances on the same EPYC hostsCloud & network
Cloud computeHourly instances, snapshots, NVMe Gen5DDoS protectionEdge absorption included on every serverNetwork & regionsAmsterdam · Frankfurt · London · AshburnEmail infrastructure · Overview
Email infrastructure is the stack that carries mail from your application to the inbox: the mail transfer agent that queues and sends, the IP pools it sends from, the SPF, DKIM, and DMARC authentication, the network beneath it, and the monitoring that guards reputation. VV Internet Hosting hosts and operates this stack on single-tenant servers — most often KumoMTA, sometimes PowerMTA — and gives honest build-versus-buy advice, including when a managed service or plain Postfix is the better choice.
In short
It is everything between your application pressing send and a message arriving in someone's inbox. People often picture only the mail server, but the server is one layer of five, and a weakness in any of them shows up as mail in the spam folder. The mail transfer agent queues messages and delivers them over SMTP. The IP addresses and pools give that mail its sending identity and reputation. Authentication — SPF, DKIM, and DMARC — proves the mail is really from you. The network underneath provides clean address space, reverse DNS, and protection from attack. And monitoring watches complaint rates, bounces, and provider reputation so problems are caught while they are still small.
A managed email service folds all five layers into a single monthly bill and hides the machinery. Running your own means owning each layer deliberately: choosing and tuning the MTA, warming the IPs, publishing and enforcing authentication, and standing up the monitoring. Neither approach is universally right, which is the whole point of the decision below. What matters is matching the stack to your volume, your team, and the kind of mail you send.
The layers are not independent. A clean IP with broken authentication still lands in spam; perfect authentication on a cold, unwarmed IP still gets throttled; and a flawless send with no monitoring means you learn about a reputation problem from your customers rather than your dashboards. Treating the stack as one system, each layer visible to the next, is what separates infrastructure that holds up from a pile of correctly configured parts.
The honest version starts with two numbers and one question: how much do you send, how fast is that growing, and do you have someone who can operate a mail server. A managed service bundles four things you would otherwise assemble yourself — MTA software, IP infrastructure, deliverability operations, and a UI/analytics layer — all in one bill. That bundle is excellent value until your volume makes the per-message price sting, or until you need control the service will not give you.
The trap is counting only the sticker price. The VPS is the sticker price; the real cost is operations time. Operators routinely undercount the categories an ESP absorbs. Self-hosting tends to pay off from roughly 50,000 messages/month with basic Linux skills and a small, steady maintenance commitment. Below roughly 25,000 messages/month, or with no technical staff and no tolerance for self-managed incidents, a managed service is the better call. At the top end the maths inverts: At high volume the gap widens sharply — self-hosting can run several times cheaper per message than a full-featured platform. To put a real figure on it, At ~1.4M messages/month a well-run self-hosted MTA realistically costs on the order of a few thousand euros a month all-in, dominated by the fractional engineer who keeps it healthy, not the software.
One more input changed the calculus recently: Microsoft's May 2025 bulk-sender enforcement, plus PCI DSS v4.0 and DORA taking effect in 2025, raised the operational and compliance stakes around how email infrastructure is run. For some operators that tips the decision toward owning the stack on known, single-tenant hardware in a chosen region.
Two softer factors deserve weight alongside the numbers. The first is lock-in: a managed platform holds your sending reputation and your templates, and moving off it later is a project of its own. The second is price drift — several large providers have raised prices after acquisitions, so the plan you sign up for is not always the plan you keep. Owning the stack trades that uncertainty for operational work; buying trades operational work for a price someone else sets. Which trade fits depends on how much each kind of risk costs you.
More than standing it up. The build is a project with an end; operations is a practice that does not stop. Day to day it means keeping the host patched, watching the queues and deferral rates, holding pace when a provider pushes back, processing bounces and complaints into your suppression list, and being there when an upstream provider does something strange on a Friday evening. None of it is dramatic, but it is constant, and it is the part teams underestimate when they price a self-hosted stack against a managed bill.
A rough rule of thumb is worth knowing: well above a million messages a month, keeping an MTA healthy takes a fraction of a skilled engineer's time — not a whole role, but not nothing, and the incidents do not arrive on a schedule. That is exactly why a self-hosted-but-operated model exists, and it is the one we offer: you get the cost and control of owning the stack without the pager landing on your team. When you would rather not think about a reverse-DNS record or a certificate that quietly expired at two in the morning, that is the work we take on, and it is most of what you are really paying for when you host with us rather than rent capacity.
The engines
In 2026 the self-hosted-versus-managed and open-versus-commercial choices turn on operating model, not raw capability. KumoMTA matched the commercial engines on throughput and shaping, so the question is who runs it, how mature the ecosystem must be, and where the volume and compliance line sits.
General-purpose sending and relays; the Linux default.
StrengthsFree, ubiquitous, well-documented; covers the large majority of sending needs with modest hardware.
Watch-outsNo native per-ISP throttling, bounce classification, feedback-loop processing, or per-campaign reporting — those need external tooling at marketing scale.
High-volume senders and platforms that want source control without a license.
StrengthsBuilt by ex-PowerMTA engineers; built-in traffic shaping, per-tenant queuing, HTTP API and Lua policy; Apache-2.0, no license fee; paid support available.
Watch-outsYounger ecosystem and smaller support network than PowerMTA; Lua policy is a real, if modest, learning curve.
ESPs and enterprises that want a supported commercial product.
StrengthsIndustry standard; mature VirtualMTA model, deep per-ISP controls, 24×7 vendor support, established services ecosystem.
Watch-outsLicense runs roughly USD 3,000–10,000+ per year and scales with sending; owned by Bird after Port25 and SparkPost.
ESPs, ISPs and security-sensitive operators wanting policy as code.
StrengthsComposable, scriptable mail flows with strong security, filtering and analytics; multi-tenant policy control.
Watch-outsCommercial; aimed at platform operators rather than a single sender.
Teams that want an ESP-style platform (UI, API, webhooks, IP pools) they host themselves.
StrengthsPlatform-first: web UI, REST API, message logs and IP pools on your own servers; pairs with a tuned MTA underneath.
Watch-outsYou operate the platform and its deliverability; it is infrastructure, not a hands-off service.
Often enough that we will recommend one when it fits. If you send modest volume, have no one to operate a server, or need a marketing UI and templates more than you need control, a managed provider is the better call — and we would rather point you there than sell you a server you do not need. The options below are not ours to sell; they are here so the decision is honest.
Lowest per-message (around USD 0.10 per 1,000) plus a small monthly fee per dedicated IP; pure infrastructure, you build analytics, bounce handling and suppression yourself.
Best forCost-conscious high-volume senders with engineering capacity, often above ~500k/month.
Tiered monthly plans, roughly tens to several hundred dollars; bundles API, templates, analytics and deliverability tooling.
Best forTeams that want a complete platform and support over raw cost efficiency.
Developer-oriented tiered plans.
Best forDeveloper teams wanting a strong API with platform features.
Premium per-volume pricing focused on transactional reliability.
Best forCritical transactional mail where inbox speed matters most; not the cheapest for bulk marketing.
Free tiers and budget-friendly plans; modern APIs or built-in marketing tooling.
Best forSmaller senders and developer-first teams getting started.
The pattern under all of this: a managed service sells you capacity and convenience and hides the MTA; self-hosting hands you the engine and the responsibility. Neither is a moral choice. It is an operating decision, and it changes as you grow.
When you do host with us, the five layers stop being your problem to assemble and become ours to operate. The MTA is KumoMTA or PowerMTA on single-tenant AMD EPYC hardware, tuned to your sending profile. The IP pools are laid out by stream, each bound to a dedicated address with correct reverse DNS, and warmed with you. Authentication and deliverability run as an ongoing discipline rather than a launch checklist. The network provides clean ranges and always-on DDoS absorption. And monitoring ties it together, feeding delivery, bounce, and complaint events into your own systems so your view matches ours.
Monitoring deserves a closer look, because it is where most reputation problems are caught or missed. We watch Google Postmaster Tools and Microsoft's sender data for domain and IP reputation, the feedback loops for complaints, blocklists for early listings, and inbox-placement signals for where mail actually arrives. When a number drifts, we trace it to the stream that caused it rather than answer with a blunt slowdown that punishes the mail that was doing fine.
Reference architecture
Your application hands mail to the MTA, which assigns it to a pool by stream, signs it, and paces delivery to each provider. Events flow back to your systems and to monitoring. The principle that holds the whole design together is stream isolation: transactional, marketing, and cold mail never share a reputation.
# reference layout — stream isolation by reputation
domains:
tx.example.com # transactional · must arrive
mail.example.com # marketing · high volume
reach.example.com # cold / re-engagement · isolated
pools:
- name: transactional
mta: kumomta
ips: [ 198.51.100.21 ]
note: "small, always warm, never shares with marketing"
- name: marketing
mta: kumomta
ips: [ 198.51.100.40, 198.51.100.41 ]
- name: outreach
mta: kumomta
ips: [ 203.0.113.10 ]
note: "separate reputation; a bad day here cannot touch receipts"We host and operate self-hosted infrastructure, so the temptation would be to recommend it to everyone. We do not, because a server that does not fit you becomes a problem we both regret. The conversation starts with your real numbers — volume, growth, traffic mix, the team you have, the compliance you carry — and runs against the same factors we weigh internally. If a managed service is cheaper once the operational hours are counted, we will say so. If a plain Postfix relay covers your low-volume, low-frequency list, we will set that up rather than sell you a marketing MTA you will not use.
Where self-hosting genuinely wins — real volume, a need for control or data residency, an economic case that holds once everything is counted — we build it on single-tenant hardware, choose the MTA that fits, and operate it so the responsibility does not land back on you. The recommendation is meant to fit your situation rather than our catalogue, and because we run both KumoMTA and PowerMTA, we are not talking our book when we point you at one or the other.
The decision is not permanent either. What is right at a hundred thousand messages a month can be wrong at ten million, and the reverse happens when volume falls. We revisit the call as your numbers move, because the honest answer this quarter should not bind you to the wrong shape next year. Re-running the maths is part of operating the stack, not a separate sales conversation.
The decision is rarely all or nothing. A common, sensible shape: premium transactional (e.g. Postmark) for must-arrive mail, self-hosted or low-cost infrastructure for high-volume marketing, and an isolated stream for cold or re-engagement. A setup like that keeps the mail that must arrive on the most reliable path, spends the savings where volume is highest, and quarantines the riskiest traffic on its own reputation. We are glad to operate the self-hosted parts of a hybrid and to wire the monitoring so the whole thing reports into one place, even where another provider carries a slice of the volume.
The thread through all of it is honesty about where the value sits. The goal is mail that lands and a bill that makes sense, measured against your own numbers — not the longest possible invoice. When that means a server, we build it; when it means a service, we will tell you; and when it means a bit of both, we will help you draw the line in the right place.
One caution on hybrids: more providers means more places to watch, so the monitoring has to be unified or the split quietly costs you the visibility it was meant to protect. We wire the events from every stream — ours and any managed slice — into one view, so the architecture stays legible no matter how many parts it has.
Questions
The build-versus-buy questions we hear most.
It is the full stack that gets mail from your application to the inbox: the mail transfer agent that queues and sends, the IP addresses and pools it sends from, the SPF, DKIM and DMARC authentication, the network and DDoS protection underneath, and the monitoring that watches reputation. A managed email service bundles all of it into one bill; running your own means assembling and operating each layer.
It comes down to volume and whether you have people to operate it. Below roughly 25,000 messages a month, or with no technical staff, a managed service is almost always cheaper once you count the hours. From around 50,000 a month with basic operations capacity, self-hosting starts to pay off, and at high volume it can run several times cheaper per message — provided someone keeps it healthy.
Under about 500,000 messages a day, a well-tuned Postfix handles it. From there to a few million a day, KumoMTA is usually the best seat: open-source, no license, with traffic shaping and per-tenant queuing built in. Above that, or where a vendor support contract is required, PowerMTA remains the established commercial choice. We host and operate KumoMTA and PowerMTA and will tell you honestly which fits.
On throughput and traffic shaping, the gap has closed — KumoMTA was built by former PowerMTA engineers and matches it for most high-volume work. The remaining differences are ecosystem maturity and support model: PowerMTA has decades of tooling and a wide partner network, while KumoMTA trades some of that for source access and no license fee.
More than the server. A VPS is a few euros a month, but the real cost is operations — patching, monitoring, warm-up, and the occasional incident. At around 1.4 million messages a month, a well-run self-hosted setup realistically costs a few thousand euros monthly all-in, most of it the fractional engineer keeping it healthy rather than the software, which can be free.
Yes, and it is often the smartest shape. Many senders keep critical transactional mail on a premium service for reliability, run high-volume marketing on self-hosted infrastructure for cost, and isolate cold or re-engagement traffic on a separate reputation. We are happy to operate the self-hosted side of a hybrid like that.
No. We host and operate self-hosted infrastructure — KumoMTA and PowerMTA on single-tenant servers. When a managed provider is genuinely the better fit for your volume or team, we will say so plainly, even though it is not what we sell.
Running your own infrastructure on single-tenant hardware in a known region gives you control over where data sits and how it is handled, which matters under regimes like PCI DSS and DORA. We place servers in the region you need and keep the configuration and logs yours.
We will run your real numbers against the same factors we weigh internally and give you a straight build-versus-buy answer — server, service, or a sensible hybrid.