An honest look at open-source email infrastructure. Not a mail client, not a mail store — a fast, pluggable SMTP engine.

TL;DR

What it is: An MIT-licensed, event-driven SMTP server written in Node.js — a mail routing layer, not an all-in-one email suite [README].
Who it’s for: Developers and sysadmins who need a flexible, high-throughput SMTP gateway for filtering, routing, or outbound delivery. Not for non-technical founders [README][website].
Cost: $0 for the software (MIT). You pay for server infrastructure — typically $5–20/mo depending on mail volume.
Key strength: Extremely fast, horizontally scalable, and the plugin architecture makes custom mail behavior straightforward for any JavaScript developer [README].
Key weakness: This is not a turnkey solution. No web UI, no mailboxes, no webmail. You assemble it with other software (Dovecot, Postfix, SpamAssassin). The learning curve is steep if you haven’t operated an MTA before [README].
GitHub: 5,593 stars, MIT license, active development [merged profile].

Note: No useful independent third-party reviews were available for Haraka at time of writing — the sources collected during research contained off-topic content. This review is based on the official README, project documentation, and firsthand knowledge of the tool.

What is Haraka

Haraka is a mail transfer agent (MTA) — specifically, the part of email infrastructure that speaks SMTP. It accepts incoming connections, runs the message through a plugin chain, and either delivers it or forwards it elsewhere. It does not store mail, provide IMAP access, or come with a web interface. The project description says it plainly: “Haraka makes no attempt to be a mail store (like Exchange or Postfix/Exim/Qmail), a LDA, nor an IMAP server (like Dovecot or Courier). Haraka is typically used with such systems.” [README]

The project was started by Matt Sergeant, who spent ten years working on SpamAssassin and Qpsmtpd before writing Haraka. That background shows — the plugin system for spam filtering and message validation is the core feature, not an afterthought [README].

What makes Haraka distinct in the MTA space is that it’s written entirely in asynchronous JavaScript on Node.js. Every connection is handled non-blocking, which is why the homepage leads with “thousands of concurrent connections and thousands of messages per second” [website]. Traditional MTAs like Postfix handle concurrency through forked processes; Haraka handles it through the Node.js event loop. For high-volume relay scenarios, this matters.

The architecture is: you install Haraka globally via npm, initialize a server directory with haraka -i, configure which plugins run in config/plugins, and start it. Mail comes in, hits your plugin chain in sequence, and gets accepted, rejected, or forwarded. That’s the entire model [README].

Why people choose it

Haraka fills a specific gap that traditional MTAs make awkward: programmable, per-message behavior in JavaScript.

When you need Postfix to do something custom — say, route mail to different backends based on a database lookup, or apply custom header rewriting — you’re writing Perl scripts, patching milter interfaces, or fighting configuration file syntax that dates to the 1990s. In Haraka, the same logic is a JavaScript function with a callback. The README gives a concrete example: providing qmail-style extended addresses (user-anyword@domain.com) to an Exchange backend is “a few lines of code in Haraka” [README].

The other use case the README explicitly calls out is running Haraka as a mail submission agent (MSA) on port 587 — the port your email client uses to send outbound mail. With the auth plugin and DKIM plugin enabled, Haraka can serve as the submission endpoint for a custom email application or transactional email pipeline [README].

Versus Postfix: Postfix is battle-hardened, handles enormous volume, and has 30+ years of production deployment behind it. It’s the default MTA on most Linux distributions. The trade-off is that extending Postfix requires understanding its milter/policy server architecture, and the configuration surface is large and sometimes arcane. Haraka is easier to extend if your team writes JavaScript, and the plugin code is readable without diving into documentation. But Postfix has a much larger community, more production case studies, and is more conservative about changes.

Versus Postal: Postal is a Ruby-based, web-UI-equipped outbound mail server with a dashboard, queuing, and click tracking. It’s aimed at the transactional email use case (think a self-hosted Mailgun). Haraka has no UI and no built-in queue management interface — it’s a lower-level building block. If you want something you can hand off to a non-developer, Postal or Mailcow is a better fit.

Versus Mailu/Mailcow: These are complete email stacks — they bundle Postfix, Dovecot, an antispam layer, webmail, and an admin interface into a single Docker Compose deployment. Haraka is not in this category. Haraka is the SMTP layer only; you bring the rest.

The realistic Haraka adopter is a developer building a custom email-dependent product — a SaaS that needs to handle inbound webhooks from email, a high-volume transactional sender, or a company that needs a programmable filtering gateway in front of their existing mail infrastructure.

Features

Based on the README and project documentation:

Core SMTP engine:

Handles inbound and outbound SMTP [README]
Asynchronous, event-driven processing via Node.js — designed for high concurrency [README]
Built-in outbound delivery queue: mail flagged as relaying (via auth plugin) is automatically queued for outbound delivery [README]
Runs as both an MTA (port 25, inbound relay/filtering) and an MSA (port 587, authenticated submission) [README]
Plugin chain executes per-connection and per-message [README]

Plugin system:

All behavior is implemented as plugins — nothing is hardcoded into the server core [README]
Plugins are written in JavaScript (Node.js), with access to the full npm ecosystem [README]
First-party plugins for: SpamAssassin integration, HELO name validation, DNS Blocklist (DNSBL) checking, DKIM signing and verification [README]
Extended address routing, header manipulation, custom delivery logic — all doable in plugin code [README]
Community plugins available via npm under haraka-plugin-* naming convention

Spam and security:

SpamAssassin plugin for content-based filtering [README]
HELO/EHLO validation [README]
DNSBL checking (Spamhaus, etc.) [README]
DKIM signing for outbound, verification for inbound [README]
The config/host_list mechanism controls which domains the server accepts mail for, preventing open relay by default [README]

What it does NOT include:

Mail storage (no mailboxes) [README]
IMAP/POP3 server [README]
Web UI or admin dashboard
Webmail
Anti-virus scanning out of the box (though plugins exist)
Built-in queue monitoring UI

Pricing: SaaS vs self-hosted math

Haraka itself has no commercial tier, no SaaS version, no paid licenses. The software is MIT, costs zero, and the only pricing question is infrastructure.

What self-hosting Haraka costs:

For a low-to-medium volume setup (under 100K messages/day):

A $6–10/mo VPS (Hetzner CX21, 2 vCPU, 4GB RAM) is comfortable
Bandwidth: most VPS providers include 20TB+/mo outbound, so not a practical concern for email
IP reputation: this is the real cost — a fresh VPS IP is likely on blocklists. You’ll either need to warm up a dedicated IP or pay for a clean IP from your provider (typically $3–5/mo extra)

What you’re replacing:

If you’re sending transactional email through a managed service:

Mailgun: $35/mo for 50K emails, $80/mo for 100K
SendGrid: $19.95/mo for 50K, $89.95/mo for 100K
Postmark: $15/mo for 10K, $50/mo for 100K
Amazon SES: $0.10 per 1,000 emails — much cheaper, and often the actual competition for Haraka

At 50K messages/month, self-hosting Haraka on a $10 VPS costs $10/mo versus $35–80 on managed services. At 1M messages/month, the savings become significant — but so does the operational complexity (IP warming, bounce handling, feedback loops with major ISPs, monitoring).

The honest math: Haraka makes economic sense when you’re sending enough volume that managed ESP fees hurt, you have an engineer to run it, and you’re willing to own the deliverability problem. At low volume, Amazon SES at $0.10/1K emails is cheaper and less operational overhead.

Deployment reality check

Installing Haraka is straightforward. Getting it to deliver mail reliably is not, and no article about an SMTP server is honest unless it says this clearly.

Installation:

npm install -g Haraka
haraka -i /path/to/my_mailserver
haraka -c /path/to/my_mailserver

That’s the entire install sequence [README]. Haraka needs Node.js and npm — no other system dependencies.

What happens after install:

The default configuration accepts mail for domains in config/host_list and forwards it via the smtp-forward plugin to a backend [README]. You configure config/smtp_forward.ini with your destination. At this point you have a running SMTP server.

What can go wrong:

IP reputation. Every major ISP (Gmail, Outlook, Yahoo) rejects or spam-filters mail from unknown IPs. You’ll need to warm up your sending IP gradually, register with Google and Microsoft’s postmaster tools, set up reverse DNS (PTR record), SPF, DKIM, and DMARC. None of this is Haraka’s job — it’s your job as the operator.
Deliverability is a full-time concern. Bounce handling, feedback loop processing (abuse reports from ISPs), monitoring your IP against DNSBL lists — this is ongoing work, not a one-time setup. Managed ESPs handle this for you; self-hosting means you own it.
No queue UI. Haraka has an outbound queue, but inspecting or managing it requires command-line tools or log file spelunking. There’s no dashboard to click through and see what’s stuck.
Plugin compatibility. Haraka plugins are versioned npm packages. Mixing incompatible versions or finding that a community plugin hasn’t been updated for the current Haraka version is a real operational friction point.

Realistic time estimates:

Developer familiar with SMTP and Node.js: working install in 30–60 minutes, production-ready with SPF/DKIM/reverse DNS in a day.
Developer unfamiliar with email infrastructure: plan for 2–4 days of learning curve to get deliverability right.
Non-technical founder: not recommended without dedicated technical support.

Pros and Cons

Pros

MIT license, genuinely free. No paid tiers, no “open core” restrictions, no commercial licenses to buy if you want to embed it in your own product [merged profile][README].
JavaScript plugins with npm access. If your team writes Node.js, extending Haraka is natural. No learning Perl or fighting milter protocol [README].
High throughput by design. The event-driven architecture handles high concurrency without the per-process overhead of traditional MTAs [README][website].
Built-in outbound delivery. Haraka includes a delivery queue for authenticated mail — useful for building a transactional email system without a separate relay [README].
Good spam-filtering primitives. SpamAssassin, DNSBL, HELO validation, DKIM — the standard toolkit is there as first-party plugins [README].
Used in production at high-traffic sites. The homepage mentions real production deployment at scale, suggesting the codebase is not purely academic [website].
Active GitHub project. 5,593 stars, CI badges passing, continuous development [merged profile].

Cons

Not a complete email solution. No IMAP, no mailboxes, no webmail, no admin UI. You build a system around Haraka, not with Haraka [README].
Deliverability is 100% your problem. The hardest part of running your own email isn’t the SMTP software — it’s getting Gmail and Outlook to accept your mail. Haraka gives you no tools for this beyond the basics.
No queue management UI. Inspecting stuck mail, monitoring delivery rates, and diagnosing bounces requires command-line investigation [README — no UI mentioned].
Smaller community than Postfix. Postfix has decades of production knowledge, Stack Overflow answers, and blog posts. Haraka has a mailing list and GitHub issues.
Steep operational curve for email newcomers. SMTP, SPF, DKIM, DMARC, PTR records, IP warming — Haraka doesn’t abstract any of this. You learn or you fail.
No SaaS option. You can’t try Haraka without deploying it. There’s no hosted version to evaluate before committing to self-hosting.
Plugin ecosystem maturity varies. Community plugins range from production-grade to abandoned. Vetting is on you.

Who should use this / who shouldn’t

Use Haraka if:

You’re a developer building a product that needs programmable inbound or outbound email handling, and you want to write that logic in JavaScript without fighting Postfix’s configuration syntax.
You’re running high-volume transactional email (100K+ messages/month) and managed ESP fees are meaningful.
You need a filtering gateway in front of an existing mail system (Exchange, Postfix) and want to write the filter logic in Node.js.
You have an engineer who understands email infrastructure, or is willing to learn.
You want MIT licensing specifically — to embed the server in a product you’re building or reselling.

Skip it (use Mailcow or Mailu instead) if:

You want a complete, self-hosted email solution with mailboxes, webmail, and an admin panel.
You’re a non-technical founder who wants to escape Google Workspace pricing. That’s not what Haraka is.
You need something your team can operate without deep SMTP knowledge.

Skip it (use Amazon SES instead) if:

You want cheap transactional email without running infrastructure. SES at $0.10/1K emails is hard to beat for low-to-medium volume.
Deliverability problems will cost you more than ESP fees.

Skip it (use Postal instead) if:

You want a self-hosted Mailgun alternative with a web UI, click tracking, and queue management — a complete outbound email platform rather than a bare SMTP engine.

Skip it (stay on Postfix) if:

Your team already knows Postfix and your filtering needs are met by SpamAssassin milter. There’s no reason to migrate a working Postfix setup to Haraka.

Alternatives worth considering

Postfix — the battle-tested standard. More community resources, more production deployments, less JavaScript-friendly plugin architecture. The right choice for most traditional email setups.
Exim — another traditional MTA, highly configurable through its own scripting language. Popular in shared hosting environments.
Postal — Ruby-based transactional email platform with a web UI. Closer to a self-hosted Mailgun than a bare MTA. Better for teams that want operational visibility without command-line depth.
Mailcow — complete self-hosted mail stack (Postfix + Dovecot + webmail + antispam + admin UI) as a Docker Compose deployment. The “I just want my own email server” choice.
Mailu — similar to Mailcow, slightly lighter resource footprint.
Amazon SES — not self-hosted, but cheap ($0.10/1K) and operationally nearly free. Realistic alternative for transactional email at low-to-medium volume.
MailHog / Mailpit — development/testing SMTP servers only. Not for production.

Bottom line

Haraka is a well-built tool for a specific job: a fast, JavaScript-extensible SMTP layer that developers can customize without fighting traditional MTA configuration systems. The 5,593 GitHub stars and production deployment at high-traffic sites confirm it’s production-capable, not just a proof of concept. But it’s not the kind of “escape your SaaS bill this weekend” tool that appears elsewhere on this site. Running Haraka means owning the entire email delivery stack — IP reputation, bounce handling, DKIM/SPF/DMARC, monitoring. The software is the easy part.

If you’re a developer or sysadmin who wants programmable email routing in Node.js, Haraka is the right answer. If you’re a non-technical founder looking to self-host your email, start with Mailcow or Mailu — they’re complete solutions that won’t require you to become an SMTP expert. And if your main goal is cheap transactional email sending, Amazon SES will beat Haraka’s economics at anything under a million messages per month.

Sources

Primary sources (all claims in this article):

Haraka README — project description, features, installation, plugin architecture, deployment steps. https://github.com/haraka/Haraka
Haraka official website — homepage, feature summary, production usage claims. https://haraka.github.io/
Haraka merged profile — stars (5,593), license (MIT), category, GitHub URL. Internal data from unsubbed.co tool database.

Note: Third-party review sources provided for this article contained off-topic content unrelated to Haraka and were not used. Claims in this review are sourced exclusively from official project documentation and firsthand knowledge of the SMTP and email infrastructure space.