Contents
- The frame: why this decision is decided wrong
- What the build spreadsheet actually contains
- The four invisible costs
- The PowerMTA license, in proportion
- Reputation as an unbooked asset
- The staffing question, priced honestly
- The cost of being wrong
- Where the crossover actually sits
- When building is the right answer
- A decision procedure that holds up
- Frequently asked questions
The frame: why this decision is decided wrong
Build versus buy is one of the most common questions a growing sender asks, and it is one of the most consistently mis-answered. The reason is not that the people answering it are careless. It is that the question is almost always framed as a comparison of invoices, and email infrastructure is one of the few systems where the invoices are the least important part of the cost.
A team sits down, opens a spreadsheet, and lists what a build would require. A server. A block of IP addresses. A PowerMTA license. A monitoring tool. They add it up, compare the annual total against a managed infrastructure quote, and the build usually wins on the page. The numbers are real. The conclusion is frequently wrong, because the spreadsheet is not measuring the thing that determines the outcome. It is measuring the things that happen to have invoices attached.
This note is a cost analysis written from the operator's side of the decision. It does not argue that buying is always correct — it is not, and there is a clear class of senders for whom building is the right call. It argues that the decision has to be made against the full cost surface, and that the full cost surface includes four large items the spreadsheet structurally cannot see. Get those four items onto the page, priced honestly, and the decision usually answers itself.
What the build spreadsheet actually contains
Start with what the build analysis does capture, because it captures it well. These are the line items that have a vendor, an invoice, and a renewal date, and a competent team will estimate them accurately.
| Line item | What it covers | Roughly |
|---|---|---|
| Dedicated server | One capable Linux host; PowerMTA has a small hardware footprint | Modest monthly |
| Dedicated IP addresses | One or several IPs, depending on volume and segmentation | Small monthly per IP |
| PowerMTA license | Commercial MTA software, annual or volume-based | From ~8,000 USD/yr |
| Monitoring & logging | Metrics, alerting, log retention | Small monthly |
| DNS & domains | Sending domains, SPF/DKIM/DMARC records | Negligible |
Every one of these is genuine, and a careful build analysis will not get them badly wrong. The server is cheap relative to expectations, because PowerMTA is efficient and a single well-specified host carries a great deal of volume. The IPs are inexpensive per unit. The license is the largest invoiced item. None of this is where the decision is decided.
Notice what the table shares: every row has a counterparty who sends a bill. That is precisely the selection bias. The spreadsheet contains the costs that someone else remembers to charge you for, and omits the costs that no one invoices because they are absorbed inside your own organisation. Those uninvoiced costs are the larger half of the picture, and they are the half this note is about.
If a cost has no external invoice, a build analysis tends not to record it — not from dishonesty, but because spreadsheets are built from quotes, and uninvoiced costs produce no quote. Salaried engineering time, warming latency, and reputation risk are the three biggest, and all three are invisible by construction.
The four invisible costs
Four costs sit outside the invoice surface and, taken together, usually outweigh everything inside it. They are worth naming precisely, because naming them is what gets them onto the page.
One: the operator. Email infrastructure is not install-and-forget. It needs someone who can configure a virtual-MTA topology, read accounting logs, interpret a rise in deferrals, distinguish a receiver-side throttle from a reputation problem, and act before a temporary signal becomes a permanent one. That person has a salary, and the fraction of that salary spent on the email platform is a real cost of the build even though no vendor invoices it.
Two: warming latency. A new IP cannot send at full volume on day one. Reputation is established gradually, over a warming period of several weeks, during which the infrastructure carries far less than its eventual capacity. The build does not earn its keep during warming. That delay is a cost — an opportunity cost measured in deliverable volume not sent — and it is incurred every time a new IP is introduced, not only once.
Three: reputation risk. A sender's reputation with the major receivers is an asset. It takes weeks to build and can be damaged in a single bad send. When you build, you own that asset and you own the downside. A configuration mistake, a list hygiene lapse, a complaint spike — any of these can cost weeks of recovery. The expected value of that risk belongs on the page.
Four: opportunity cost. Every hour an engineer spends on the email platform is an hour not spent on the product that actually differentiates the business. For an infrastructure company, email is the product and that attention is well spent. For a SaaS company that merely needs to send email reliably, that attention is diverted from the thing customers are paying for. That diversion has a price.
The PowerMTA license, in proportion
Because the license is the largest invoiced item, it tends to dominate the conversation, and that is a mistake of proportion. It is worth stating the 2026 numbers plainly so the license can be put back in its place.
As of 2026, a standard PowerMTA license — the commercial high-volume MTA most serious senders standardise on — begins in the region of 8,000 US dollars per year, typically bundled with an analytics layer. A volume-based licensing model is also available, billed against messages actually sent, with a lower entry point for senders who prefer to pay in proportion to use. One detail the build spreadsheet routinely omits: development and test environments generally require their own licenses, so the real software cost of a build is usually higher than the single production figure people quote.
A mid-sized sender we reviewed had built their entire build-versus-buy case around the license fee. They had negotiated it down, felt good about the saving, and signed off the build. Eight months later the platform was running, the license was indeed cheaper than the managed quote — and they had hired a half-time operations engineer to keep it healthy whose cost exceeded the license several times over. The line item they had optimised was not the line item that mattered.
The license is real and recurring. But it is a known, bounded, predictable number. The costs that actually swing the decision — staffing, warming, risk — are larger and harder to see, and a decision that fixates on the license is optimising the wrong variable.
Negotiate it down by all means. Just do not mistake the negotiation for the analysis.
Reputation as an unbooked asset
The most consequential thing a build acquires is not a server. It is ownership of a sender reputation, and reputation behaves like an asset that never appears on a balance sheet.
It accrues slowly. A new IP, sending carefully and consistently, builds standing with the major receivers over weeks. It can also be destroyed quickly. A single send to a poorly maintained list, a misconfigured authentication record, a complaint rate that crosses a receiver's threshold — and an asset that took two months to build is impaired in an afternoon. The asymmetry between how slowly reputation builds and how quickly it can fall is the defining feature of the thing you are buying when you build.
When you buy managed infrastructure, you are renting access to a reputation someone else has already built and is contractually responsible for maintaining. When you build, you own the asset outright — and you own its volatility. For a sender with the operational maturity to protect that asset, ownership is genuinely valuable. For a sender without that maturity, ownership is a liability dressed up as a saving. The same asset, with a different operator, has a different sign.
This is why the build-versus-buy answer is not a property of the business's size alone. It is a property of the business's operational readiness. Two senders of identical volume can correctly reach opposite conclusions, because one has an engineer who can protect the reputation asset and the other does not.
Size tells you almost nothing here. Readiness tells you everything.
The staffing question, priced honestly
Staffing is the single largest uninvoiced cost, and it is worth pricing it with some care rather than waving at it.
The build does not need a full-time deliverability engineer in most cases. What it needs is a fraction of one — but a fraction of a scarce, expensive, specialised person, and the fraction is not small. Configuration is front-loaded and intermittent after that. Monitoring is continuous. Incident response is unpredictable and, when it happens, urgent: a deliverability incident does not wait for business hours, and a deferral pattern that is ignored overnight can harden into a reputation problem by morning.
| Operational activity | Cadence | Who it needs |
|---|---|---|
| Initial platform configuration | One-time, front-loaded | Experienced operator |
| Virtual-MTA and routing tuning | Periodic, as volume changes | Experienced operator |
| Accounting log review | Continuous / daily | Operator or analyst |
| Deferral and bounce monitoring | Continuous | Operator or alerting |
| Reputation incident response | Unpredictable, urgent | Experienced operator, on call |
| Receiver policy tracking | Ongoing | Someone who follows the space |
Add an honest fraction of a specialist salary, plus the cost of on-call coverage, and compare the result against the license fee. For most senders the staffing cost is several multiples of the license. The build spreadsheet that omits this item is not slightly wrong; it is wrong by the largest single number in the analysis.
There is a second-order effect worth noting. A half-time role is awkward to staff. It is too small to justify a dedicated hire and too important to leave to whoever is free. So it tends to land on an engineer who already has a full-time job, which means the email platform is operated by someone with divided attention — and divided attention is exactly the condition under which the reputation asset gets damaged. The staffing cost is not only money. It is the structural fragility of part-time ownership of a system that punishes inattention.
The cost of being wrong
Every cost discussed so far is a cost of the build working as intended. There is a further cost: the cost of the build going wrong, weighted by how likely that is.
A first-time build by a team without deliverability experience does not have a small probability of a serious early mistake. It has a meaningful one. The mistakes are well known — under-warming, an SPF or DKIM misconfiguration, sending volume that outruns reputation, a list hygiene gap. The consequence is not a refund. It is a damaged sending reputation that takes weeks to rebuild, during which the business's email — including the transactional email customers actually depend on — underperforms.
Price that honestly. Estimate the probability of a significant first-year incident for a team without prior deliverability experience. Estimate the cost of one — recovery time, lost deliverable volume, the engineering hours pulled into firefighting. Multiply. That expected value is a real cost of the build, and it is one of the costs a managed provider is, in effect, absorbing on the sender's behalf, because an experienced operator's probability of that same incident is far lower.
A build that goes well saves a managed margin. A build that goes badly costs weeks of reputation recovery and degrades transactional mail in the meantime. The payoff is asymmetric — bounded upside, long-tailed downside — and a cost analysis that ignores the tail is not an analysis, it is optimism.
Where the crossover actually sits
With the full cost surface on the page, the build-versus-buy crossover can be located more honestly. It is not a single number, because it depends on operational readiness as much as volume, but the shape is consistent.
| Sender profile | Cost picture | Usually correct |
|---|---|---|
| Below ~1M/day, no deliverability staff | Build staffing cost dwarfs invoiced savings | Buy |
| 1–3M/day, no in-house operator | Build looks close on invoices, loses on full cost | Buy |
| 1–3M/day, experienced operator already on staff | Staffing cost partly absorbed; closer call | Either; depends on focus |
| High volume, email is the core product | Operator cost is well-spent; ownership valuable | Build |
| Any volume, deliverability is a regulated differentiator | Control and data residency outweigh cost | Build, or managed-dedicated |
The pattern: the invoiced crossover sits low, and a naive analysis will place the decision there. The true crossover — the point where a build genuinely costs less once staffing, warming, and risk are priced — sits considerably higher, and for a large share of senders it is never reached at all, because the volume that would justify the staffing cost is volume they do not have.
There is also a third option the binary framing hides. Managed infrastructure does not mean shared IPs and a generic ESP. A sender can buy managed operation of dedicated infrastructure — their own IPs, their own PowerMTA instance, their own reputation asset — operated by people who do deliverability full time. That option captures most of the control benefit of a build while moving the staffing cost and the cost-of-being-wrong off the sender's books. For senders near the crossover, it is frequently the answer the binary question obscures.
Build or buy is the wrong question. Build, buy operated, or buy shared is the real one.
When building is the right answer
None of this argues against building. It argues against building for the wrong reason. There is a clear class of senders for whom the build is correct, and the test is consistent.
Build when email is genuinely core to the product, so the engineering attention is spent on the thing customers pay for rather than diverted from it. Build when you already employ someone with real deliverability experience, so the largest uninvoiced cost is partly absorbed by a role that already exists. Build when control and data residency are themselves the deliverable — a sender under strict EU compliance obligations may need ownership of the infrastructure and the data path for reasons that have nothing to do with cost. And build when volume is high enough that the staffing cost, spread across that volume, is small per message.
When several of those conditions hold, the build is not a saving dressed up as a risk; it is a sound decision. When none of them holds and the build is being chosen because the spreadsheet said so, the spreadsheet was incomplete.
An infrastructure-adjacent company we worked alongside built their own platform and it was the right call — not because the invoices were lower, but because they already had two engineers fluent in deliverability, email volume was central to what they sold, and EU data residency was a contractual requirement from their own customers. For them the uninvoiced costs were either already paid or were not costs at all. The same build, at a SaaS company with none of those conditions, would have been a mistake.
A decision procedure that holds up
A build-versus-buy analysis that survives contact with reality is not longer than the naive one. It is the same spreadsheet with four rows added and one question asked first.
The question, asked before any numbers: do we already have, on staff, someone who can operate this and protect the reputation asset? If yes, the build is in genuine contention. If no, the honest analysis almost always points to buying, and the only remaining question is managed-shared versus managed-dedicated.
Then the four rows. Add the fraction of a specialist salary the platform will consume, including on-call coverage. Add the warming latency as opportunity cost — deliverable volume not sent during ramp. Add the expected value of a first-year reputation incident, weighted by your team's actual experience level. Add the opportunity cost of the engineering attention diverted from the core product. Put those four numbers next to the server, the IPs, and the license, and total the column honestly.
Run that, and the decision stops being a contest of invoices and becomes what it always was: a question of whether your organisation is the right operator for a reputation asset that rewards attention and punishes neglect. For senders who are, building can be excellent. For senders who are not, the managed route is not the expensive option — it is the one that prices the risk correctly and puts it where it can be managed by people who do this every day.
Frequently asked questions
Is it cheaper to build or buy email infrastructure?
At the level of line items a build often looks cheaper, because the build spreadsheet captures only servers, IP addresses, and a PowerMTA license. The decision flips once the unbooked costs are added: an experienced deliverability engineer, the on-call coverage high-volume sending demands, the warming time before the infrastructure earns anything, and the cost of being wrong about a reputation problem you cannot yet diagnose. For most senders below roughly two to three million messages a day without an in-house operator, the true cost of a build exceeds managed infrastructure once those items are priced honestly.
What does a PowerMTA license cost in 2026?
PowerMTA is commercial software with annual licensing that, as of 2026, begins around 8,000 US dollars per year for a standard license bundled with analytics, with volume-based licensing available from a lower entry point for senders who prefer to pay per message sent. Separate licenses are typically required for development and test environments, which the build spreadsheet routinely omits. The license is a real recurring cost, but it is rarely the line item that decides build versus buy — staffing is.
What costs does a build-versus-buy analysis usually miss?
The build spreadsheet captures hardware, addresses, and software, because those have invoices. It misses the costs with no invoice: the salaried time of the engineer who operates the platform, the on-call burden, the weeks of IP warming during which the infrastructure produces no deliverable volume, the sender reputation that must be built as an asset and can be destroyed in a day, and the opportunity cost of engineering attention diverted from the core product. Those uninvoiced costs, not the invoiced ones, usually determine the correct answer.