Install SpamAssassin with Postfix & Dovecot

Q: What port does SpamAssassin use with Postfix?

SpamAssassin uses port 783 by default when running in milter mode. Ensure this port is open and listening.

Q: Can SpamAssassin run with Dovecot only?

No — SpamAssassin works with the MTA (Postfix) to scan incoming mail. Dovecot handles delivery after the scan.

Q: How does SpamAssassin differ from DKIM and DMARC?

SpamAssassin filters spam based on content and sender reputation. DKIM verifies message authenticity. DMARC enforces email policy across SPF and DKIM.

Q: Is SpamAssassin effective against modern phishing?

Yes — when combined with real-time networks like Razor, it detects phishing content, malicious URLs, and suspicious sender behavior.

Q: Do I need to update SpamAssassin regularly?

Yes — update its rules and plugins regularly to defend against new spam techniques and evolving threats.

Q: Can I use SpamAssassin with other mail servers?

Yes — SpamAssassin supports milter integration with Sendmail, Exim, and other MTAs beyond Postfix.

Q: What is a milter in SpamAssassin?

A milter is a Mail Filtering Service that integrates with Postfix to scan messages in real time before delivery.

Q: How do I stop SpamAssassin from marking legitimate mail as spam?

Train the system with `sa-learn --ham` on clean emails, adjust spam thresholds, and use Sieve to bypass filtering for trusted senders.

Q: Is SpamAssassin safe to run on a public server?

Yes — when configured properly with firewalls and minimal services exposed, it’s a safe, open-source tool for self-hosted email.

Q: Can I run SpamAssassin without a milter?

Yes — but it’s less efficient. Without a milter, filtering must occur post-delivery, reducing speed and usability.

Why You Need SpamAssassin on Your Self-Hosted Email Server

You spent hours setting up Postfix and Dovecot. Your server is secure, your domain is verified, and you’re finally running your own email. Then you log in and see 127 spam messages in the inbox—some with fake invoices, others pretending to be from your bank.

Even the most well-configured mail server is exposed to spam without a content-aware filter. That’s where SpamAssassin comes in: a mature, open-source email filter that analyzes headers, content, and sender reputation to stop junk before it reaches your inbox.

This guide shows you how to install SpamAssassin with Postfix and Dovecot—step by step, with no black-box cloud services. You’ll gain full control over spam rules, avoid third-party data sharing, and keep your server private and resilient.

Key takeaways

SpamAssassin runs locally, so your email data never leaves your server.
It reduces spam by scoring messages based on content, headers, and sender reputation—no cloud dependency.
Integrating it with Postfix and Dovecot allows full control over filtering, without outsourcing email security.

Prerequisites: What You Need Before Installing SpamAssassin

You need a working Postfix mail server with SMTP delivery, Dovecot running IMAP/POP3 and user authentication, access to a Linux server (Ubuntu, Debian, or CentOS) via SSH, and root or sudo access to install packages and configure services. Let’s make sure you’ve got those base layers solid before adding SpamAssassin.

Core Mail System Setup

Ensure Postfix is installed and configured to send and receive mail via SMTP. Test with telnet localhost 25 or ss -tulnp | grep 25 to confirm the service is active.
Dovecot must be running with IMAP and/or POP3 enabled, and properly authenticated against local users or LDAP. Use systemctl is-active dovecot to validate status.
Verify both services are reachable from outside networks—this helps avoid configuration blind spots later. Consider using MXToolbox to check your server’s SPF and MX records.

Server and Access Requirements

Use a clean Ubuntu 22.04, Debian 11/12, or CentOS 8/Stream server with a static IP and fully qualified domain name (FQDN). Avoid shared hosting—SpamAssassin needs direct control.
Access via SSH with a non-root user that has sudo privileges. Avoid using root for daily tasks; it’s a security best practice.
Ensure your firewall allows SMTP (port 25), IMAP (port 143), and POP3 (port 110) traffic. Use ufw status or firewall-cmd --list-all to check rule sets.

Once all this is in place, you’re ready to install SpamAssassin. While you're setting up, consider how you’ll manage mail across multiple domains or team inboxes—our self-hosted option lets you run a full email suite with built-in spam filtering, encryption, and granular controls.

SpamAssassin is only as effective as your mail server’s foundation. No point adding filters if Postfix isn’t delivering reliably or Dovecot isn’t authenticating users.

With the core stack in place, you’ll avoid common pitfalls like false positives or email delivery failures down the line. The next step? Let’s install SpamAssassin and hook it into Postfix’s filtering chain.

How to Install SpamAssassin with Postfix and Dovecot: The Core Setup

You can install SpamAssassin with Postfix and Dovecot by first installing the necessary packages, enabling the SpamAssassin daemon, configuring Postfix to use it via the milter interface, and setting up Dovecot to deliver spam messages to the right folders using Sieve filters. This setup blocks spam effectively while keeping your mail system secure and customizable. Let’s walk through it step by step.

Install and Enable SpamAssassin

Install SpamAssassin and its dependencies using your package manager: sudo apt install spamassassin spamc on Debian/Ubuntu, or equivalent on other distributions.
Enable the SpamAssassin daemon by editing /etc/default/spamassassin and setting ENABLED=1. This ensures SpamAssassin runs continuously to filter incoming messages.
Start and enable the service with sudo systemctl enable --now spamassassin. This makes it available for Postfix to connect via the milter system.

Integrate SpamAssassin with Postfix and Dovecot

Configure Postfix to use SpamAssassin by editing /etc/postfix/master.cf. Add a new milter entry:spamd unix - - n - 5 smtpd
-o content_filter=spamassassin
-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_required=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,rejectThis tells Postfix to pass incoming mail through SpamAssassin during delivery.
Ensure SpamAssassin is accessible via the milter interface by confirming the socket path (usually /var/spool/postfix/spamassassin) is correctly mapped in Postfix.
Now configure Dovecot to handle spam delivery using Sieve filters. Create a sieve script in user mailboxes, such as ~/.dovecot.sieve, with a rule like:if header :contains "X-Spam-Flag" "YES" {
fileinto "Spam";
}This automatically moves flagged mail to a Spam folder.
Compile and apply the Sieve filter using doveadm sieve compile to make it active. Now spam is delivered where users expect it.

For an alternative to manual setup, consider a secure, integrated environment like Unifiedesk, which includes built-in spam filtering and privacy controls. It supports custom domains and secure encryption—no need to configure milters or Sieve scripts by hand. Explore how it handles mail, calendar, and Drive securely: self-hosted or with your domain.

Spam filtering is as much about configuration as it is about tools. A well-tuned milter and Sieve setup keeps your inbox clean without false positives.

The Sieve standard ensures your filtering logic works across email clients. Use it to build predictable, reliable rules. And remember: always test with real mail to avoid blocking legitimate messages.

Configuring the SpamAssassin Milter for Postfix

You enable SpamAssassin’s milter interface by editing its config to allow milter mode, then configure Postfix to use it via smtpd_milters in main.cf. This lets SpamAssassin inspect incoming mail in real time, tagging spam before delivery. You’ll run the milter on port 783 with proper permissions, then reload Postfix without a full restart. For a self-hosted setup where you control all layers, this gives you granular spam control, especially useful when you’re managing your own domain’s email security.

Enable the Milter Interface in SpamAssassin

Open /etc/spamassassin/spamassassin.conf (or your system’s equivalent) and ensure use_bayes 1 is set to enable learning.
Add or uncomment the line use_razor2 1 and use_pyzor 1 if you want to use distributed spam signals. These are community-driven, real-time detection methods used across the email security ecosystem.
Set milter_protocol 2 to enable the milter interface, which communicates with Postfix using the MILTER protocol standard defined in RFC 2554.

Configure Postfix to Use the SpamAssassin Milter

Ensure the SpamAssassin milter daemon is running and listening on port 783 by checking sudo systemctl status spamass-milter and setting SPAMASSASSIN_MILTER_OPTS="-p 783 -u spamd" in /etc/default/spamass-milter.
In /etc/postfix/main.cf, add the following lines:
- smtpd_milters = inet:127.0.0.1:783 — applies to incoming mail only.
- non_smtpd_milters = inet:127.0.0.1:783 — applies to non-SMTP sources like local delivery or fetchmail.
Set the milter timeout to avoid delays: milter_timeout = 30s in main.cf.
Reload Postfix with sudo systemctl reload postfix — this applies changes without dropping existing connections.

SpamAssassin now runs as a background service, and Postfix forwards each incoming message through it. You’ll see spam scores in headers, and spam messages can be marked or rejected based on your spamassassin.conf rules. This is the same level of control you get when using a platform like Unifiedesk, where spam protection is built-in and managed under a single, secure, self-hosted stack — including features like AI-assisted spam detection, encrypted storage, and full ownership of your data via our on-premise deployment.

SpamAssassin Postfix Integration: Verifying the milter Connection

You’ve got SpamAssassin running and Postfix configured to talk to it via the milter interface—now verify it’s actually working. Use ss -tulnp | grep 783 to confirm the milter port is active. Next, send a test message flagged as spam and check the headers in Postfix logs for X-Spam-Status: Yes. If the score is applied, SpamAssassin is integrated and filtering as expected. This is how you know it’s not just running—it’s doing its job.

Check the milter is listening

Run ss -tulnp | grep 783 to verify SpamAssassin’s milter is bound to port 783.
If no output appears, restart the milter service or check your spamd config in /etc/mail/spamassassin/spamd.conf for the correct localhost:783 or IP binding.
Ensure spamd is running: systemctl status spamassassin or service spamassassin status.

Test and validate the flow

Use a known spam sample from a test environment—such as those available from Spamhaus ZEN—or send an email with a subject line known to trigger spam filters (e.g., "Viagra", "Free money").
After delivery, check the full headers of the received email. Look for X-Spam-Status: Yes, X-Spam-Score, and X-Spam-Report fields—these confirm SpamAssassin processed it.
Confirm Postfix logs at /var/log/mail.log include lines like spamd[...]: message: ... score=5.2 or filtered via milter.
If the headers are missing, check the milter socket path and ensure smtpd_milters and non_smtpd_milters in /etc/postfix/main.cf list inet:127.0.0.1:783 correctly.

When the score appears and the headers are injected, SpamAssassin is not just running—it’s active. This is the foundation of a clean inbox. For teams needing stronger spam and content hygiene without relying on centralized providers, self-hosted tools like SpamAssassin are a proven, trusted layer. If you’re building your own secure workspace with full control—and want to include AI-assisted threat detection and encrypted storage—you’ve already got the basics covered. Deploy Unifiedesk to manage email, drive, docs, calendar, and AI in one place, with encryption at rest, end-to-end in the cloud, and full control over your data.

SpamAssassin vs DKIM/DMARC: What Each Protects and Why You Need Both

You need both SpamAssassin and DKIM/DMARC because they defend different layers of your email security: SpamAssassin filters spam based on content and sender behavior, while DKIM and DMARC prevent spoofing by verifying sender authenticity and enforcing domain policies. Together, they reduce spam, block impersonation, and minimize false positives—especially important when running your own mail server. Think of SpamAssassin as the gatekeeper checking the guest’s story, and DKIM/DMARC as the ID check verifying they’re who they claim to be.

SpamAssassin: Filtering the Noise

SpamAssassin inspects the actual content of incoming mail—looking at words, formatting, headers, and known spam patterns. It scores each message, and if the score passes a threshold, it’s tagged or quarantined. It’s especially good at catching deceptive phishing attempts or bulk spam that hides in plain sight. You’re not just stopping spam; you’re reducing noise so you can focus on what matters.

For example, if an email claims your account is “about to be suspended” and uses excessive capitalization, SpamAssassin’s heuristics will flag it. It doesn’t care about your domain—just the message’s behavior. It’s like a security guard patrolling the hall with a checklist of red flags.

DKIM & DMARC: Protecting Your Identity

DKIM adds a digital signature to outbound mail. When you send an email, your server signs it with a private key tied to your domain. The recipient’s server checks the signature using your public key published in DNS. This proves the message wasn’t altered in transit and actually came from your domain.

DMARC builds on SPF and DKIM by telling receiving servers what to do if a message fails authentication. You define policies—like “quarantine” or “reject”—and DMARC enables enforcement. This stops scammers from sending emails that pretend to be from your company.

Without DKIM and DMARC, even if SpamAssassin blocks spam, attackers can still spoof your domain. With them, you protect your domain reputation. According to the Anti-Phishing Working Group (APWG), over 80% of phishing emails involve domain spoofing—making DKIM and DMARC essential.

And here’s the key takeaway: SpamAssassin reduces spam volume. DKIM and DMARC stop attackers from impersonating you. Together, they create a layered, resilient defense. You’re not just reacting—you’re stopping malicious attempts before they reach your inbox, whether it’s a scam, a spoof, or a mass campaign. For teams or organizations running their own email infrastructure, this is foundational.

If you're setting up a secure, self-hosted email system, tools like SpamAssassin, Postfix, and Dovecot are the foundation. Unifiedesk offers a managed, self-hostable alternative with built-in spam filtering, DKIM/DMARC enforcement, and end-to-end encryption—all without the complexity of manual configuration. Try Unifiedesk for self-hosted email and workspace security.

Enabling Real-Time Spam Filtering: Using Razor, DCC, and Pyzor

You can boost SpamAssassin’s spam detection by integrating real-time intelligence networks—Razor, DCC, and Pyzor. These tools share spam signatures across a global network, helping catch new spam faster than static rules alone. They’re optional but highly effective when added to your existing setup.

Set Up the Real-Time Spam Intelligence Feeds

Install the required tools: apt-get install razor, apt-get install dcc, and apt-get install pyzor. These packages provide access to live spam signature databases.
Initialize Razor with razor-admin -create -home ~/.razor and run razor-admin -register -home ~/.razor to join the network. This registers your server and enables reputation-based filtering.
Set up DCC by running dccproc -i to start the DCC daemon and enable it in /etc/default/dcc. DCC hashes message content to detect spam patterns across millions of servers.
Initialize Pyzor with pyzor -h to see help, then run pyzor discover to find peers and pyzor register to join the network. It shares checksums of spam content for instant cross-server detection.

Integrate Feeds into SpamAssassin

Once these services are running, enable them in SpamAssassin’s configuration.

Ensure the bayes_store_module is set to Dworm or SQL in /etc/spamassassin/local.cf for accurate learning. A robust learning database is key to real-time accuracy.
Add these lines to /etc/spamassassin/local.cf to enable real-time checks:
- use_bayes 1
- use_pyzor 1
- use_razor2 1
- use_dcc 1
Restart SpamAssassin: systemctl restart spamassassin. This loads the new configuration and reinitializes connections to remote networks.
Test the setup with a known spam message using spamassassin -t < test-spam.eml. Check output for high scores from Razor, DCC, or Pyzor. Real-time feeds should appear in the report.

These services work best when combined with local Bayesian learning and SPF/DKIM checks. According to RFC 3834, distributed spam detection improves overall accuracy. They’re not foolproof—but they reduce false negatives by catching spam before it spreads.

Want an email suite that handles spam, encryption, and compliance out of the box? Self-hosted Unifiedesk includes email, calendar, Drive, meet, and AI—built with privacy by design and ready to integrate tools like SpamAssassin.

SpamAssassin Postfix: Securing Your Configurations with User-Side Filters

You can automatically move SpamAssassin-tagged messages to the Junk folder using Dovecot’s Sieve filtering, set per-user spam thresholds (so users control their own sensitivity), add visible spam headers with add_header from SpamAssassin: Yes, and let users define custom rules without touching server config—all through user-side tools that stay private and flexible.

Use Sieve Filters to Automate Spam Handling

With Dovecot’s Sieve support enabled, you can create user-specific filtering rules that act on messages tagged by SpamAssassin. This means each user gets their own spam management logic—no one-size-fits-all compromise. You’ll use the meta directive in Sieve to detect the SpamAssassin header added during filtering, then route high-scoring messages to the Junk folder automatically.

For example, your Sieve script can check for a header like SpamAssassin: Yes and move the email accordingly. This keeps spam handling out of the main mail flow while preserving user autonomy. It's a lightweight, scalable way to apply policies without overloading the server.

Let Users Tune Their Own Spam Thresholds

SpamAssassin assigns scores to messages, but you don’t have to enforce a single threshold for everyone. By enabling per-user customization via Sieve, each user can decide what score triggers a spam tag. The spam meta tag from SpamAssassin is readable in Sieve, so users can adjust their rules without touching the server.

For instance, a user might want messages with a score over 5 to be moved to Junk, while another prefers 7. This flexibility reduces false positives and ensures everyone controls their inbox hygiene. It also aligns with modern email security best practices: user autonomy paired with system-level enforcement.

When setting up your server, ensure SpamAssassin adds the add_header from SpamAssassin: Yes directive in the local.cf file. This makes the tag visible in headers and usable by filters. As noted in RFC 5322, visible spam indicators help users assess message legitimacy and improve trust in automated filtering.

With all this in place, users can define custom rules—like blocking senders with certain patterns or quarantining emails from known phishing domains—without needing root access or changing server configs. It’s email security that scales with ownership.

If you're managing email on your own domain and want built-in spam filtering, encryption, and user control—without relying on third-party services—Unifiedesk’s self-hosted suite gives you full control over Mail, Calendar, Drive, Docs, and AI, with end-to-end encryption, per-account keys, and native Sieve support for custom filtering, all while keeping your data sovereign.

Common Issues and Fixes When Installing SpamAssassin

SpamAssassin often fails silently due to misconfigurations or permission issues. You’ll fix most problems by verifying AppArmor/SELinux isn’t blocking it, checking Postfix’s milter config in master.cf, confirming spamd runs and listens on port 783, and ensuring proper ownership of /var/spool/spamassassin. Let’s walk through the real culprits you’re likely to hit.

SpamAssassin Won’t Start

Check if AppArmor (Ubuntu) or SELinux (RHEL/CentOS) is blocking the spamd process. Run sudo dmesg | grep -i denied to see denials, then adjust policies with aa-complain or setsebool as needed.
Ensure the spamd service is enabled and running: sudo systemctl status spamassassin. If it’s not, start it with sudo systemctl enable --now spamassassin.
Check logs at /var/log/mail.log or /var/log/syslog for startup errors — often a missing config file or permission failure.

Postfix Milter Connection Problems

Verify your Postfix master.cf uses --milter not just milter in the milter definition. The correct line should be: smtp inet n - y - - smtpd -o milter_protocol=2 -o milter_mail_command=spamc -o milter_daemon_timeout=30.
Incorrect use of milter without --milter can cause Postfix to ignore the milter entirely.
After fixing master.cf, reload Postfix: sudo postfix reload. Use postfix check to validate syntax before reloading.

Messages Not Tagged or Marked

Confirm spamd is active and listening on port 783: run sudo netstat -tulnp | grep 783 or ss -tulnp | grep 783. If not, restart spamd.
Ensure Postfix’s spamc is configured to connect to localhost:783. You can test with echo "Subject: Test spam" | spamc -u [email protected].
The spamd process must be running per user or as a system-wide service — check systemctl status spamassassin and ps aux | grep spamd.

Permission Denied Errors

If logs show “Permission denied” when accessing /var/spool/spamassassin, fix ownership: sudo chown -R spamd:spamd /var/spool/spamassassin.
Ensure the directory has correct permissions: sudo chmod 750 /var/spool/spamassassin.
Check that the spamd user can write to the directory — this is often the root cause when new users get denied.

Security isn’t optional — it’s baked into how you configure each layer. A single misowned directory can expose your mail system to abuse.

If you’re managing email at scale, consider a unified solution like self-hosted Unifiedesk, which handles milters, spam filtering, and encryption without the complexity of DIY setups. All data stays under your control, with end-to-end encryption and real-time threat detection.

Automating Updates and Monitoring Your SpamAssassin Deployment

You can keep SpamAssassin effective and your system secure by automating updates, monitoring spam scores over time, training SpamAssassin with user feedback, and reloading the milter after config changes. This reduces manual work and strengthens spam filtering over time using real user input. Let’s walk through the essentials.

Run regular system updates: On Debian or Ubuntu, use sudo apt update && sudo apt upgrade weekly. This keeps SpamAssassin and its dependencies current with security patches and rule improvements. Automate it with a cron job using crontab -e and add 0 2 * * 1 apt update && apt upgrade -y to run every Monday at 2 AM.
Monitor spam scores with logwatch: Install logwatch with sudo apt install logwatch. Configure daily reports by editing /etc/logwatch/conf/logwatch.conf and set MailTo = [email protected]. Logwatch pulls from /var/log/mail.log, showing spam score trends and false positive alerts.
Train SpamAssassin with user feedback: If a user marks a message as spam or not spam, use sa-learn --spam or --ham in their mailbox context. For example: sa-learn --spam --mbox /home/user/Maildir/.Spam/cur. Run this periodically via cron to refine the model. Note: This is the only way spam filters improve with time.
Reload the milter after config changes: After modifying /etc/spamassassin/local.cf or similar, reload SpamAssassin’s milter without restarting the service: systemctl reload spamassassin. This preserves active connections and applies new rules immediately. For Postfix-specific reloads, also run systemctl reload postfix to ensure rules are reapplied.

Log Monitoring and Alerting

SpamAssassin logs to /var/log/mail.log with entries like spamassassin: NO ACTION: spam score. You can parse these manually or use tools like journalctl or RFC 5226 for log format consistency checks. For real-time visibility, consider lightweight log analysis tools like Logwatch or custom scripts.

Leverage Your Infrastructure

If you’re managing mail at scale, consider integrating SpamAssassin into a broader security workflow. Self-hosting offers full control—exactly what Unifiedesk enables with self-hosted deployments. You can customize every layer, including spam filtering. For teams needing built-in tools without complex setup, Unifiedesk offers managed mail, calendar, and Drive with end-to-end encryption and no data mining. See how it simplifies secure email: private email.

Why Unifiedesk Users Don’t Need to Install SpamAssassin — Built-In Protection

With Unifiedesk, spam filtering is built into the platform from day one. Inbound mail is checked against SPF, DKIM, and DMARC records, and content-based spam rules automatically block malicious messages before they reach your inbox.

Outbound messages are DKIM-signed to preserve sender reputation, and your mail stack includes layered defenses without any manual configuration. You don’t need to install or maintain SpamAssassin—your system is secure by design.

For those who self-host, the open-source Unifiedesk engine supports custom filtering rules and monitoring, giving you full control without the complexity of managing tools like SpamAssassin manually.

Ready to put this into practice? Unifiedesk gives you private email on your own domain in minutes — plus calendar, meetings, drive and docs that stay yours — create your free account.

Frequently asked questions

What port does SpamAssassin use with Postfix?