Every few months a post surfaces on Hacker News arguing that you should run your own mail server because ESPs are extractive and Postfix is easy. The replies are filled with veterans explaining why, in 2026, a self-hosted MTA sending from a residential-adjacent VPS IP lands in Gmail's spam folder without passing Go.
Both camps are partly right. The decision depends on your volume, your tolerance for operational complexity, and how much placement risk you can afford. Let's walk through it.
For transactional mail at any meaningful volume, use a dedicated ESP relay (Postmark, SES, SendGrid). For personal mail, newsletter experiments, and one-off projects, direct send from Postfix on a mail-focused host is fine. For marketing mail at scale, there is no compelling direct-send path — use an ESP.
What "direct send" means
Your application or MTA (Postfix, Exim, OpenSMTPD, a cloud function) connects directly to the recipient's destination MTA over port 25. You own the IP, the DNS, the authentication, and the reputation.
What "relay" means: your application hands off to a third party (SendGrid, Postmark, SES, Mailgun, Postmark's SMTP endpoint). They do the actual delivery from their infrastructure, their IPs, their SMTP connections. You keep the sender domain and DKIM signing; they provide the transport.
Placement: relay wins, usually
On an apples-to-apples comparison (same domain, same content, same volume), a reputable relay beats a self-hosted Postfix for placement at Gmail and Outlook. Here is why:
- IP reputation. Postmark's IPs have been sending transactional mail since 2010. A random DigitalOcean droplet was assigned to a cryptominer last month.
- Port 25 reachability. Most cloud providers block outbound port 25 by default. You have to open a ticket and explain why. Some (DigitalOcean, Linode on new accounts) refuse outright.
- TLS and MTA-STS compliance. Modern relays handle this; a default Postfix config does not.
- Retry and bounce handling. Relays implement sophisticated retry logic that respects recipient feedback. A stock Postfix hammers the same destination on a defensive backoff and looks like spam.
- Complaint feedback loops. Gmail, Outlook, Yahoo, AOL and others offer feedback loops where they report user spam complaints back to the sending IP owner. Relays have these wired up; you have to apply for each FBL separately and act on the data.
Cost: direct wins, sometimes
At low volume, direct send is cheaper: a $5/month VPS plus a $12/year domain. At typical startup transactional volume (10k—100k messages/month), a relay like Postmark or SES is $10—50/month — still trivially cheap. At marketing volume (1M+ per month), dedicated IPs with an ESP run $200—1000/month; self-hosted infrastructure at that volume is a full-time job and costs more in ops time than you save in fees.
The break-even against ops time is almost always in favour of the relay.
Operational cost: relay wins, always
A self-hosted mail setup requires, at minimum:
- Postfix configuration and TLS setup.
- DKIM key generation, rotation, and DNS management.
- Monitoring the queue, bounces, deferrals.
- Warming IP reputation over weeks.
- Applying for feedback loops at each major provider.
- Reacting to blacklistings (which will happen).
- Keeping DNS (SPF, DKIM, DMARC, MTA-STS, BIMI) correct.
A relay reduces this to: configure a DKIM CNAME and an SPF include. The rest is the provider's problem.
The middle ground: Postfix as a smart host
You can run Postfix locally and relay through an ESP's SMTP endpoint. Your application speaks SMTP to localhost, Postfix queues and forwards to Postmark / SES / SendGrid. You get local queuing (survives network blips) without inheriting IP reputation.
# /etc/postfix/main.cf excerpt - relay through SES
relayhost = [email-smtp.us-east-1.amazonaws.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_security_level = encrypt
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_generic_maps = hash:/etc/postfix/generic# /etc/postfix/sasl_passwd
[email-smtp.us-east-1.amazonaws.com]:587 AKIAXXX:SECRET
# After editing:
postmap /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd*
systemctl reload postfixThis is what most self-hosted mail setups actually look like in 2026. They are nominally "self-hosted" but the final hop is a commercial relay.
When direct send actually makes sense
Direct send (you own the destination hop) is still the right choice in specific cases:
- You need a dedicated IP with a known history. You buy a warmed IP or migrate a long-running one; you need total control over it; no ESP gives you that.
- You send to a closed recipient universe. Internal mail, B2B with partners who whitelist, a specific institutional recipient who trusts your IP directly.
- You have staff who genuinely understand MTAs. A dedicated email infrastructure engineer who reads RFCs for fun. Rare.
- You have regulatory or political reasons to keep mail on your infra. Government, defence, certain regulated industries.
Most teams who try direct send from a generic VPS come back within 6—12 months after spending weekends troubleshooting why Gmail puts everything in spam. The time cost dwarfs the ESP subscription. Experience is the most expensive teacher.
The modern pattern: split by use case
Large senders commonly split mail across providers:
- Transactional (password reset, receipts): Postmark or SES. Narrow focus, highest placement, fastest latency.
- Marketing/bulk: SendGrid or Mailgun with a dedicated IP. Volume discounts, tracking dashboards.
- Internal/notifications: Relay via local Postfix through a cheap SES tier. Survives brief ESP outages; queue.
Each category has different placement, cost, and feature trade-offs. A single ESP that does all three well does not really exist.
Monitoring both paths
Whichever path you pick, monitor placement independently of the provider's dashboard. Your ESP reports delivered vs bounced; it cannot report inbox vs spam. A seed-based probe answers the question that actually matters.