Do not self-host Postfix on a cloud VPS unless you have a warmed IP, an allowlisted port 25 outbound, and a mail-ops engineer on call. For everyone else, Amazon SES at $0.10 per 1,000 emails on AWS's pre-warmed IPs is the pragmatic answer (AWS, 2026). The gap is wide because the major cloud providers - AWS EC2, DigitalOcean, Google Cloud, Linode, Hetzner, Vultr - block outbound port 25 by default, and on Google Cloud the block is indefinite with no removal path.
Postfix is the open-source MTA most self-hosted email stacks are built on. SES is the AWS-managed equivalent. Below is a straight comparison of cost, IP reputation, the Gmail/Yahoo Feb 2024 rules, ops time, and the narrow operator profiles where Postfix still defends itself. For the broader hosted-vs-self-hosted decision frame, our self-hosted vs hosted email marketing breakdown sits one level up.
The honest comparison
The dimensions that actually matter for a production email sender split cleanly across SES and Postfix. Cost is the headline most people lead with, but it's not the most expensive line - operator time and IP reputation almost always dominate the total. The table below is the short version of the rest of this post, weighted toward what a real sender hits in the first 90 days of running either stack.
| Dimension | Amazon SES | Self-hosted Postfix |
|---|---|---|
| Recommended for most senders | ✓ Yes | Only with mail-ops experience |
| Cost at 100k emails/month | $10 (SES) + management layer | $20-50 VPS + 5-10 hrs ops time |
| IP reputation at launch | Pre-warmed AWS IP pools | Cold IP, 4-6 week warm-up |
| Bounce handling | SNS notifications, auto suppression list | You build it (parse bounces, store, suppress) |
| Complaint feedback (FBLs) | SNS complaint topic, auto-tracked | Manual FBL signup per provider |
| SPF / DKIM / DMARC setup | Console wizard, CNAMEs published once | OpenDKIM + OpenDMARC + manual DNS |
| List-Unsubscribe (RFC 8058) | Easily added via headers in send call | You implement headers + endpoint |
| Scaling | Auto-scales to millions/day | Manual queue tuning, multi-IP, multi-MTA |
| Compliance posture | SOC 2, ISO 27001, HIPAA-eligible (BAA) | You are the auditor |
| Ongoing ops time | Near zero | 5-10 hours/month minimum |
The rows that decide the comparison for most teams are IP reputation, ops time, and complaint feedback. The cost row is almost a distraction - by the time you've covered the rest, the dollars-per-thousand difference between SES and a Postfix VPS is rounding error.
Why IP reputation kills most self-hosted Postfix attempts
A fresh VPS gets a fresh IP address, and a fresh IP address has no reputation at any major mailbox provider. Worse, on most cloud VPS providers it has no outbound port 25 at all by default - AWS EC2, DigitalOcean, Linode, Hetzner, and Vultr require a written removal request, and Google Cloud blocks port 25 indefinitely with no removal path (AWS, 2026). Gmail's published sender guidelines treat unknown senders as suspect by default and require IPs to maintain a Postmaster Tools spam rate below 0.30% to keep delivering at all (Google, 2024). SES sends from AWS IP ranges that have been delivering legitimate mail for over a decade and are already known to every receiver in the world.
The practical effect on a new Postfix install is brutal. For the first 4-6 weeks, even with perfect SPF, DKIM, DMARC, valid PTR records, and TLS, a typical cold IP lands 30-60% of mail in spam folders, gets greylisted by Gmail, and may be temporarily blocked entirely by Microsoft until you build engagement signals. The warm-up routine - small daily volumes, only to engaged recipients, slowly ramping over weeks - is well documented but unforgiving. One day of pushing 50,000 cold sends to a stale list can torch the IP permanently and force you onto a fresh one to start over.
SES sidesteps this entirely. New SES accounts inherit the reputation of the shared IP pool and only need to demonstrate good behavior to graduate from the sandbox. Senders that need a dedicated IP can purchase one through SES and let AWS handle the warm-up signaling on their behalf. The reputation work that consumes the first month of any self-hosted setup is already done. For a deeper look at how this plays out in practice, see our Amazon SES deliverability deep dive.
What Postfix actually gives you - and what it doesn't
Postfix is an MTA (Mail Transfer Agent), released by Wietse Venema in 1999 and licensed under IPL-2.0, that moves SMTP messages from a queue out to receiving servers reliably and at scale (Postfix Project, 2026). That is genuinely all it does. It does not handle suppression lists, complaint feedback loops, engagement tracking, RFC 8058 one-click unsubscribe headers, list management, segmentation, or any of the marketing-platform features that operators sometimes assume "self-hosted email" implies. A bare Postfix install is the SMTP layer, not the sending platform.
A realistic production-grade self-hosted stack on top of Postfix typically looks like:
- Postfix as the MTA, with a tuned
main.cffor TLS, rate limits, and queue behavior. - OpenDKIM as a milter to DKIM-sign outgoing mail.
- OpenDMARC as a milter to enforce alignment and produce aggregate reports.
- Rspamd or SpamAssassin for outbound spam scoring (yes, you want to score your own outgoing mail).
- A suppression database (Postgres or Redis) holding bounced and complained addresses with the logic to keep mail from being requeued to them.
- Feedback loop processing for every major provider that offers FBLs (Microsoft SNDS, Yahoo CFL, etc.), with manual signup per domain.
- List-Unsubscribe headers and a public HTTP endpoint that accepts one-click POSTs per RFC 8058.
- Postmaster Tools and SNDS dashboards, manually monitored, with alerting if spam rates climb.
- Log aggregation so you can investigate why a send underperformed.
Every one of these components is also a piece of software that needs patching, monitoring, and incident response. Postfix itself is famously stable, but the surrounding stack is where the on-call pages come from. SES bundles equivalents for nearly all of these as managed features behind a single API.
When self-hosted Postfix actually makes sense
Three narrow profiles defend a self-hosted Postfix setup in 2026, and "I want to save money" is not one of them. The first is small transactional volume from a known-good IP - a company that has been running its own mail server reliably for years, already has warm IP reputation, and uses Postfix for low-volume notification mail. Migrating that to SES would buy nothing and risk breaking a working setup.
The second is data residency or compliance contexts where AWS doesn't fit. Some EU healthcare and financial workloads require infrastructure inside a specific jurisdiction with no US parent-company touch, which AWS's standard SES regions can't always satisfy. A Postfix node inside a sovereign cloud or on-prem datacenter is the practical answer. The third is R&D and hobby setups - learning the SMTP stack, running a personal mail server, sending newsletters to friends - where operator time is free and the slow IP warm-up is part of the project.
Outside these three profiles, the math points to SES. The clearest tell: if you don't already have a designated mail-ops engineer with deliverability experience, self-hosting Postfix is rebuilding a managed service from scratch on a critical path.
When SES is the obvious choice
SES is the obvious choice for any marketing or transactional sender without a dedicated mail-ops engineer, which describes almost every commercial sender in 2026. The Feb 2024 Gmail and Yahoo bulk sender rules - SPF, DKIM, DMARC, one-click List-Unsubscribe, spam complaint rate under 0.3%, valid PTR, TLS - are non-negotiable, and SES has them as defaults or trivial console toggles (Google, 2024). On Postfix, every one is a configuration project.
SES also wins anywhere you need scale without ops surprises. AWS auto-scales the sending infrastructure, manages the IP pools, and provides bounce and complaint topics over SNS that you can subscribe to with three clicks. The per-thousand price is published, the suppression list is managed, and the feedback loops are wired up at the platform level. For pricing details across volumes and feature add-ons, see our Amazon SES pricing breakdown.
The one caveat: SES has a sandbox onboarding step that requires a support request to enter production sending. It's a one-time 1-2 business day process, not an ongoing tax. After that, the path of least resistance is permanent.
Cost comparison at 100k emails/month
The cost picture flips depending on whether you cost operator time. At 100,000 emails per month (10,000 contacts under Mailblast's 10-per-contact allowance), SES charges $10 in send fees at its published $0.10/1,000 rate plus $20/month for Mailblast at that contact tier. A VPS running Postfix is closer to $20/month for the server itself - cheaper on the surface, but the surface is misleading.
Self-hosted Postfix at production quality realistically takes 5-10 hours of operator time per month: patching, blocklist monitoring, FBL queue review, occasional Spamhaus delisting requests, DKIM rotation, log review when delivery dips. At a $60/hour blended developer rate, that's $300-$600/month of operator cost, before you count incident time when something actually breaks. The Stack Overflow 2024 Developer Survey puts typical developer hourly rates well above this in most Western markets, so the figure is conservative.
The bar chart understates the risk side of Postfix. The dollar figure assumes nothing goes wrong. A single Spamhaus listing or a Gmail reputation dip can consume a full day of incident response, and the cost of degraded delivery (revenue from undelivered marketing mail, missed transactional notifications) is rarely included. SES rolls that risk into the per-1000 fee; Postfix passes it to you uncovered.
How Mailblast fits on top of SES
Mailblast is the management layer customers add on top of their own Amazon SES account (BYO-SES) - it is not a Postfix alternative, and it does not run its own SMTP infrastructure. The model is straightforward: your AWS account holds the SES configuration, IP reputation, and per-1000 billing. Mailblast provides the subscriber lists, the BeeFree drag-and-drop editor, automation flows (welcome sequences, drip campaigns, list-based triggers), analytics with per-link click tracking, and the suppression UI that ties bounces and complaints back to specific recipients.
The equivalent self-hosted stack on top of Postfix would be Postfix plus OpenDKIM plus OpenDMARC plus Rspamd plus a custom suppression database plus a campaign UI like Mautic or listmonk plus log aggregation plus FBL signup work - all of which you build, monitor, and patch. The Mailblast layer collapses that to a subscription starting at $10/month for 1,000 contacts, which includes automation on every paid rung. The free plan covers 1,000 contacts and 10,000 emails/month with a "Sent with Mailblast" footer; unbranded sending starts on the first paid rung.
The model only works because SES is doing the heavy infrastructure lifting underneath. Layering a marketing UI on top of Postfix is structurally possible but bears the deliverability and ops cost of running the whole stack yourself - which is the entire trade this post is about.
FAQ
Is Amazon SES cheaper than running Postfix on a VPS?
At any volume below roughly 5 million emails/month, yes. SES costs $0.10 per 1,000 emails with no servers to maintain (AWS, 2026). A $20/month VPS running Postfix looks cheaper until you cost in operator time: 5-10 hours/month of patching, queue tuning, blocklist remediation, and feedback-loop monitoring at a developer rate dwarfs the SES bill at any commercial volume.
Why does Postfix on a fresh VPS have such bad deliverability?
The IP is cold. Major mailbox providers (Gmail, Microsoft, Yahoo) greylist or outright block unknown IPs by default and only build positive reputation after weeks of consistent, low-volume, engaged sending. Amazon SES sends from IP ranges that have been warmed for over a decade. A new Postfix VPS typically lands 30-60% of mail in spam for the first 4-6 weeks even with perfect SPF, DKIM, and DMARC.
Can Postfix meet Gmail and Yahoo's February 2024 bulk sender rules?
Yes, but only with significant manual configuration. You need SPF, DKIM with rotation, DMARC with at least a none policy, RFC 8058 one-click List-Unsubscribe headers, valid PTR records, TLS, and a spam complaint rate below 0.3% (Google, 2024). Postfix itself handles none of the compliance work - it's the SMTP daemon. You add OpenDKIM, OpenDMARC, a suppression database, and FBL processing on top.
When does running Postfix yourself actually make sense?
Three narrow cases: a small low-volume transactional setup on an already-warmed IP, compliance scenarios where AWS data residency doesn't fit, and research or hobby setups where operator time is free. For commercial marketing and transactional senders without a dedicated mail-ops engineer, the deliverability and ops math points decisively at SES.
Does Mailblast work with self-hosted Postfix?
No. Mailblast is a hosted management layer on top of your own Amazon SES account (BYO-SES). It uses the SES API to send, so the underlying MTA is SES itself, not Postfix. If you want a hosted UI on top of Postfix, you would look at tools like Mautic or listmonk pointed at your own SMTP endpoint - not Mailblast.
Disclosure: Mailblast is a BYO-SES hosted email marketing platform, so we have a perspective on this comparison. We tried to characterize self-hosted Postfix on its real merits and limits; the ops profile and IP-reputation timelines come from public deliverability guidance and our own operator experience helping customers move off self-hosted stacks.