Server — Mail — Rspamd

The Razor, Pyzor, and DCC articles established SpamAssassin as the spam filtering foundation for February’s mail setup, with each collaborative tool adding a layer on top. Before going further, this article addresses a question that should have come earlier: is SpamAssassin the right choice for a new mail server deployment in 2026, or has the field moved on?

The honest answer is that the field has moved on. Rspamd is now the default for new mail deployments, and understanding why helps clarify what decision February’s mail setup is actually making.

What Rspamd is

Rspamd is a spam filtering daemon written in C and Lua. It integrates with Postfix via the milter protocol, which means it connects directly as a Postfix content filter without the intermediary processes that SpamAssassin requires. It includes built-in support for DKIM signing and verification, SPF checking, DMARC enforcement, greylisting, fuzzy hash checking (its own equivalent of Razor/Pyzor/DCC), Bayesian filtering, and neural network scoring, all in a single daemon.

It ships with a web interface for monitoring, reviewing mail decisions, and training the Bayesian filter. It requires Redis for some modules, which February already has in the infrastructure plan.

It is fast. The architecture processes each message asynchronously with non-blocking DNS lookups, rather than forking a new process for each message as SpamAssassin does. On comparable hardware with comparable rules, Rspamd processes messages significantly faster than SpamAssassin.

What SpamAssassin is, in 2026

SpamAssassin is a mature, battle-tested Perl-based spam filter that has been in production use since 1997. Version 4.0.2 shipped in August 2025 and the project is actively maintained. It has an enormous ecosystem of third-party rule sets, decades of tuning documentation, and a well-understood operational model.

What SpamAssassin does not have is a native milter interface. Integrating it with Postfix requires either the spamass-milter intermediary process or the content filter re-injection model, both of which add moving parts. It processes messages synchronously with one process per message. DNS lookups are sequential rather than concurrent. At low mail volumes none of this matters; at higher volumes the difference becomes measurable.

SpamAssassin’s collaborative filtering, as covered in the Razor, Pyzor, and DCC articles, works by calling external tools as subprocesses. Rspamd handles equivalent functionality internally: its fuzzy hash system queries its own distributed network, and the integration is tighter and faster.

Where the ecosystem stands

The signal from the broader mail server community is clear. Every major self-hosted mail stack that has made an architectural decision in the last few years has chosen Rspamd. Mailcow has shipped Rspamd as its spam engine for years. Mailu uses Rspamd. Docker-mailserver moved Rspamd to its default. The migration from SpamAssassin is effectively complete for new deployments.

SpamAssassin is not dead. It is maintained, it receives updates, and it works well. But it is the choice you make when you have an existing SpamAssassin deployment you are not ready to migrate, or when a specific third-party rule set you rely on has no Rspamd equivalent. For a new deployment, starting with SpamAssassin in 2026 is swimming against the current.

The honest position for February

The previous three articles built out a SpamAssassin setup with Razor, Pyzor, and DCC. That work is not wasted: the conceptual understanding of collaborative spam filtering applies regardless of which daemon runs the checks. But the question of which daemon to run is worth answering directly.

For February, the argument for SpamAssassin is:

• The Razor, Pyzor, and DCC articles are already written and the setup is understood.
• SpamAssassin’s rule ecosystem is more extensively documented.
• SpamAssassin requires no Redis dependency, which simplifies the stack slightly if Redis is not otherwise needed.

The argument for Rspamd is:

• Native milter integration with Postfix is simpler than the SpamAssassin content filter model.
• Built-in DKIM signing means one fewer component to configure separately.
• The web interface provides visibility into spam decisions that SpamAssassin does not offer without additional tooling.
• The collaborative filtering, greylisting, and Bayesian components are integrated rather than assembled from separate tools.
• This is where the community is, which means better documentation for new problems and a longer maintenance runway.

The recommendation

Use Rspamd.

Not because SpamAssassin is bad — it is not — but because starting a new mail server on SpamAssassin in 2026 is choosing the tool that the community is moving away from, when the tool the community is moving toward is available, actively developed, and genuinely better integrated with Postfix.

The Razor, Pyzor, and DCC articles provide useful background on how collaborative spam filtering works. Rspamd’s equivalent functionality, the fuzzy hash system and reputation modules, operates on the same principles. The conceptual grounding carries over even if the specific tooling does not.

The practical implication is that the next article in this series is the Rspamd install rather than a SpamAssassin install. The SpamAssassin add-on articles stand as reference material, and if you prefer SpamAssassin for your own reasons, the path from those articles to a working Postfix integration is straightforward. But February will run Rspamd.

What Rspamd does not replace

Rspamd is a spam filter. It is not:

An antivirus scanner. ClamAV integration is available via Rspamd’s antivirus module, and February’s mail setup should include it. That is a separate article.

A Postfix replacement. Rspamd sits alongside Postfix, not in place of it. Postfix handles the SMTP layer; Rspamd evaluates message content and tells Postfix what to do with it.

A DKIM signing setup on its own. Rspamd can handle DKIM signing, which removes the need for a separate tool like OpenDKIM. The Rspamd install article covers this as part of the configuration.

What Rspamd needs

Rspamd has one dependency not previously in the series: Redis. Several Rspamd modules, including rate limiting, greylisting, DMARC reporting, and the Bayes statistical filter, require Redis for storage. The Redis introduction article earlier in this series covers the decision; the install article that follows it will configure Valkey for Rspamd’s use.

If Redis is already installed and running on February by the time the Rspamd install article is reached, the dependency is already satisfied. If not, the install article notes what is needed.