# Spam filter for Plesk: MX-level filtering in front of your Plesk server URL: https://iblockspam.com/platforms/plesk Last updated: 2026-10-22 > Filter spam, phishing and malware before it reaches your Plesk mail server: keep the mail service on, change MX, trust the filter, then close port 25. Point your MX to iBlockSpam, keep Plesk's mail service on so the mailboxes still receive mail, stop Plesk's SMTP checks from judging the filter's IP address, and close the direct route around the filter. This page shows how to put iBlockSpam in front of a Plesk server so that internet mail is filtered before Plesk accepts it. The mailboxes stay on Plesk. For the full background on Plesk's own anti-spam tools and how to tune them, read our guide [Plesk email spam filter setup](https://iblockspam.com/blog/plesk-email-spam-filter-setup). Menu names below are from Plesk Obsidian's documentation at the time of writing (October 2026). Where Plesk for Linux and Plesk for Windows differ, the step says so. Placeholders used below: - ``: the MX hostnames for your domain. - ``: the IP ranges the filtering service delivers from. - ``: your Plesk server's mail hostname, for example `plesk1.example.net`. The iBlockSpam setup wizard shows your exact values, a before/after DNS comparison and the rollback steps. ## Prerequisites - Plesk administrator access for the server-wide steps, or a host who can apply them. A customer account can change its own DNS records and mailbox spam settings. - The server has a hostname with a valid TLS certificate and accepts mail on port 25. - You know where DNS for the domain is hosted. If Plesk hosts it, you edit MX in Plesk. If it's elsewhere, change MX there. - An outside test mailbox. ## Step by step 1. **Add your domain in iBlockSpam.** Set the delivery destination to `` on port 25. The wizard checks that it can connect. 2. **Lower the MX TTL** to 300 seconds at least one full old-TTL period before the cutover. Our guide to [DNS TTL and MX propagation](https://iblockspam.com/blog/dns-ttl-mx-change-propagation) explains the timing. 3. **Leave the mail service on.** Plesk's steps for external mail servers tell you to deactivate the mail service for the domain. That is for mailboxes hosted elsewhere. Here the mailboxes stay on Plesk, so Plesk must keep accepting the domain's mail. 4. **Stop SPF checks from rejecting filtered mail (Linux).** In **Tools & Settings » Mail Server Settings**, Plesk's SPF option offers modes from "Only create Received SPF-headers, never block" to "Reject mail if SPF does not resolve to 'pass'" ([Plesk docs: DKIM, SPF and DMARC protection](https://docs.plesk.com/en-US/obsidian/administrator-guide/mail/antispam-tools/domainkeys-protection.59433/)). Behind a filter, Plesk sees the filter's IP address as the sender, so choose **Only create Received SPF-headers, never block**. Plesk's documentation doesn't cover external filters; this is our advice. Plesk also enables a DMARC check on incoming mail; consider turning it off and letting the filter enforce authentication, because Plesk can't see the original sending server. 5. **Exempt the filter from DNSBL checks (Linux).** In **Tools & Settings » Mail Server Settings**, open the **White List** tab and add each range in ``. Plesk says whitelisted IPs are not rejected for DNSBL listings, but can still be rejected by SPF, DKIM or DMARC checks, delayed by greylisting or marked by SpamAssassin ([Plesk docs: Protecting against spam](https://docs.plesk.com/en-US/obsidian/administrator-guide/mail/antispam-tools/protecting-against-spam.80013/)). Keep the list to the filter's ranges only. 6. **Tell SpamAssassin the filter is trusted (Linux).** As root, add this line to `/etc/mail/spamassassin/local.cf`, listing the same ranges separated by spaces, then restart SpamAssassin: ``` trusted_networks ``` SpamAssassin then runs its network tests against the hop before the filter ([Apache SpamAssassin configuration](https://spamassassin.apache.org/full/4.0.x/doc/Mail_SpamAssassin_Conf.html)). Plesk names `local.cf` as the file for custom server-wide settings ([Plesk docs: Spam protection](https://docs.plesk.com/en-US/obsidian/advanced-administration-guide-linux/services-management/spam-protection.68764/)). Check that the line is still there after Plesk updates. 7. **Review mailbox spam settings.** On each mailbox's **Spam Filter** tab, prefer **Move spam to the Spam folder** (Plesk for Linux only) over **Delete all spam messages** during the first weeks ([Plesk docs: Protecting from spam](https://docs.plesk.com/en-US/obsidian/customer-guide/mail-settings/protecting-from-spam.65690/)). Spam caught by iBlockSpam goes to quarantine; anything SpamAssassin flags afterwards stays recoverable. 8. **Change MX.** If Plesk hosts your DNS, go to **Websites & Domains » DNS Settings** and click the MX record to edit it ([Plesk docs: Managing DNS records](https://docs.plesk.com/en-US/obsidian/quick-start-guide/plesk-functionality-explained/managing-dns-records.74404/)). Replace it with `` and the priorities shown in the wizard. Do not keep the Plesk server as a backup MX: senders may use any listed MX ([RFC 5321, section 5.1](https://www.rfc-editor.org/rfc/rfc5321#section-5.1)), and that gives spammers a direct path. 9. **Close the direct route.** Removing the server from MX does not stop spammers who connect to its IP address directly. Once the old TTL has expired: - **Server with only filtered domains:** in **Tools & Settings » Firewall** on Plesk for Linux, allow inbound TCP port 25 only from `` ([Plesk docs: The Plesk Firewall](https://docs.plesk.com/en-US/obsidian/administrator-guide/plesk-administration/plesk-for-linux-the-plesk-firewall.72046/)). On Plesk for Windows, Plesk's firewall rules are documented by port and protocol only, with no source-address field ([Plesk docs: The Plesk Firewall (Windows)](https://docs.plesk.com/en-US/obsidian/administrator-guide/plesk-administration/the-plesk-firewall-windows.64951/)), so set the source restriction in Windows Defender Firewall itself, whose inbound rules can be scoped to remote IP addresses. Keep ports 587 and 465 open for your users. - **Shared server with unfiltered domains:** skip the firewall step. Our [direct-to-server guide](https://iblockspam.com/blog/block-direct-to-tenant-bypass) explains the trade-offs. ## How to verify Send a test from an outside mailbox and view the full headers in webmail, or paste them into the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer), which runs in your browser. - **Received**: the hop before your server should be the filtering service. - **Received-SPF**: with the "never block" mode, Plesk adds the header but doesn't reject. A fail result against the filter's IP is expected and harmless. - **X-Spam-Status** (if SpamAssassin is on): network-based rules should reflect the original sender. A sudden rise in blocklist hits suggests `trusted_networks` is missing. Use the [MX Lookup](https://iblockspam.com/tools/mx-lookup) tool to confirm the public records. After step 9, a direct connection to port 25 from any other IP should fail. ## Rollback 1. Remove any port 25 firewall restriction first, so direct mail is accepted again. 2. Change MX back to the Plesk server, with a short TTL. 3. Keep the iBlockSpam domain active until the old TTL expires, so mail in flight through the filter is delivered. 4. Then remove the filter's ranges from the Mail Server Settings white list and `trusted_networks`, and set your SPF and DMARC checks back to the modes you used before. ## Common mistakes - **Deactivating the mail service.** That's the setting for mailboxes hosted elsewhere. With a filter in front, Plesk then refuses its own mail. - **Leaving SPF in a rejecting mode.** Plesk judges the filter's IP against the sender's SPF record and refuses legitimate mail. - **Expecting the white list to cover SPF.** Plesk's mail white list only skips DNSBL checks. - **Keeping the server as a lower-priority MX.** That is the route spammers use to skip the filter. - **Closing port 25 on a shared server.** Domains not filtered by iBlockSpam stop receiving mail. ## Outbound mail and SPF Nothing in this setup changes how Plesk sends mail. It keeps delivering outbound mail directly, so your SPF record stays as it is ([RFC 7208](https://www.rfc-editor.org/rfc/rfc7208)). Add iBlockSpam to SPF only if you later route outbound mail through the iBlockSpam [outbound relay](https://iblockspam.com/features/outbound-relay), which includes 500 messages per domain each month. ## Limits - Each domain includes 100,000 inbound messages per month and accepts messages up to 400 MB. Plesk's own message size limit also applies, and the smaller limit wins. - Unlimited mailboxes means any number of mailboxes per domain, not unlimited message volume. - Mail is spooled for up to 5 days if the server is down. Message history is kept for 30 days. - An MX lookup can't prove mail is filtered. Headers, logs and a direct-connection test are the evidence. Hosting providers can offer filtering across customer domains, with partner terms agreed individually; see [partners](https://iblockspam.com/partners) and our page for [hosting providers](https://iblockspam.com/solutions/hosting-providers). Other platforms are on the [platforms page](https://iblockspam.com/platforms). Stuck on a step? Our [support page](https://iblockspam.com/support) lists what to send so we can trace mail quickly. ## Frequently asked questions ### Do I switch off the mail service in Plesk when a filter sits in front of it? No. Plesk tells you to deactivate the mail service when mailboxes are hosted elsewhere. With an MX-level filter the mailboxes stay on Plesk, so the mail service must stay on to accept filtered mail. Only the MX record changes, plus a few settings so Plesk trusts the filter. ### Which SPF checking mode should Plesk use behind a spam filter? Only create Received SPF-headers, never block. Behind a filter, Plesk sees the filter's IP address as the connecting server, so any mode that rejects on an SPF result can refuse legitimate mail. The filter checks SPF against the original sender before mail reaches Plesk. This is our advice; Plesk's documentation doesn't cover external filters. ### Does Plesk's mail white list stop SPF and DMARC rejections for the filter? No. Plesk says mail from an IP on the Mail Server Settings white list is always accepted despite DNSBL listings, but it can still be rejected by SPF, DKIM or DMARC checks, delayed by greylisting or marked by SpamAssassin. That is why the SPF mode and the DMARC check need attention too. ### Can I keep SpamAssassin on Plesk as a second layer? Yes. Keep it on, with mailboxes set to move spam to the Spam folder rather than delete it. Add the filter's ranges to SpamAssassin's trusted_networks, so its network tests look at the server that sent the message to the filter rather than at the filter itself. ### Can I close port 25 on a Plesk server that hosts unfiltered domains? Not safely. A firewall rule applies to the whole server, so domains whose MX still points at Plesk would stop receiving mail. Restrict inbound port 25 to the filter only when every domain on the server is filtered. Ports 587 and 465 for your users stay open either way. --- Source: iBlockSpam, https://iblockspam.com/platforms/plesk (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt