Building Postfix yourself?
Here is the real cost.

The software is genuinely good. Postfix's modular architecture — separate daemons for receiving plus rewriting plus queuing plus delivering, each running with limited privileges — is one of the most security-conscious designs in long-running open-source server software. The configuration syntax in main.cf and master.cf is readable, the documentation is well-maintained, and the operational tooling (postqueue, mailq, postfix status, postfix reload) covers the common administration tasks. A properly-tuned Postfix instance on modest hardware handles hundreds of deliveries per second sustained, with peak throughput in the low thousands per second on the largest configurations. We run Postfix internally on several internal-tooling workloads and we are not anti-Postfix. The question is when self-hosted Postfix is the right operational choice versus when a managed alternative is.

The build-versus-buy framing that most "is self-hosted email worth it" articles use is incomplete. The framing typically compares ESP per-message pricing against VPS hosting cost: $50/month for a Hetzner CX31 versus $250/month for a managed ESP at the same volume, with the conclusion that self-hosted is "5x cheaper." This framing ignores the operational cost layer that dominates Total Cost of Ownership at any volume above hobby-scale. The actual comparison requires four cost components: (1) infrastructure (the VPS or dedicated server), (2) software licences if any (Postfix is free but ancillary tools may not be), (3) engineer-hours for setup, ongoing operations and incident response, and (4) opportunity cost of the engineer-hours diverted from product work.

Engineer-hour cost is the component most-frequently underestimated. A production Postfix deployment requires initial setup time (typically 20-40 hours for a competent Linux administrator to bring a Postfix instance to production-grade configuration with proper authentication plus hardening plus monitoring plus queue management). Ongoing operations require a baseline of 4-8 hours per month for routine maintenance: security patches, certificate renewals, log analysis, queue monitoring, sender-reputation checks against the major blacklists. Incident response adds variable hours — typically 10-40 hours per quarter for a sender with non-trivial volume — covering blacklist removals, deliverability remediation, capacity expansion, abuse handling, and the inevitable "why are emails going to spam" investigations.

At a typical European fully-loaded engineer cost of €70-€120 per hour (salary plus benefits plus overhead), the engineer-hour cost component lands at €280-€960 per month for ongoing operations alone, before incident-response peaks. The infrastructure cost — €50-€200 per month for the VPS and adjacent services — is a small fraction of total operational cost. The "self-hosted is 5x cheaper" framing collapses immediately under realistic engineer-hour costing.

The framing matters because the engineer-hours are not optional and not eliminable. Postfix's security-conscious design does not exempt the operator from configuring it correctly. A misconfigured Postfix instance — open relay, weak TLS, missing SPF alignment, expired DKIM key, blacklisted IP — produces deliverability failure modes that range from "annoying" to "company-ending" depending on what depends on the email pipeline. The operational discipline required to run Postfix at production grade is real. It is learnable. It is not a substitute for the actual time investment.

Profile one: in-house engineering teams with existing Postfix expertise and modest email volume. A 50-person SaaS engineering organisation with one or two engineers who have run Postfix in previous roles, sending sub-100K monthly transactional traffic, where the marginal cost of running an additional Postfix instance is genuinely low because the operational pattern is already familiar. The infrastructure cost is €50-€100/month, the engineer-hour cost is €280-€480/month at the lower end of the range because the learning curve is paid, and the total operational cost lands at €330-€580/month. This is competitive with mid-tier managed ESP pricing and superior on control-surface and jurisdictional simplicity. We have helped several customers in this profile build their internal Postfix capacity rather than migrate them to our managed service. Honest internal-build is often the right answer for this profile.

Profile two: control-sensitive or sovereignty-sensitive workloads where the operator wants direct line-of-sight to every layer. A defence contractor, a national intelligence agency on a non-classified workload, a financial institution under regulatory pressure to demonstrate exhaustive supply-chain control. The build-versus-buy calculation at this profile is not driven by cost — these organisations can afford either approach — but by the requirement to control the entire processing chain. Self-hosted Postfix on dedicated hardware in a controlled facility, operated by cleared internal staff, produces an audit trail that no managed service can match. We do not compete with this profile and we will refer prospects to the appropriate self-hosted-build consultants when their requirements match it.

Profile three: sub-50K monthly volume with strong open-source preference and engineering capacity. Small-to-medium businesses run by technical founders, often in the open-source-adjacent business categories (developer tools, security consultancies, technical-content sites), where the engineering capacity to maintain a Postfix instance exists and the cultural preference for self-hosted infrastructure is strong. The volume is low enough that the ESP alternative would be inexpensive but the architectural preference is strong enough that the cost differential is not the deciding factor. We respect this choice. The right BIG BOX engagement for this profile is occasional consulting (we help debug a deliverability incident, we audit the configuration before a renewed warmup, we provide a peer review on the IP-rotation strategy) rather than full managed service.

Outside these three profiles, the self-hosted Postfix choice becomes harder to justify on the cost or operational dimensions. The remaining justifications tend to be ideological (open source for its own sake), historical (the team has always run Postfix and migration friction is real), or budgetary (the engineer-hour cost is invisible on the books because the engineers are already on payroll, even though the opportunity cost is real). These justifications are not invalid — many of our prospects ultimately choose to stay self-hosted and we respect that — but they should be acknowledged as the operational reasons they are.

Lack of in-house MTA expertise combined with non-trivial volume. An e-commerce platform at €5M-€50M revenue sending 200K-1M monthly transactional emails, with an engineering team focused on product features rather than infrastructure. Hiring a dedicated Postfix engineer at €80,000-€120,000 fully-loaded annual cost is operationally feasible but not justified for a single workload. Training an existing engineer to MTA-operator proficiency takes 6-12 months and produces a single-person dependency that the organisation cannot lose without operational risk. Our managed PowerMTA or managed SMTP Relay service eliminates the staffing question — the operational layer is our responsibility, the customer's engineering team focuses on the application layer. The price differential (€399-€999 monthly versus the loaded cost of internal staffing) is favourable at any non-trivial volume.

Regulator-grade compliance posture without building the audit trail in-house. Sector regulators — BaFin, ACPR, FINMA, HDS-supervised authorities, NIS2-scope critical infrastructure designations — require detailed processing documentation, sub-processor disclosures, incident-response procedures, and supply-chain controls. Building this audit trail for a self-hosted Postfix deployment requires the same documentation and audit work as building it for any internal infrastructure — typically 80-200 hours of compliance-team time per regulator engagement. Our managed service ships with the audit trail pre-built: published DPA at /legal/dpa/, documented sub-processor list, ISO 27001-certified infrastructure providers, NIS2-compliant incident response. The compliance hours that would otherwise go into building internal documentation are eliminated.

Deliverability remediation as a competitive advantage. Senders whose business model depends on email deliverability as a competitive moat — high-velocity B2B SaaS, transactional-revenue e-commerce, deliverability-sensitive consumer apps — benefit from operational deliverability expertise that is genuinely difficult to build in-house. Our deliverability team has compounded knowledge from running mail across many customer profiles since 2002. The specific knowledge that matters — which receiver does what with which authentication signal, when to rotate IPs out of a degrading pool, how to interpret an aggregate DMARC report against a specific receiver's idiosyncrasies, what the current state of Microsoft's SmartScreen recalibration means for this week's outbound — accumulates faster across many customer profiles than across a single internal one. For senders where this expertise is a competitive moat, the managed-service argument is operational rather than cost-based.

Scale above 1M monthly volume where engineer-hour costs dominate. Above 1M monthly emails, the operational complexity of self-hosted Postfix increases non-linearly. Multiple IPs require pool management. Bounce-handling at this volume requires automated remediation rather than manual review. Receiver-specific traffic shaping (delaying Gmail traffic during their peak hours, batching Yahoo traffic to match their hourly rate limits) becomes important. Blacklist monitoring across the 30+ relevant blacklists is a continuous workload. The engineer-hour cost at this band typically lands at 0.5-1.0 FTE of dedicated deliverability engineering — €40,000-€120,000 annually fully-loaded. Our managed PowerMTA or managed KumoMTA service at this band is €1,299-€2,499 monthly = €15,588-€29,988 annual. The cost crossover is decisive in our favour.

Band A: 50K monthly emails, single-stream transactional. Self-hosted Postfix: €60 VPS + 4 hours operations × €100 = €460 monthly. Add 2 hours per quarter for incident peaks averaged across the year = additional €17/month = €477/month. BIG BOX SMTP Relay Starter: €99 monthly. BIG BOX wins by €378/month or €4,536/year. The TCO crossover is well below this volume; even at 10K monthly the engineer-hour layer makes self-hosted more expensive than managed for any sender without pre-existing Postfix operational capacity.

Band B: 250K monthly emails, mixed transactional plus light marketing. Self-hosted Postfix: €120 VPS + 8 hours operations × €100 = €920 monthly. Add 6 hours per quarter for incident peaks = €50/month = €970/month. BIG BOX SMTP Relay Standard with dedicated IP: €399 monthly. BIG BOX wins by €571/month or €6,852/year. The deliverability gap widens at this volume — self-hosted on a single new IP typically takes 6-8 weeks to reach 92-94% inbox placement against managed dedicated-IP infrastructure that reaches 95-97% by week 2 — and the customer-facing revenue impact of the deliverability gap typically exceeds the cost differential.

Band C: 1M monthly emails, mixed traffic, deliverability-sensitive sender. Self-hosted Postfix: €300 dedicated server + 0.4 FTE engineer time × €100/hr × 70 hours/month = €7,300 monthly fully-loaded, or €4,500 monthly if the engineer is on payroll and the opportunity cost is invisible to the budget line. BIG BOX managed SMTP Relay Enterprise or managed PowerMTA: €999-€1,299 monthly. BIG BOX wins decisively on TCO and on deliverability quality. The single-person dependency risk at this volume is material: if the dedicated Postfix engineer leaves the organisation, the mail infrastructure becomes an operational liability for 6-12 weeks during the replacement-and-onboarding window.

Band D: 10M monthly emails, multi-stream, large e-commerce or SaaS. Self-hosted Postfix at this volume requires multiple servers, dedicated IPs across multiple pools, automated bounce handling, receiver-specific traffic shaping, and a dedicated deliverability team. The realistic cost is 1.0-1.5 FTE deliverability engineering + €1,000-€3,000 monthly infrastructure = €10,000-€18,000 monthly. BIG BOX managed KumoMTA dedicated: €2,499-€3,999 monthly. BIG BOX wins by 5-7x on TCO at enterprise volume. The remaining argument for self-hosted at this band is strategic control rather than cost — and even on the control argument, our managed PowerMTA or managed KumoMTA services expose enough of the underlying configuration that the control-surface gap is smaller than typically assumed.

Failure mode one: IP blacklist incident with slow remediation. A sending IP gets listed on Spamhaus SBL or one of the major operator blacklists. The blacklist removal procedure typically requires the operator to identify the root cause (compromised account, list-quality incident, abuse complaint), remediate it, document the remediation, submit a delisting request through the blacklist operator's portal, and wait 24-72 hours for the delisting to propagate. For a competent in-house team that has handled blacklist incidents before, this is a 2-4 hour operational task. For a team that has not, the same incident can extend to 1-3 days of degraded deliverability while the team learns the process. Our customers experiencing the same incident on managed infrastructure see a 30-60 minute mean-time-to-remediation because we have run the procedure dozens of times.

Failure mode two: DKIM key rotation accident. An operator rotates the DKIM key for a domain, updates DNS, and forgets to update the MTA configuration to sign with the new selector — or vice versa, updates the MTA but forgets to publish the new selector to DNS. The result is a percentage of outbound mail failing DKIM verification, which in 2026 increasingly produces silent spam-folder routing rather than visible bounces. The incident is detectable from aggregate DMARC reports but typically only after 24-48 hours of degraded delivery. Our managed infrastructure runs DKIM rotation as a coordinated procedure with verification at each step; the failure mode is structurally eliminated.

Failure mode three: TLS certificate expiration on the SMTP submission port. An operator's TLS certificate for the submission endpoint expires. Outbound mail submission from the application fails. The application's mail queue backs up. The incident is detectable from application monitoring but the root cause (certificate expiry) is one of the less obvious diagnoses. Time-to-recovery typically runs 30 minutes to 4 hours depending on the operator's certificate-renewal automation. Our managed infrastructure handles certificate renewal as part of the operational layer.

Failure mode four: receiver-side rate-limiting cascade. A customer launches a campaign that exceeds a major receiver's hourly rate limit (Yahoo and AOL are the most-frequent triggers). The receiver responds with 421 deferral codes. A naive Postfix configuration retries aggressively, which the receiver interprets as abuse and escalates to harder rate limits or temporary blacklisting. The cascade can take 24-72 hours to resolve and typically requires manual operator intervention. Our managed infrastructure includes receiver-specific traffic shaping that anticipates rate limits and paces outbound traffic to avoid the cascade.

Failure mode five: queue management during incidents. A receiving domain experiences an outage. Outbound mail to that domain accumulates in the Postfix queue. A naive operator either lets the queue grow unbounded (eventually consuming disk and impacting other workloads) or aggressively expires queued messages (losing legitimate mail). Optimal queue management requires the operator to make per-incident judgements about retry intervals, expiry windows and customer notification. Our managed infrastructure handles queue management as a standard operational practice; the customer sees the result rather than making the judgement.

None of these failure modes is exotic. Each is recoverable. The recovery, however, requires either operational expertise that takes time to build or operational time that compounds across incidents. For senders whose business can absorb occasional multi-hour deliverability degradation, the self-hosted choice is defensible. For senders whose revenue or compliance posture cannot absorb it, the managed alternative is the operationally-correct answer regardless of the headline cost differential.

The hybrid pattern works as follows. The application's outbound mail is generated by application code talking SMTP to a local Postfix instance running on the application's own infrastructure. Postfix handles the application-side concerns: SMTP submission, message queue, basic envelope formatting, application-specific routing rules, internal authentication. Outbound delivery from Postfix is then relayed through BIG BOX's SMTP Relay rather than direct-to-receiver. BIG BOX handles the deliverability-critical layer: dedicated IP reputation, DKIM signing, MTA-STS enforcement, receiver-specific traffic shaping, bounce categorisation, blacklist monitoring, regulator audit trail.

The hybrid architecture preserves several self-hosted properties that matter to certain senders. The application's mail-generation logic stays on-premises. The customer-data integration with the mail pipeline remains under the customer's control. The Postfix configuration remains modifiable by the customer's operations team. The customer retains the option to switch outbound relay providers without rewriting the application's mail-submission logic.

The hybrid architecture also eliminates the operational burdens that the self-hosted-only choice creates. The customer's Postfix instance does not need a public IP address. It does not need to manage external IP reputation. It does not need TLS certificates for receiver-facing SMTP. It does not need to handle bounce categorisation, blacklist monitoring, or receiver-specific traffic shaping. The operational burden on the customer reduces from "run a full production MTA" to "run a forwarding SMTP submission server" — typically 2-4 hours per month versus 8-12 hours per month for the full-stack self-hosted choice.

Pricing for the hybrid pattern is BIG BOX SMTP Relay Sender at €259/month for up to 250K monthly volume, plus the customer's own Postfix infrastructure (typically €50-€100/month VPS). Total operational cost €360-€460/month, which is comparable to or below pure self-hosted at the same volume after engineer-hour costing, with better deliverability and lower operational risk.

The hybrid architecture is the configuration we recommend most frequently to prospects coming from self-hosted backgrounds who want to preserve operational control on the application side while outsourcing the deliverability-critical layer. We provide reference configurations for Postfix-to-BIG BOX-relay setup covering the common host platforms — AlmaLinux, Ubuntu, Debian and FreeBSD — on request; ask us and we will send the set that matches your stack.

Path one: full managed migration. The customer's application is reconfigured to talk SMTP directly to BIG BOX SMTP Relay rather than the local Postfix instance. The Postfix instance is decommissioned. The IP that Postfix was sending from is allowed to age out of receiver reputation systems. Total elapsed time 2-4 weeks. The migration is the simplest of the migration types we run because there is no contractual lock-in with the previous infrastructure and the application change is typically a single configuration update in the mail-submission credentials.

Path two: hybrid migration. The customer's Postfix instance is reconfigured to relay outbound through BIG BOX rather than send direct. The application's mail-submission logic remains unchanged. The Postfix configuration change is a single relayhost directive plus SASL credentials. Total elapsed time 1-2 weeks because there is no application-side change required. This is the migration we run most frequently because it preserves the customer's existing operational practices while eliminating the deliverability-critical operational burden.

In both patterns, we run a parallel-sending window — typically 1-2 weeks — where outbound traffic splits between the existing infrastructure and the new BIG BOX path, allowing the customer's monitoring to compare deliverability metrics side-by-side. The split is implemented either at the application layer (for full migration) or via Postfix's smtp_fallback_relay directive (for hybrid migration). Rollback to pure self-hosted is a single configuration change at any point during the parallel window.

Pricing for the migration engineering is included in the first 12-month service contract for new customers. We do not charge separately for the migration assistance because the migration is the operational moment where we earn the customer's confidence, and over-engineering the commercial layer at that moment is counterproductive.

Question one: does your team have current Postfix operational expertise, and is your monthly volume below 100K? If yes, self-hosted Postfix on EU-domiciled VPS infrastructure is a legitimate choice. The operational burden is manageable at this volume for a team that has paid the learning curve, and the control surface is genuine. We are happy to provide occasional consulting on deliverability incidents without a full managed engagement.

Question two: is your volume between 100K and 1M monthly, or do you have regulator-driven compliance requirements? If yes, the hybrid architecture (self-hosted Postfix application-side, BIG BOX SMTP Relay outbound) is typically the operationally-correct answer. It preserves the application-side control your team values while eliminating the deliverability-critical operational burden that the pure self-hosted choice would require. The cost is comparable to pure self-hosted at honest engineer-hour costing, with better deliverability outcomes.

Question three: is your volume above 1M monthly, or do you lack current Postfix operational expertise, or is your business model deliverability-sensitive? If yes, fully managed BIG BOX (managed PowerMTA or managed KumoMTA) is the operationally-correct answer. The self-hosted alternative at this band requires dedicated FTE deliverability engineering that is structurally more expensive and structurally riskier than the managed-service equivalent.

The conversation we recommend is a 30-minute scoping call where we model your specific volume, team capacity, compliance requirements and operational tolerance. We will tell you honestly whether self-hosted, hybrid (Postfix plus relay) or fully-managed is the right answer for your shape. We have customers in all three patterns. We do not believe the universal answer to "build versus buy" is "buy" — we believe the answer depends on your specific situation and we will say so.