Spam hasn’t gone anywhere. Keep coming back to it, as I hate cleaning up my INBOX and so do my clients! In fact, AI-generated spam has made the problem noticeably worse through 2025 and into 2026 — it’s more convincing, passes basic heuristic checks that would’ve flagged template spam instantly, and arrives in higher volumes. Research now puts AI-generated content in over 82% of phishing emails analysed in recent periods. The tooling to fight it has evolved too, and the gap between the best options and the rest has never been wider.
This article is a full comparison of every major open source anti-spam tool available in 2026 — covering filter engines, full mail stacks, and MX-level gateways — with honest takes on what’s still relevant, what’s coasting on legacy reputation, and what you should probably leave behind.
One thing up front: this article is organised by type, not just alphabetically, because a “filter engine” and a “full mail stack” are fundamentally different things and comparing them side-by-side without that context is misleading. A filter engine doesn’t handle mail flow. A full stack isn’t designed to protect someone else’s mail server. These are different tools for different problems.
Quick Answer: Open source anti-spam in 2026 is dominated by Rspamd as the filter engine, mailcow/Mailu as full Docker stacks, and Proxmox Mail Gateway for MX-level external protection.
Form Spam Protection ? If your are looking for a modern spam protection system for forms, check out mosparo.
Pure Docker ? Check the 7 days of Docker article.
How Anti-Spam Tools Are Categorised
Quick Answer: Anti-spam tools fall into three types: filter engines (scan mail), full mail stacks (everything bundled), and gateways (sit upstream of any mail server).
Category 1 — Filter Engines
These are pure spam detection libraries and daemons. They don’t send or receive email themselves — they just analyse messages and return a score or verdict. Examples: Rspamd, Apache SpamAssassin, Amavisd-new. You integrate them into an MTA (Postfix, Exim, Sendmail) via milter, SMTP re-injection, or pipe. They’re the brains — not the plumbing.
Category 2 — Full Mail Stacks
Docker Compose bundles that include everything — SMTP server (Postfix), IMAP server (Dovecot), spam filter (Rspamd), antivirus (ClamAV), webmail, admin UI. You get a complete mail server in one deployment. Examples: mailcow: dockerized, Mailu, docker-mailserver. The trade-off is that their spam filtering is internal and not designed to protect any other server.
Category 3 — Mail Gateways
Dedicated servers that sit upstream of any mail server. Your MX record points at them. They filter all inbound mail and relay clean messages to your real server — whether that’s Exchange, cPanel, G Suite with custom routing, or your own Postfix. Examples: Proxmox Mail Gateway, ASSP. This model works with literally any downstream mail server regardless of platform.
Tool | Category | Docker | External Use | Language | Activity |
|---|---|---|---|---|---|
Rspamd | Filter Engine | Official | Yes (milter) | C | Very Active |
SpamAssassin | Filter Engine | Community | Yes (spamd TCP) | Perl | Maintained |
Amavisd-new | Filter Engine | Community | Partial | Perl | Slowing |
ASSP | Gateway/Proxy | None | Yes (SMTP proxy) | Perl | Slow |
MailScanner | Gateway Scanner | Community | Partial | Perl | Slow |
Proxmox Mail Gateway | Mail Gateway | None (VM) | Yes (MX-level) | Perl/C | Active |
mailcow: dockerized | Full Stack | Native | No | Mixed | Very Active |
Mailu | Full Stack | Native | No | Python | Active |
docker-mailserver | Full Stack | Native | No | Bash/Mixed | Active |
ClamAV | AV Engine | Official | Yes (clamd TCP) | C | Active |
Filter Engines: The Core Detection Layer
Quick Answer: Filter engines are the brains — they detect spam but don’t handle mail flow. Rspamd dominates in 2026; SpamAssassin is still viable for legacy setups.
These tools do one thing: they analyse email and return a verdict. No SMTP listener, no delivery, no queuing. You wire them into an MTA and they do the scoring. Understanding this distinction saves a lot of confusion when people ask “but can it receive mail?” — no, and it’s not supposed to.
Rspamd
Quick Answer: Rspamd is the fastest, most capable open source spam filter in 2026 — C-based, neural network module, full DKIM/SPF/DMARC, built-in web UI, official Docker image.
- Type: Filter Engine
- External Use: Yes — milter protocol (port 11332) or HTTP API (port 11333), binds to any interface
- Docker: Official image — rspamd/rspamd on Docker Hub
- Actively Maintained: Yes — monthly releases, 2026 versions confirmed (v3.14.3 in mailcow 2026-03)
- Best For: Any modern self-hosted mail setup; standalone Docker filtering service for external MTAs
Strengths: Written in C — genuinely fast, handles high mail volumes without breaking a sweat. Multi-layer detection: Bayesian filtering backed by Redis, DNSBL/URIBL checks, fuzzy hashing for image spam, a neural network module that trains itself over time, full SPF/DKIM/DMARC validation, and a greylisting module. DKIM signing is built in so you don’t need a separate tool. The web UI on port 11334 lets you view stats, train Bayes, and adjust scores without touching config files. Milter protocol means it works with Postfix, Sendmail, Exim, and any MTA that supports milter. HTTP API for non-milter integrations. The official Docker image has proper volume mounts for config and data.
Weaknesses: Config isn’t immediately intuitive — you work with /etc/rspamd/local.d/*.conf files and need to understand the override system before it clicks. Pure filter engine, no MTA included (that’s by design, but worth being clear about). The neural network module needs time and traffic volume before it trains into something meaningfully effective — don’t expect magic on day one.
Here’s a standalone Rspamd Docker Compose you can spin up as an external filtering service — connects to your existing Postfix via milter on port 11332:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
services: rspamd: image: rspamd/rspamd:latest ports: - "11334:11334" # Web UI - "11332:11332" # Milter - "11333:11333" # HTTP API volumes: - ./rspamd/local.d:/etc/rspamd/local.d - rspamd_data:/var/lib/rspamd depends_on: - redis restart: unless-stopped redis: image: redis:7-alpine volumes: - redis_data:/data restart: unless-stopped volumes: rspamd_data: redis_data: |
Once that’s running, tell your Postfix to use it by adding smtpd_milters = inet:rspamd-host:11332 to /etc/postfix/main.cf. Done.
Apache SpamAssassin
Quick Answer: SpamAssassin v4.0.2 (August 2025) is battle-tested with massive rule libraries — still solid for legacy setups, but Rspamd outperforms it on speed and modern features.
- Type: Filter Engine
- External Use: Yes — spamd daemon accepts TCP connections on port 783 from any remote spamc client
- Docker: Community images only (no official image)
- Actively Maintained: Yes — v4.0.2 released August 2025, adds Perl 5.42 support and a new Redirectors plugin
- Best For: Legacy integrations, teams already running SA for years, Amavis-based pipelines not yet ready to migrate
Strengths: Decades of community rule development. The third-party ruleset ecosystem is enormous — KAM, SARE, and others add detection coverage well beyond what ships in the base install. The sa-update tool pulls fresh rules automatically on a cron. Bayesian filtering, header analysis, body rules, DNSBL lookups. The spamc/spamd protocol supports genuine remote scanning — run spamd on a dedicated filtering server and any host with the spamc client installed can submit mail for scoring over TCP. SSL and gzip compression are both supported for remote scanning. SpamAssassin remains the reference implementation that most other tools benchmark against.
Weaknesses: Perl-based — significantly slower than Rspamd, especially at scale. No built-in web UI. Memory usage can get heavy under load. Config syntax is powerful but verbose. The new Redirectors plugin in v4.0.2 is genuinely useful, but if you’re starting fresh in 2026, Rspamd is the better choice for raw performance. SpamAssassin’s real advantage is the ecosystem, not the engine itself.
Remote scanning with spamc — useful when your MTA box doesn’t run spamd locally:
|
1 2 3 4 5 6 7 8 9 10 |
# Connect to a remote spamd instance for scanning spamc -d 192.168.1.10 -p 783 < email.eml # With SSL encryption spamc -d spamd.example.com -p 783 --ssl < email.eml # Update rules via cron (run as root or the sa user) sa-update && sa-compile && systemctl restart spamassassin |
Amavisd-new
Quick Answer: Amavis is the classic Postfix ↔ SpamAssassin/ClamAV glue layer — functional but aging, with active Docker projects now shifting to Rspamd instead.
- Type: Filter Engine (SMTP content filter / glue layer)
- External Use: Partial — any Postfix can route through Amavis via
content_filter = smtp:[host]:10024, but in practice it’s almost always co-located - Docker: Community images (mlan/postfix-amavis — now deprecated in favour of mlan/rspamd)
- Actively Maintained: Slowing — the mlan project has explicitly deprecated their Amavis Docker image
- Best For: Existing Amavis deployments that aren’t yet ready to migrate to Rspamd
Strengths: Well-understood integration pattern with Postfix. Acts as an SMTP re-injection layer: Postfix hands mail to Amavis on port 10024, Amavis runs SpamAssassin and ClamAV, Amavis returns cleaned mail to Postfix on port 10025. Supports multiple AV engines simultaneously. Long deployment history in production environments.
Weaknesses: The writing is clearly on the wall. The most active Docker maintainer for the Postfix/Amavis combo (mlan) has deprecated their Amavis image outright and moved to Rspamd, noting that “Amavis is growing old and issues with maintaining functionality has started to appear.” Perl-based overhead. If you’re building anything new in 2026, start with Rspamd instead and skip this step entirely.
Mail Gateways: External Protection for Any Server
Quick Answer: Mail gateways sit upstream of your real mail server via MX record or SMTP proxy — they protect Exchange, cPanel, Office 365 relay setups, and any server you can’t modify directly.
Here’s the model: you change your domain MX record to point at the gateway. All inbound mail arrives at the gateway first, gets filtered, and clean mail is forwarded to your real server on an internal port. Your real server is never exposed directly to the internet. Nobody is connecting to port 25 on Exchange — they’re connecting to port 25 on your gateway. This works with any mail server regardless of platform. Exchange, Postfix, cPanel, IBM Domino — doesn’t matter.
This is a fundamentally different deployment model from running Rspamd as a milter on the same host as your MTA. Gateways are for when you can’t touch the mail server directly, or when you want that separation layer at the network level.
Proxmox Mail Gateway
Quick Answer: Proxmox Mail Gateway is the best open source MX-level gateway — free, feature-complete, web UI included — but it’s VM/bare-metal only with no Docker image.
- Type: Mail Gateway (MX-level)
- External Use: Yes — designed exactly for this; works with any downstream mail server
- Docker: None — Debian-based VM or bare metal only
- Actively Maintained: Yes — v9.0 released October 2025, built on Debian 13 “Trixie” with kernel 6.14, ClamAV 1.4.3, SpamAssassin 4.0.2
- Best For: Businesses protecting Exchange, cPanel, Office 365 custom routing, or any server they can’t directly filter
Strengths: This is the dedicated open source MX gateway. Deploy it as a VM, change your MX records to point at it, and all inbound mail hits PMG before reaching your real server — no matter what that real server is. Uses SpamAssassin 4.0.2 and ClamAV 1.4.3 under the hood. Web UI for quarantine management, rule configuration, reporting, and per-domain settings. Cluster support for high-availability deployments. Relay domain configuration supports forwarding to multiple downstream servers. Greylisting cuts a meaningful percentage of spam at the connection level. PMG detects mail to non-existent users at the SMTP level — before the message is even accepted — which can reduce analysed traffic by up to 90%. Free and fully open source.
Weaknesses: No Docker image — this is a VM commitment. Requires a dedicated server or a hypervisor slot. First-time setup involves public DNS changes (updating your domain’s MX records) which is a meaningful step that affects live mail flow. The web UI is functional and comprehensive but not exactly modern-looking.
The MX change is straightforward but worth spelling out. Normally your MX record points directly at mail.yourdomain.com — your real server exposed on port 25. With PMG you create a new A record for pmg.yourdomain.com pointing at your PMG VM’s IP, then update your domain MX record to pmg.yourdomain.com. PMG accepts all inbound mail on port 25, filters it, and relays clean mail to your real server on port 26 (or any configured relay port). Your real mail server listens on port 26 only — never exposed on port 25 to the public internet.
ASSP (Anti-Spam SMTP Proxy)
Quick Answer: ASSP is a Perl-based transparent SMTP proxy that intercepts traffic for any mail server — Exchange, Postfix, Domino — without changing how your MTA handles delivery.
- Type: SMTP Gateway / Proxy
- External Use: Yes — designed as a transparent proxy for any SMTP server on the same host or a separate server
- Docker: None — OVA appliances available for Linux and FreeBSD, Perl install otherwise
- Actively Maintained: Slow — v2.8.1 build 24261 is current as of February 2026, development has slowed
- Best For: Organisations needing MTA-agnostic spam protection without committing to an MX-level gateway
Strengths: ASSP explicitly documents support for Sendmail, qmail, Postfix, iMail, Exchange, Courier, Mercury, and IBM Lotus Domino — this is genuinely MTA-agnostic in a way that few tools can claim. It works by intercepting port 25 traffic, filtering it, then forwarding clean mail to your real SMTP server on an alternate port. The feature set is genuinely impressive: Bayesian filtering plus a Hidden Markov Model, greylisting, DNSBL/DNSWL/URIBL, SPF, DKIM, DMARC, ARC, SRS, backscatter detection, attachment blocking, IPv6 support, SSL/STARTTLS, LDAP user verification for rejecting mail to non-existent users, and SNMP monitoring. Browser-based UI with no separate web server dependency. OVA appliances make deployment reasonably painless.
Weaknesses: No Docker image in 2026. Perl-based. Development has slowed noticeably compared to the Rspamd ecosystem. The UI feels dated. If you have the choice between ASSP and Proxmox Mail Gateway for external protection, PMG is better maintained. ASSP’s real value is in the MTA-agnostic angle when you can’t use a dedicated gateway VM.
MailScanner
Quick Answer: MailScanner wraps SpamAssassin and ClamAV into a gateway-style scanner — useful for dedicated filtering servers but requires Postfix or Exim as the transport layer.
- Type: Gateway Scanner
- External Use: Partial — can run on a dedicated filtering server with Postfix, but requires MTA co-location
- Docker: Community images (not officially maintained)
- Actively Maintained: Slow
- Best For: Dedicated spam and virus filtering servers for organisations that prefer SpamAssassin over Rspamd
Strengths: Combines SpamAssassin and ClamAV (and other AV engines) into a single pipeline. Runs between two Postfix queues — inbound queue to MailScanner, then cleaned mail to outbound queue. Supports multiple AV engines simultaneously. Long history in enterprise environments. Custom ruleset support.
Weaknesses: Requires Postfix or Exim — not truly MTA-agnostic like ASSP. Slower development than Rspamd-based projects. No official Docker image. For most new deployments in 2026, an Rspamd-based solution is more practical and better supported.
Full Mail Stacks: Everything in One Docker Compose
Quick Answer: Full mail stacks bundle SMTP, IMAP, spam filtering, antivirus, and webmail into one deployment — great for self-hosting, but the spam filter is internal and can’t protect other servers.
A note on External Use before we go further: all three stacks below are listed as “No” for external use. That’s intentional and not a knock on them. These are complete self-hosted solutions. The Rspamd running inside mailcow is configured to work with mailcow’s Postfix and trains on mailcow’s Dovecot IMAP actions. It’s not designed or practical to extract as a standalone filtering service for other servers. If you need external filtering, use a dedicated filter engine (Rspamd standalone, SpamAssassin spamd) or a gateway (PMG, ASSP).
mailcow: dockerized
Quick Answer: mailcow: dockerized is the most complete self-hosted Docker mail stack in 2026 — Postfix, Dovecot, Rspamd 3.14.3, ClamAV, SOGo webmail, web admin — with monthly active releases.
- Type: Full Mail Stack
- External Use: No — Rspamd runs internally, not designed for external mail filtering
- Docker: Yes — native Docker Compose, actively developed
- Actively Maintained: Very active — 2026-03 release shipped with forced 2FA, DNS-01 ACME challenge support, and Rspamd 3.14.3
- Best For: Anyone who wants a complete, production-grade self-hosted mail server with everything included
Strengths: The most feature-complete open source mail stack available right now. It ships with Postfix (SMTP), Dovecot (IMAP/POP3), Rspamd 3.14.3 (spam filtering), ClamAV with Olefy (AV including Office document scanning), SOGo (webmail, CalDAV, CardDAV), full web admin UI, Let’s Encrypt integration, and DKIM key management all in one. Rspamd auto-trains from user Junk folder actions — when your users move messages to Junk, the filter learns. Monthly releases with detailed changelogs mean the project is moving fast. Large community means you’ll find answers to most problems quickly.
Weaknesses: Heavy — 4 GB RAM is the minimum recommendation and you’ll want more in production. Lots of moving containers means more to manage and monitor. Not for users who want a minimal footprint. Upgrading requires care and a read-through of the changelog. The internal spam filter can’t be extracted to protect other servers.
Deploying mailcow takes about ten minutes once you have a VM ready:
|
1 2 3 4 5 6 |
git clone https://github.com/mailcow/mailcow-dockerized cd mailcow-dockerized ./generate_config.sh docker compose pull && docker compose up -d |
The generate_config.sh script asks for your hostname and timezone and writes a mailcow.conf file. That’s genuinely most of the required config for a basic deployment.
Mailu
Quick Answer: Mailu is the simpler Docker mail stack — less complex than mailcow, Rspamd built in, good documentation, better fit for single-domain small deployments.
- Type: Full Mail Stack
- External Use: No — Rspamd is internal to the stack
- Docker: Yes — native Docker Compose
- Actively Maintained: Active
- Best For: Smaller self-hosted deployments, single-domain setups, users who find mailcow too complex or resource-heavy
Strengths: Docker-native from the start. The setup wizard at setup.mailu.io generates your docker-compose.yml and .env file interactively — no hand-editing of config before first boot. Lighter than mailcow in resource terms. Includes Postfix, Dovecot, Rspamd, ClamAV, and a choice of Roundcube or Snappymail for webmail, plus an admin UI. Documentation is clear and well-maintained. Lower RAM requirements make it viable on smaller VPS instances.
Weaknesses: Less feature-rich than mailcow — no built-in CalDAV/CardDAV in the basic configuration, simpler admin UI. Smaller community means less coverage in forums and Stack Overflow when things go sideways. The spam filter is internal and not extractable for other servers.
docker-mailserver
Quick Answer: docker-mailserver is a production-ready single-container mail server — scriptable config, Kubernetes support, no web UI, with Rspamd or SpamAssassin/Amavis available.
- Type: Full Mail Stack
- External Use: No — spam filtering is internal
- Docker: Yes — single container design, Kubernetes supported
- Actively Maintained: Active — large GitHub community
- Best For: Developers and sysadmins who want infrastructure-as-code mail hosting with no web UI and full scriptability
Strengths: Single container with Postfix, Dovecot, and either Rspamd (recommended) or SpamAssassin/Amavis. Config is entirely via environment variables and config files — ideal for GitOps and IaC workflows where you want everything version-controlled. Kubernetes support makes it the right choice for teams running container orchestration. Rspamd integration handles SPF, DKIM, and DMARC validation as part of the spam score calculation. Greylisting is available via RSPAMD_GREYLISTING=1. Lower overhead than mailcow.
Weaknesses: No web UI at all — everything is CLI and config files. Not for non-technical users. External spam filtering is not a supported use case. You need to be comfortable with the command line before this becomes a pleasant experience rather than a frustrating one.
ClamAV: The Antivirus Layer
Quick Answer: ClamAV isn’t a spam filter, but it’s the antivirus companion to every spam solution on this list — open source, Docker-native, essential for any complete mail security stack.
- Type: Antivirus Engine
- External Use: Yes — clamd daemon accepts TCP connections from any host
- Docker: Official image — clamav/clamav on Docker Hub
- Actively Maintained: Yes — maintained by Cisco
- Best For: Virus, malware, and phishing attachment scanning alongside any spam filter
ClamAV pairs with everything on this list. Rspamd has native ClamAV integration. SpamAssassin can call it via the clamdscan interface. mailcow bundles it with Olefy for Office document scanning (docx, xlsx, pptx — the formats attackers love). docker-mailserver includes it. Proxmox Mail Gateway ships v1.4.3 in its latest release.
It’s worth being clear about what ClamAV does and doesn’t do: it’s not a spam filter and it doesn’t score messages for spamminess. What it catches is malware payloads, infected attachments, and phishing documents. AI-generated spam text that scores below threshold will sail past ClamAV just fine — that’s not its job. Its job is to catch the Excel file with the macro dropper, the PDF with the embedded JavaScript, or the ZIP with the ransomware payload. Run it alongside your spam filter, not instead of it.
The official Docker image handles signature updates automatically via freshclamd:
|
1 2 3 4 5 6 7 8 9 10 |
clamav: image: clamav/clamav:stable container_name: clamav volumes: - clamav_data:/var/lib/clamav environment: - CLAMAV_NO_FRESHCLAMD=false restart: unless-stopped |
Connect Rspamd to it by adding a ClamAV configuration in your Rspamd local.d directory pointing to the clamd TCP socket. Rspamd will then submit every message body and attachment to ClamAV for scanning as part of its scoring pipeline.
2026 Trends in Open Source Anti-Spam
Quick Answer: The big shifts in 2026: AI-generated spam is the primary threat, Rspamd has won the filter engine debate, DMARC enforcement is now table stakes, and Docker-first is the default deployment model.
AI-Generated Spam Is the New Threat
LLM-generated spam is the problem that 2003-era techniques weren’t designed for. Template spam has predictable patterns — repeated phrases, suspicious link structures, tell-tale header combinations. AI-generated spam can be unique every time, contextually appropriate, grammatically correct, and written in the exact style of a trusted contact if the attacker has done their homework. Over 82% of analysed phishing emails in recent research contained AI-generated content.
What this means for your filter stack: static rulesets are less effective than they used to be. Neural network-based filters that learn from traffic patterns (Rspamd’s neural module, Bayesian classifiers trained on recent data) are better positioned to catch this than fixed heuristics. Train your filters constantly. Make it easy for users to report spam. Feed those reports back into Bayes training. The signal from your own traffic is more valuable than any pre-built ruleset when the threat is this adaptive.
Rspamd Has Won the Filter Engine War
The migration from SpamAssassin and Amavis to Rspamd is effectively complete for any new deployment. mailcow has shipped Rspamd as its spam engine for years. docker-mailserver is moving Rspamd to the default. The mlan Docker project deprecated their Amavis image and recommends Rspamd. Mailu uses Rspamd. The argument is over — if you’re starting a new mail infrastructure in 2026, you’re using Rspamd.
SpamAssassin isn’t dead — v4.0.2 shipped in August 2025 and it’s still maintained. But it’s the choice you make when you have an existing SA deployment you’re not ready to migrate, not the choice you make when you’re building something new.
DMARC Enforcement Is Table Stakes
Every tool on this list supports SPF, DKIM, and DMARC. In 2026, deploying a mail server without DMARC enforcement is indefensible. Google and Microsoft both enforce strict DMARC requirements for bulk senders as of 2024, and the filtering pressure has trickled down to all inbound mail handling. If you’re not validating DMARC on inbound and publishing DMARC on outbound, you’re behind.
Rspamd handles all three — SPF, DKIM validation, and DMARC — as part of its standard scoring pipeline. No extra tools needed. docker-mailserver’s Rspamd integration does the same. There’s no excuse for a 2026 mail stack to be missing these.
Docker-First Is the Default
Every major active mail project ships as Docker Compose. Bare-metal installs still happen — PMG and ASSP are VM or native installs — but the momentum and the developer mindshare are entirely in containerised deployments. If a project doesn’t have a Docker Compose example in 2026, it’s a signal about where the project is in its lifecycle.
Greylisting Is Still Effective
Despite being a 2003-era technique, greylisting still catches a meaningful percentage of spam because most spam servers don’t retry after a temporary rejection. A legitimate mail server that receives a 451 response will queue the message and retry — spam infrastructure typically doesn’t bother. Proxmox Mail Gateway reports that greylisting can reduce email traffic by up to 50%. Rspamd’s greylisting module is worth enabling — it’s low-effort and the false-positive rate on greylisting alone is minimal for well-configured senders.
The Bottom Line: Which One Should You Use?
Quick Answer: mailcow for full self-hosted stacks, Rspamd standalone for external filtering, Proxmox Mail Gateway for protecting servers you don’t control.
Your Situation | Best Choice | Runner-Up |
|---|---|---|
Self-hosted mail, want the full stack | ||
Self-hosted, want minimal footprint | ||
Need to protect Exchange / cPanel / Office 365 | Rspamd standalone Docker | |
Need a Docker-based external spam filter | ||
Already running SpamAssassin, not migrating yet | — | |
Need MTA-agnostic SMTP proxy | — | |
Need antivirus alongside spam filtering | ClamAV + SpamAssassin | |
Maximum performance filter engine | — | |
Legacy Amavis stack | Amavisd-new (for now) | Migrate to Rspamd |
FAQ
How does Rspamd compare to SpamAssassin on detection rate?
Rspamd has been benchmarked at around 13x faster than SpamAssassin and scores comparably or better on detection. The difference isn’t just speed — Rspamd’s neural network module and fuzzy hashing catch patterns that static SA rules miss. For new deployments Rspamd wins on every metric. For existing SA setups with years of tuned custom rulesets, the detection accuracy gap narrows, but Rspamd still has the edge.
Should I run Rspamd AND SpamAssassin at the same time?
Generally no. Rspamd includes a SpamAssassin-compatible rules plugin that runs SA rules natively, so you get SA’s ruleset without running a separate SA daemon. Running both full processes adds overhead without meaningfully improving detection. On control panels like DirectAdmin that manage both, SA settings are often forwarded automatically to Rspamd anyway — check your panel’s docs before assuming they’re running independently.
What spam score threshold should trigger rejection vs just tagging?
Rspamd defaults: tag (add spam header) at 6, reject at 15. Most admins start at these defaults and tighten after Bayesian training matures. Setting rejection too low early on causes false positive hard bounces — worse than delivering spam. A common safe approach: tag at 5, soft-reject at 8, hard-reject at 15 for the first month, then lower the hard-reject to 12 once Bayes data is solid.
How do I reduce false positives when I first set up a spam filter?
Start with a high rejection threshold (15+) and watch your logs before tightening it. Whitelist known bulk senders — newsletters, CRMs, monitoring tools — immediately. Most importantly, feed ham aggressively into Bayesian training. In mailcow and Mailu, moving messages out of the Junk folder automatically teaches Rspamd they’re ham via imapsieve hooks. The filter improves dramatically in the first 2-4 weeks of active training.
How do I train Rspamd to learn spam and ham?
Three paths: (1) Folder-based auto-training — mailcow and Mailu automatically train Rspamd when users move messages in/out of their Junk folder via Sieve and imapsieve. (2) CLI training with rspamc learn_spam < spam.eml and rspamc learn_ham < ham.eml on raw email files. (3) Enable autolearn in Rspamd’s Bayes module, which trains automatically on messages that score very high or very low. All Bayes data lives in Redis — make sure your Redis volume is persistent or training resets on container restart.
What are DNSBLs and which ones are worth enabling?
DNS Block Lists are real-time blacklists of known spam IP addresses and sending domains queried for every incoming message. Rspamd queries multiple DNSBLs by default. Spamhaus ZEN (covers SBL, XBL, PBL) and Spamhaus DBL are the most reliable starting points with low false positive rates. Avoid overly aggressive lists like UCEProtect Level 3, which has a reputation for collateral blocking. Rspamd’s default DNSBL configuration is well-balanced — don’t disable it unless you know exactly why.
How much RAM do I need to run mailcow or Mailu?
mailcow recommends a minimum of 4 GB RAM, with 8 GB comfortable for production — ClamAV alone uses 500 MB to 1 GB. Mailu is lighter and runs reasonably on 2 GB for small deployments. docker-mailserver is the most RAM-efficient option. ClamAV is the biggest memory consumer across all stacks — disabling it frees the most RAM if AV scanning isn’t a priority for your setup.
Can these tools work with cPanel, Plesk, or DirectAdmin?
SpamAssassin integrates natively with all three — cPanel has built-in SA management, DirectAdmin exposes per-user SA settings, Plesk has SA support. Rspamd integration varies: DirectAdmin can map SA settings to Rspamd when it’s installed, Plesk has a Rspamd extension, cPanel/WHM doesn’t officially support Rspamd yet. Proxmox Mail Gateway sidesteps all of this entirely — point your cPanel or Plesk server’s MX at PMG and the control panel never needs to know about it.
How do I whitelist a sender that keeps getting flagged as spam?
In Rspamd, add the sender’s domain to /etc/rspamd/local.d/whitelist_sender_domain.map or use the web UI’s whitelist section directly at port 11334. In SpamAssassin, add whitelist_from or whitelist_from_rcvd entries to local.cf. In mailcow, use the Spam Filter section in the admin UI to add entries globally or per-mailbox. Always whitelist by DKIM-verified domain rather than IP address when possible — IP-based whitelisting is fragile and can create gaps over time.
Does self-hosted spam filtering work as well as commercial solutions?
For most setups, yes. Rspamd with proper Bayes training and active DNSBLs catches the vast majority of spam at rates comparable to commercial services. Where commercial solutions like SpamTitan win is shared intelligence — millions of customers feeding the same threat model gives an edge on zero-day campaigns. Self-hosted wins on privacy, cost, and customisation. For a small business or personal server, a well-tuned self-hosted setup is genuinely competitive with paid options.
What is fuzzy hashing in Rspamd?
Fuzzy hashing creates a fingerprint of a message’s structure and content that’s robust to minor variations — spam campaigns typically reuse the same template with small word or link changes to evade exact-match filters. Rspamd’s fuzzy storage module builds a local database of these fingerprints from messages you mark as spam, plus pulls from shared Rspamd fuzzy servers. When a new message arrives with a similar fingerprint, it scores higher even if the specific words have changed.
How do I check if my spam filter is actually working?
Open the Rspamd web UI at port 11334 and check the Statistics page — look for score distributions showing caught spam, ham, and scores in between. Review mail logs for lines showing reject or add header actions from Rspamd. Test it by sending a message containing the GTUBE string (a standard spam test pattern) — Rspamd should reject it with a high score. If you see zero activity, verify your MTA’s milter configuration is actually pointing at Rspamd and that the milter port is reachable from your mail server.
