AI-generated phishing campaigns, snowshoe spam, and compromised accounts blasting garbage have made 2026 a genuinely rough time for inboxes — and every production mail environment needs a solid filtering layer to survive it. In 2026, the best open source options all run in Docker.
This guide covers every major open source anti-spam solution with a Docker image: standalone filter engines you can slot in front of any existing MTA, and complete self-hosted mail stacks that bundle SMTP, filtering, and webmail in a single Compose file. Whether you’re hardening an existing Postfix setup or spinning up a full mail server from scratch, there’s a Docker solution here for you.
Quick answer: Rspamd is the standalone filter engine of choice in 2026; mailcow, Mailu, and docker-mailserver lead the full self-hosted stacks.
Two Types of Docker Anti-Spam Deployment
Quick Answer: Docker anti-spam solutions split into two categories: standalone filter engines (Rspamd, SpamAssassin) you wire into an existing MTA, and full mail stacks (mailcow, Mailu, docker-mailserver) that include SMTP, IMAP, spam filtering, and more in one compose file.
Before diving into individual tools, it’s worth understanding the two deployment models — because the right choice depends entirely on what you’re trying to do.
Model A — Standalone filter engine. You already have a mail server (Postfix, Exim, or even a relay in front of Exchange) and you want to bolt a spam filter onto it. Run Rspamd or SpamAssassin in Docker, expose the milter or spamd port, point your MTA at it. Your existing mail infrastructure stays in place; you’re just adding a filtering layer.
Model B — Full self-hosted mail stack. You want everything in one Docker Compose file: SMTP, IMAP, spam filtering, antivirus, webmail, admin UI. You’re replacing or building a complete mail server. mailcow, Mailu, and docker-mailserver all do this, each with different trade-offs on complexity vs features.
Here’s how every Docker-capable solution in this guide maps to those models:
Solution | Docker Image | Deployment Model | External MTA Support |
|---|---|---|---|
Official (rspamd/rspamd) | Standalone filter engine | Yes — milter to any MTA | |
Community image | Standalone filter engine | Yes — spamc/spamd TCP | |
Community image | Gateway scanner (needs MTA) | Partial | |
Community image | Content filter (Postfix glue) | Partial | |
Native Docker Compose | Full mail stack | No — internal only | |
Native Docker Compose | Full mail stack | No — internal only | |
Native Docker Compose | Full mail stack | No — internal only |
Keep that table in mind as we go through each solution. The “External MTA Support” column is what separates the standalone engines from the full stacks.
1. Rspamd — The Modern Standalone Filter Engine
Quick Answer: Rspamd is the fastest, most capable open source spam filter in 2026 — C-based, Docker-native, supports milter protocol for integration with any external MTA.
- External Use: Yes — bind the proxy worker to a public port and any milter-compatible MTA can connect remotely
- Docker: Official image (rspamd/rspamd on Docker Hub)
- Best For: Anyone building a modern spam filtering stack, self-hosted or external
- Links: Website | Docs | Docker Hub
What’s Good: Written in C, so it’s genuinely fast — not “fast for a spam filter” fast, but actually fast. Multi-layered detection covers all the bases: Bayesian filtering, DNSBL/URIBL checks, fuzzy hashing, a neural network module, SPF/DKIM/DMARC validation, and greylisting. Built-in web UI ships on port 11334 with no extra config. DKIM signing is baked right in. Redis integration handles statistics and Bayesian data persistence. Works as a milter for Postfix/Sendmail or as an HTTP API for custom integrations. The official Docker image is actively maintained. Rspamd is currently at version 3.14.3-1 (as of the mailcow March 2026 release), with active development continuing.
What’s Not So Good: Configuration is not trivial for first-timers — there’s a real learning curve navigating the config files in /etc/rspamd/local.d/. It’s a pure filter engine, no MTA included, so you need to wire it up yourself. To use it externally you need to expose the milter port and configure proper access controls, which trips people up the first time.
Here’s a solid Docker Compose stack for standalone Rspamd with Redis and ClamAV — this is the setup you’d use for an external filtering gateway:
|
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 26 27 28 29 30 31 32 33 34 35 36 |
services: rspamd: image: rspamd/rspamd:latest container_name: rspamd ports: - "11334:11334" # Web UI - "11332:11332" # Milter protocol - "11333:11333" # Normal scanning volumes: - ./rspamd/conf:/etc/rspamd/local.d - rspamd_data:/var/lib/rspamd depends_on: - redis - clamav restart: unless-stopped redis: image: redis:7-alpine container_name: rspamd-redis volumes: - redis_data:/data restart: unless-stopped clamav: image: clamav/clamav:stable container_name: rspamd-clamav volumes: - clamav_data:/var/lib/clamav restart: unless-stopped volumes: rspamd_data: redis_data: clamav_data: |
Once that’s running, connecting your Postfix instance to the Rspamd milter looks like this:
|
1 2 3 4 5 6 7 |
# Connect Postfix to remote Rspamd milter smtpd_milters = inet:RSPAMD_HOST:11332 non_smtpd_milters = inet:RSPAMD_HOST:11332 milter_protocol = 6 milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen} |
To allow external MTAs to connect to your Rspamd instance, add this to your worker-proxy.inc config:
|
1 2 3 |
bind_socket = "*:11332"; |
That single line is what transforms Rspamd from a local filter into a remotely-accessible filtering service. Pair it with proper firewall rules to restrict which IPs can connect, and you’ve got yourself a legitimate external spam gateway.
2. Apache SpamAssassin — The Proven Veteran
Quick Answer: SpamAssassin v4.0.2 (2025) is battle-tested, widely integrated, and supports remote scanning via spamc/spamd TCP protocol — externally usable from any server.
- External Use: Yes — spamd listens on TCP port 783, any server with
spamcinstalled can submit mail for scanning remotely - Docker: Community images available (no official image)
- Best For: Legacy integrations, Amavis pipelines, organisations that have been running SA for years
- Links: Website | Docs | Docker Hub
What’s Good: Decades of rule development and community knowledge are baked into SpamAssassin — it’s been fighting spam since 2001 and it’s still actively maintained. Version 4.0.2, released August 2025, added Perl 5.42 compatibility and a new Redirector plugin. The detection stack covers Bayesian filtering, DNSBL checks, header analysis, and body rule matching. The ecosystem of third-party rulesets (SARE, KAM, and others) extends coverage significantly. And yes, it does remote scanning: spamc can point at a remote spamd server over TCP port 783 with the -d flag, and it supports SSL and gzip compression for long-distance scanning. It integrates with virtually every MTA and mail gateway ever built.
What’s Not So Good: Written in Perl, which means it’s significantly slower than Rspamd at scale. Memory-hungry when you start processing volume. Rule updates require manual configuration or scheduled sa-update jobs — they don’t just happen. No built-in web UI. If you’re starting fresh in 2026, Rspamd is the smarter performance choice, but SpamAssassin absolutely still works and has an enormous amount of institutional knowledge behind it.
Remote scanning with spamc — this is what makes SpamAssassin genuinely externally usable:
|
1 2 3 4 5 6 7 8 9 10 |
# Scan a message against a remote spamd server spamc -d spamd.example.com -p 783 < message.eml # With SSL for secure remote scanning spamc -d 192.168.1.50 -p 783 --ssl < message.eml # Pipe from a mail processing script cat message.eml | spamc -d spamd.example.com -p 783 |
Any server that can install spamc (the lightweight C client) can submit mail to a remote spamd instance for scanning. The mail server itself doesn’t need to know anything about SpamAssassin — the integration happens at the MTA filter level.
3. MailScanner — The Gateway Scanner
Quick Answer: MailScanner wraps SpamAssassin and ClamAV into a gateway scanning layer that can be placed in front of any Postfix or Exim server — external use is possible with proper setup.
- External Use: Partial — acts as a gateway scanner with Postfix/Exim, can be placed upstream but requires MTA co-location
- Docker: Community images available
- Best For: Organisations wanting a combined spam and antivirus gateway layer on a dedicated filtering server
- Links: Website | GitHub | Docker Hub
What’s Good: MailScanner combines SpamAssassin and ClamAV (and optionally other AV engines) into a single scanning layer sitting between two Postfix instances. The architecture is: incoming Postfix queue → MailScanner scans → outgoing Postfix queue → relay to destination. Supports multiple antivirus scanners simultaneously, which is handy for organisations with compliance requirements. Long track record in enterprise mail environments. Custom rulesets and whitelist/blacklist support.
What’s Not So Good: The architecture is more complex than Rspamd-based setups — you’re running two Postfix instances plus MailScanner as a bridge between them. Requires Postfix or Exim as the MTA wrapper, making it less truly MTA-agnostic than a standalone milter-based filter. Not “external-capable” in the pure sense — you need an MTA on the same host. Development pace is slower than Rspamd. Docker support is community-maintained, not official.
4. Amavisd-new — The Content Filter (Aging Gracefully)
Quick Answer: Amavisd connects Postfix to SpamAssassin and ClamAV via SMTP re-injection on port 10024 — functional but being phased out in favour of Rspamd by most active projects.
- External Use: Partial — any Postfix server can route mail through Amavis via SMTP (
content_filter = smtp:[amavis_host]:10024), but practically always co-located - Docker: Community images available (mlan/postfix-amavis)
- Best For: Legacy stacks already using Amavis that aren’t ready to migrate to Rspamd
- Links: Website | mlan/docker-postfix-amavis GitHub | Docker Hub
What’s Good: Mature, proven integration layer between Postfix and SpamAssassin/ClamAV. The SMTP re-injection approach is theoretically usable from any Postfix server by setting content_filter to point at a remote Amavis host. Wide deployment history and a huge amount of documentation out there for troubleshooting.
What’s Not So Good: The mlan/docker-postfix-amavis project has explicitly announced it’s no longer maintained, with development effort shifting to mlan/rspamd. Amavis itself is aging, and maintenance issues are starting to show. Rspamd does everything Amavis does plus much more, and does it faster. If you’re building new in 2026, skip Amavis entirely and go straight to Rspamd. If you’re already running Amavis and it’s working, no emergency — but start planning the migration.
5. mailcow: dockerized — Best Full Self-Hosted Stack
Quick Answer: mailcow bundles Postfix, Dovecot, Rspamd, ClamAV, SOGo, and a web admin UI into one Docker Compose stack — the most complete self-hosted mail solution available in 2026.
- External Use: No — the Rspamd instance is internal to the stack, not designed to filter external mail servers
- Docker: Yes — native Docker Compose, actively developed (2026-03 release ships Rspamd 3.14.3-1)
- Best For: Self-hosters who want a complete, production-grade mail server with everything included
- Links: Website | Docs | GitHub
What’s Good: Genuinely the most complete self-hosted mail stack you can spin up with a single docker compose up. The 2026-03 release (March 10, 2026) includes: Postfix for SMTP, Dovecot for IMAP/POP3, Rspamd 3.14.3-1 for spam filtering, ClamAV for antivirus, Olefy for Office document scanning, SOGo 5.12.5 (now built from source) for webmail plus calendar and contacts, and a polished web admin UI. Rspamd learns from user actions — moving mail to or from the Junk folder automatically trains the Bayesian filter. Fuzzy hash storage builds pattern-based learning over time. The March 2026 release added forced 2FA setup and password update enforcement, sponsored by Philipps-Universitat Marburg. Monthly release cadence, active community, solid documentation.
What’s Not So Good: It’s a lot of moving parts — this is not a minimalist deployment. The full stack needs at least 4 GB RAM to run comfortably. Upgrading requires care (the team always recommends a backup before updating). The Rspamd inside is not extractable for use with external servers — it’s wired into the mailcow network and configuration. But if self-hosted email is what you’re building, this is the gold standard.
|
1 2 3 4 5 6 7 8 |
# Deploy mailcow: dockerized git clone https://github.com/mailcow/mailcow-dockerized cd mailcow-dockerized ./generate_config.sh docker compose pull docker compose up -d |
6. Mailu — The Simpler Full Stack
Quick Answer: Mailu is a lighter Docker-native mail stack with Rspamd built in — less complex than mailcow, good for smaller deployments and single-domain setups.
- External Use: No — Rspamd runs internally within the Mailu stack
- Docker: Yes — native Docker Compose
- Best For: Smaller self-hosted setups, single-domain deployments, users who find mailcow overwhelming
- Links: Website | Docs | GitHub
What’s Good: Mailu hits a real sweet spot for people who want a fully functional self-hosted mail server without the complexity of mailcow. It covers the essentials — Postfix, Dovecot, Rspamd, ClamAV, webmail (Roundcube or Snappymail), and an admin UI — and it’s Docker-native from the ground up. The setup wizard generates your docker-compose.yml for you based on a web form, which makes initial deployment genuinely easy. Less RAM-hungry than mailcow, which matters for smaller VPS setups. Good documentation and a straightforward configuration model.
What’s Not So Good: Less feature-rich than mailcow — CalDAV/CardDAV availability depends on your configuration, and the admin UI is less powerful. The community is smaller than mailcow’s. And like mailcow, the Rspamd inside is internal to the stack — you can’t use it as an external filter. But if you don’t need the full mailcow feature set, Mailu is a genuinely good choice that’ll get you up and running faster.
7. docker-mailserver — The Minimalist Production Option
Quick Answer: docker-mailserver is a production-ready single-container mail server with Rspamd or SpamAssassin/Amavis — Kubernetes-supported, minimal footprint, no web UI.
- External Use: No — spam filtering is internal to the container
- Docker: Yes — native, single container design, Kubernetes supported
- Best For: Developers and sysadmins who want a production mail server without a web UI, infrastructure-as-code friendly
- Links: Website | GitHub | Docker Hub
What’s Good: Single container, full mail stack — surprisingly minimal resource usage for what it does. docker-mailserver is built for infrastructure-as-code: configuration is driven entirely by environment variables and config files, with no web UI in sight. That’s a feature, not a bug, for the sysadmin crowd. Kubernetes support is solid — there are guides for deploying on K8s with Rspamd using Redis for state storage. Supports both Rspamd (the recommended modern option) and the legacy SpamAssassin/Amavis stack. Sieve filtering routes spam to the Junk folder automatically. Active GitHub community with frequent contributions.
What’s Not So Good: No web UI — management is entirely via CLI and config files. Not for users who want point-and-click administration. You’re also limited to filtering your own stack’s traffic — there’s no external filtering capability here. But for developers running their own mail infrastructure in a scripted, reproducible way, this is an excellent choice.
Building an External Spam Gateway with Docker
Let’s get practical. You’ve got an existing Postfix server, or a relay in front of Exchange, or Office 365 with custom MX routing, and you want to add a self-hosted Docker spam gateway upstream of it. Here’s the complete stack using Rspamd — this is what you’d run on a VPS or dedicated server upstream of your actual mail server:
|
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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
version: '3.8' services: rspamd: image: rspamd/rspamd:latest container_name: spam-gateway-rspamd ports: - "11334:11334" # Web UI - "11332:11332" # Milter (for external MTAs) - "11333:11333" # HTTP scanning API volumes: - ./rspamd/local.d:/etc/rspamd/local.d - rspamd_data:/var/lib/rspamd depends_on: - redis - clamav restart: unless-stopped redis: image: redis:7-alpine container_name: spam-gateway-redis command: redis-server --save 60 1 --loglevel warning volumes: - redis_data:/data restart: unless-stopped clamav: image: clamav/clamav:stable container_name: spam-gateway-clamav volumes: - clamav_data:/var/lib/clamav restart: unless-stopped volumes: rspamd_data: redis_data: clamav_data: |
Next, configure Rspamd’s proxy worker to accept connections from external MTAs. Create or edit ./rspamd/local.d/worker-proxy.inc:
|
1 2 3 4 5 6 7 8 9 10 11 |
# /etc/rspamd/local.d/worker-proxy.inc # Allow external MTAs to connect to the milter port bind_socket = "*:11332"; # Restrict to your mail server IPs only (recommended) # upstream "local" { # default = yes; # self_scan = yes; # } |
Then, on your external Postfix server (which could be on the same gateway host acting as an SMTP relay, or a separate Postfix instance upstream of Exchange), add this to /etc/postfix/main.cf:
|
1 2 3 4 5 6 7 8 9 |
# On your external Postfix server: # /etc/postfix/main.cf smtpd_milters = inet:YOUR_GATEWAY_IP:11332 non_smtpd_milters = inet:YOUR_GATEWAY_IP:11332 milter_protocol = 6 milter_default_action = accept milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen} |
A note for Exchange and Office 365 setups: you can’t point Exchange directly at a milter. The typical approach is to run a Postfix relay on the same gateway server. Inbound mail flow looks like this: internet SMTP → Postfix relay (port 25) → Rspamd milter (port 11332) → Postfix relay delivers to Exchange/O365 via SMTP. For Office 365 specifically, you’d set up an inbound connector in Exchange Admin Center to accept mail from your gateway’s IP, then change your domain’s MX record to point at the gateway. Clean mail flows out via the connector. Spam gets rejected or quarantined before it ever touches your O365 tenant.
Which One Should You Use?
Here’s the bottom line decision guide. No fluff, just the right tool for your situation:
Your Setup | Best Choice |
|---|---|
Self-hosted mail — want the complete stack | |
Self-hosted — want something simpler than mailcow | |
Self-hosted — want scriptable, no web UI, Kubernetes-ready | |
Existing Postfix — want a standalone Docker spam filter | |
Exchange or relay — want an upstream Docker filtering layer | Rspamd gateway + Postfix relay |
Legacy stack already using SpamAssassin | |
Need spam + AV gateway layer with multiple AV engines | |
Maximum performance, modern stack |
FAQ
Can I use Rspamd to filter mail for Exchange or Office 365?
Yes, with some infrastructure work. You can’t point Exchange directly at Rspamd’s milter, but you can run a Postfix relay upstream that routes through Rspamd, then configure Exchange or Office 365’s inbound connector to receive mail from that relay. Change your domain’s MX record to point at the gateway, and clean mail flows out via the O365 connector — spam gets rejected before it ever touches your tenant.
How do I add spam filtering to an existing Postfix server using Docker?
Run Rspamd in Docker with the official rspamd/rspamd image, expose the milter port (11332), and add smtpd_milters = inet:RSPAMD_HOST:11332 to your Postfix main.cf. Pair it with a Redis container for Bayesian learning and an optional ClamAV container for antivirus. The full docker-compose.yml with all three services is a solid production starting point — see the setup section in this article.
How do I reduce false positives when I first set up Rspamd?
Start with a high rejection threshold (score 15+) and watch your logs before tightening it. Whitelist known bulk senders — newsletters, CRMs, monitoring tools — immediately. 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. Most setups see false positive rates drop significantly within the first 2-4 weeks of active training.
What is the milter protocol and why does it matter?
Milter (mail filter) is a protocol that lets external daemons hook into an MTA’s SMTP transaction before mail is fully accepted. Rspamd speaks milter, which means any Postfix or Sendmail server — including ones on a completely different host — can route mail through Rspamd for filtering over TCP. It’s more efficient than post-acceptance filtering because spam can be rejected before the full message body is even transferred.
How do I train Rspamd to learn spam and ham?
Three approaches: (1) Folder-based auto-training — mailcow and Mailu train Rspamd automatically when users move messages in/out of Junk via Sieve and imapsieve. (2) CLI training with rspamc learn_spam < spam.eml and rspamc learn_ham < ham.eml on raw email files. (3) Autolearn mode, which trains automatically on very high or very low scoring messages. All Bayes data is stored in Redis — make sure your Redis volume is persistent or training resets every time the container restarts.
What’s the difference between running Rspamd standalone vs inside mailcow?
Standalone Rspamd runs as its own Docker service (just Rspamd + Redis + ClamAV) and you wire it into any existing MTA via milter. mailcow runs Rspamd internally as part of a full mail stack — Postfix, Dovecot, ClamAV, SOGo all included. Use standalone if you already have a mail server and just want to add filtering. Use mailcow if you’re building a complete self-hosted mail environment from scratch.
What spam score threshold should I use for rejection?
Rspamd’s defaults are a solid starting point: tag at 6, reject at 15. Don’t lower the rejection threshold aggressively until your Bayesian filter has matured — early false positive rejections cause hard bounces, which are worse than delivering spam. A safe ramp-up: tag at 5, soft-reject at 8, hard-reject at 15 for the first month, then lower hard-reject to 12 once you have solid Bayes training data behind you.
What are DNSBLs and which ones should I enable?
DNS Block Lists are real-time blacklists of known spam IPs and domains queried for every incoming message. Rspamd includes a well-curated DNSBL configuration by default. Spamhaus ZEN (covering SBL, XBL, PBL) and Spamhaus DBL are the best starting points — high efficacy, low false positive rate. Avoid overly aggressive lists like UCEProtect Level 3. Don’t disable Rspamd’s default DNSBL module without a specific reason — it carries significant weight in scoring.
How much RAM does mailcow need to run properly?
Minimum 4 GB RAM for a single-user setup, 8 GB recommended for production. ClamAV is the main memory consumer at 500 MB to 1 GB on its own. Rspamd plus Redis add another 200-400 MB. If you’re RAM-constrained, Mailu runs on 2 GB for small setups and docker-mailserver is lighter still. Disabling ClamAV in mailcow frees the most RAM if antivirus scanning isn’t a priority.
How do I whitelist a legitimate sender that keeps getting caught?
In Rspamd, add the sender’s domain to /etc/rspamd/local.d/whitelist_sender_domain.map or use the Rspamd web UI whitelist section at port 11334. In mailcow, use the Spam Filter section in the admin UI for global or per-mailbox whitelist entries. In SpamAssassin, add whitelist_from or whitelist_from_rcvd rules to local.cf. Whitelist by DKIM-verified domain rather than IP address when possible — IP whitelisting breaks when the sender’s mail infrastructure changes.
Is SpamAssassin still worth using in 2026?
For existing deployments, yes — SpamAssassin 4.0.2 (August 2025) is actively maintained and still solid. For new deployments, Rspamd is the better choice: 13x faster, built-in web UI, neural network module, and DKIM signing included. The main reason to stay with SpamAssassin is ecosystem — if your control panel manages it natively and you have years of tuned custom rules, the migration cost is real. Otherwise, Rspamd is where the community has moved.
How do I check if Rspamd is actually catching spam?
Open the Rspamd web UI at port 11334 and check the Statistics page for score distributions and action counts. Review mail logs for reject and add header actions. Test immediately by sending a message containing the GTUBE string — Rspamd should reject it with a high score. If you see no filtering activity at all, verify your MTA milter configuration is pointing at Rspamd’s correct host and port, and that port 11332 is reachable from your mail server.
