Rspamd

Last reviewed Sep 13, 2026 · 942 words

Rspamd is the spam filter inside almost every serious self-hosted mail stack you have heard of, and if you run mailcow, Mailu or docker-mailserver you already have it and can skip to the tuning section. For everyone building a mail server by hand, the news is this: Rspamd replaces SpamAssassin, DKIM signing, greylisting, rate limiting and a good chunk of your Postfix restrictions with one C daemon that scores a message in milliseconds rather than the seconds SpamAssassin can take, and the price is a Redis dependency plus a configuration layout that takes an evening to understand.

It is a scorer, not a mail server

Rspamd receives each message from your MTA through the milter protocol, runs a few hundred rules against it in parallel, and hands back a score and an action. It does not accept mail from the internet, store mailboxes, or deliver anything; Postfix and Dovecot still do those jobs. The rules span everything the email category cares about: SPF, DKIM and DMARC verification, DNS blocklists, URL reputation, a Bayesian classifier, a small neural network that learns from your own scoring history, fuzzy hashes of known spam, and a large set of heuristics about headers and encoding. Each rule adds or subtracts points, and the total is compared against thresholds that you own.

The defaults are: above 4 points, greylist; above 6, add a spam header; above 8, rewrite the subject; above 15, reject at SMTP time. Those numbers are set in local.d/actions.conf and I would leave them alone for the first month. Rejecting at 15 is conservative enough that false rejections are rare, and the header action lets Dovecot's Sieve move mail to Junk without losing anything.

Postfix needs three lines, Redis is not optional

Installation on Debian or Ubuntu is the project's own apt repository, which stays current where distribution packages lag. There is also the rspamd/rspamd Docker image. Either way, the Postfix side is:

smtpd_milters = inet:localhost:11332
non_smtpd_milters = inet:localhost:11332
milter_default_action = accept
milter_protocol = 6

Port 11332 is the proxy worker, the process that speaks milter. Port 11333 is the normal worker doing the scanning, and 11334 is the controller, which serves the web UI and the learning endpoints. milter_default_action = accept matters: if Rspamd is down, mail flows unfiltered rather than bouncing, which is the failure mode you want.

Redis is where the Bayes tokens, greylisting state, rate limits, fuzzy cache and the history you see in the web UI all live. Rspamd runs without it, but Bayes, greylisting and ratelimit silently do nothing, and people spend weeks wondering why the filter is not learning. Install Redis on the same host, point local.d/redis.conf at it with a single servers = "127.0.0.1"; line, and check the web UI's status page shows it connected.

The web UI and the learning loop

The controller UI on port 11334 is genuinely good: live throughput, a history of every scanned message with its symbols and score, a scan-a-message box for testing, and the ability to learn ham and spam. Set the password with rspamadm pw and paste the hash into local.d/worker-controller.inc; never leave the default q1 password on a reachable port, and put the UI behind your reverse proxy or a VPN.

Learning is what turns a good filter into a great one. The reliable pattern is Dovecot's IMAPSieve plugin calling rspamc learn_spam when a message is dragged into Junk and rspamc learn_ham when it is dragged out. That gives every user on the server a training button they already know how to use. Bayes needs about 200 examples of each class before it activates, so expect 2 to 4 weeks before the classifier's symbols show up in scores.

Outbound: sign with it, and watch the rate limits

The dkim_signing module signs your own outgoing mail once you drop a key under /var/lib/rspamd/dkim/ and add the selector and domain to local.d/dkim_signing.conf. This removes a separate OpenDKIM daemon from the stack, and DKIM plus a p=quarantine DMARC record is the minimum for your mail to reach Gmail. The ratelimit module protects you in the other direction: a compromised account sending 5,000 messages an hour gets throttled before your IP lands on a blocklist. Both are cheap wins that SpamAssassin never offered, and they are why SpamAssassin is now mainly of historical interest for new deployments.

When to skip all of this

If you want filtering without owning the configuration, use a bundled stack. Mailcow and Mailu ship Rspamd tuned and wired, and Stalwart takes the other route with its own built-in filtering engine and no Rspamd at all. The honest case for running mail yourself, and the reasons not to, are in self-hosted email, honestly. Rspamd by hand is for people who already run Postfix and Dovecot and want to see every rule fire.

What I'd do

Install from the project repository, add Redis, wire the three Postfix lines, set the controller password, and change nothing else for 30 days. During that month add the IMAPSieve learning hooks and move DKIM signing into Rspamd. After the month, read the history tab, find the 3 symbols that most often push real mail over 6, and adjust their weights in local.d/groups.conf rather than moving the thresholds. Run like that, Rspamd catches more than any hosted gateway I have used, on about 256 MB of RAM, and never becomes the thing that loses a customer's email.