Stop running Postfix in 2026

I deleted my Postfix config last month and I've never been happier.

Some context. I have a small fleet of Linux boxes that run cron jobs, build agents, deployment scripts. They send email. Status reports, deploy notifications, alerts when a backup fails. The kind of thing every DevOps shop has.

For years, the canonical answer for "how do I send transactional email from a Linux box" has been: install Postfix, configure a smarthost, set up DKIM, hope nothing breaks. I had this exact setup, lovingly maintained, on six servers.

Last month I replaced all of it with nylas email send.

Why Postfix is overkill for transactional sends

Postfix is great. It's also configured to be a full mail server, and it brings the full mail server problem set with it:

• 200+ config directives in main.cf
• DKIM signing daemon (OpenDKIM) as a separate process
• TLS cert management (or relying on opportunistic TLS, which is its own can of worms)
• Bounce handling
• Queue management on disk
• Periodic security advisories that need patching

If you're running a real mail server (incoming + outgoing, multiple users, vacation responders, the works), Postfix is the right answer. But if all you need is "this script needs to email me when the backup fails," Postfix is doing 50x more than required.

What I switched to

brew install nylas/nylas-cli/nylas       # macOS
# or:
curl -fsSL https://cli.nylas.com/install.sh | bash   # Linux

nylas auth config --api-key <YOUR_KEY>

nylas email send \
  --to oncall@example.com \
  --subject "Backup failed at $(hostname)" \
  --body "Run timestamp: $(date -u +%FT%TZ). Check /var/log/backup.log."

That's it. No Postfix, no smarthost, no DKIM keys to rotate. The CLI uses HTTPS to deliver the message, which means it works through firewalls that block SMTP ports. CI containers, sandboxes, GitHub Actions runners, anywhere outbound 443 is open.

What I miss

I'll be honest, a few things.

• Local queueing. Postfix queues messages locally if the relay is unreachable. The CLI does not. If the API is down, the send fails. For most transactional cases this is fine (the cron job can retry). For audit-critical sends, you'd want a local buffer.
• Header surgery. With Postfix you can rewrite headers in arbitrary ways via header_checks. The CLI lets you set common headers but not arbitrary ones.
• The smug satisfaction of having dovecot-imapd and postfix-mta both green in systemctl. Genuinely.

What I don't miss

• Reading Postfix's hieroglyphic logs.
• Forgetting to renew an LE cert and discovering it via Connection refused at 4am.
• The annual "wait, is OpenDKIM still maintained?" panic.
• Six servers' worth of main.cf drift.

Practical advice

If you're running Postfix to send transactional email and nothing else:

1. Audit what your scripts actually do. Most just call mail or sendmail with a body and recipient.
2. Replace those calls with nylas email send (one-line drop-in for most).
3. Decommission the local mail daemon.
4. Reclaim the cognitive overhead.

Full setup walkthrough: Send email from any Linux server in 60 seconds.

Some readers will, correctly, point out that Postfix isn't the only option here. sendmail, exim, msmtp all do the relay-only job better. They're right. But the broader argument holds: if you're a developer writing a deploy script in 2026, you shouldn't need to touch any mail daemon to send a status email. Done.

Command references:

• nylas email send — send email
• nylas email list — read messages
• nylas mcp install — connect to AI assistants
• Full command reference

Related posts:

• 5 nylas-cli commands every developer should know
• Automate Your Entire Email Workflow from the Terminal