If incoming mail to your Plesk server suddenly started bouncing with a message referencing zen.spamhaus.org and the words "Error: open resolver", your server is not actually blacklisted — it is being rejected by Spamhaus because of how it queries their DNSBL. This plesk spamhaus open resolver error has become one of the most common causes of sudden mail delivery failure on Plesk servers in 2025 and 2026, and it is not fixed by warming up your IP or checking your SPF records. It requires a specific configuration change.
1. What the "Open Resolver" Error Actually Means
When a sender tries to deliver mail to your Plesk server, Postfix checks the sender's IP against DNSBL zones such as zen.spamhaus.org. Spamhaus used to let anyone query these zones for free through the public DNS system. It no longer does. Public DNS resolvers (Google's 8.8.8.8, Cloudflare's 1.1.1.1, and most ISP resolvers) are now treated by Spamhaus as "open resolvers" — shared infrastructure they cannot rate-limit or attribute to a single mail server. Instead of returning a normal blocklist answer, Spamhaus returns a special response code telling Postfix the query itself is invalid.
Postfix does not know how to interpret that as "skip this check" — it interprets it as "this sender is blocked," and rejects the connection outright. The result: legitimate senders bounce, and your own users start asking why external mail stopped arriving.
The exact error you will see
In /var/log/maillog or /var/log/mail.log, affected connections show something like:
554 5.7.1 Service unavailable; Client host [203.0.113.45] blocked using zen.spamhaus.org; Error: open resolver;
For assistance, see https://www.spamhaus.org/returnc/pub/The IP inside the brackets is the sender's IP, not yours — which confuses a lot of admins into thinking the sending server is at fault. It is not. Your Plesk server's DNS resolution path is what triggered the rejection.
What triggers the "127.255.255.x" response
Spamhaus DNSBL zones reply with an address in the 127.0.0.2-127.0.0.255 range for genuine blocklist matches. Special codes in the 127.255.255.0/24 range mean something else entirely:
127.255.255.252- typo or malformed query127.255.255.254- query came from a public/open DNS resolver127.255.255.255- query rate exceeded the free usage threshold
Any Plesk server that resolves DNSBL lookups through a shared or public upstream resolver — which is the default in many hosting setups — is a candidate for this problem, especially on shared hosting nodes where dozens of domains generate high query volume.
💡 None of these worked? Skip the guesswork.
Get Expert Help →2. Confirm This Is Your Actual Problem Before Changing Anything
Run a manual lookup against Spamhaus's zen zone from the server itself, using a test IP known to be listed (Spamhaus publishes 127.0.0.2 as a permanent test entry reachable via 2.0.0.127.zen.spamhaus.org):
dig 2.0.0.127.zen.spamhaus.org +shortA healthy, authenticated setup returns 127.0.0.4 (confirming the test entry resolves). If instead you get no answer, a SERVFAIL, or a response in the 127.255.255.x range, your resolver path is being treated as an open/public resolver by Spamhaus.
cat /etc/resolv.conf
postconf | grep smtpd_recipient_restrictionsIf /etc/resolv.conf points at 8.8.8.8, 1.1.1.1, or your upstream provider's shared DNS servers, that is almost certainly the root cause.
grep -i "open resolver" /var/log/maillog | tail -20If this returns hits, every bounce with this signature is a Spamhaus rejection, not a real blocklist hit — do not waste time on IP reputation cleanup or SPF/DKIM changes for this specific symptom.
Sign up at Spamhaus's DQS registration page with your domain and a valid admin email. Most servers doing normal levels of inbound mail checking qualify for the free tier at no cost.
In Plesk, go to Tools & Settings > Mail Server Settings, and find the DNS blackhole list (DNSBL) configuration field. Replace any entry referencing zen.spamhaus.org or sbl.spamhaus.org with your keyed DQS hostname, in the format:
YOUR_DQS_KEY.zen.dq.spamhaus.netDo the same for the domain blocklist if you use it:
YOUR_DQS_KEY.dbl.dq.spamhaus.netSome Plesk versions store the DNSBL zone separately from the raw Postfix main.cf value. Confirm and edit directly if needed:
postconf | grep smtpd_recipient_restrictions
postconf -e 'smtpd_recipient_restrictions = ..., reject_rbl_client YOUR_DQS_KEY.zen.dq.spamhaus.net, ...'
systemctl restart postfix4. Re-run the manual test query using your key to confirm the fix landed:
dig 2.0.0.127.YOUR_DQS_KEY.zen.dq.spamhaus.net +shortYou should now get a real answer (127.0.0.4 for the test entry) instead of a 127.255.255.x code or a timeout.
4. Alternative Fixes If You Cannot Register for DQS Immediately
If you need mail flowing again before completing DQS registration, you have two lower-effort options — both are workarounds, not permanent fixes.
Option A: Point Postfix at a non-public DNS resolver
Run a local caching resolver (Unbound is lightweight and works well on Plesk servers) so DNSBL queries originate from your server's own IP rather than a shared public resolver:
dnf install unbound -y
systemctl enable --now unbound
echo "nameserver 127.0.0.1" > /etc/resolv.confThis alone resolves the open-resolver classification for many servers, since Spamhaus's objection is to shared/public resolvers, not local ones — though very high query volume can still hit rate limits without a DQS key.
Option B: Temporarily disable the Spamhaus zones
In Tools & Settings > Mail Server Settings, remove any entry containing spamhaus or abuseat from the DNSBL field, leaving other working blocklists (such as bl.spamcop.net) in place. This restores mail flow immediately but weakens spam filtering until DQS is configured — treat it as a stopgap, not the destination.
5. Prevent This From Recurring
- Register the DQS key as a standard step in any new Plesk mail server build — don't wait for a rejection to discover the default zone name is now unreliable.
- Run a local caching resolver (Unbound or BIND) on every mail-handling server rather than relying on public or ISP-provided DNS.
- Monitor
/var/log/maillogfor the stringopen resolverwith a simple cron-driven grep and alert, so a recurrence is caught before customers report bounced mail. - Periodically re-verify the DQS key test query (
dig 2.0.0.127.KEY.zen.dq.spamhaus.net) after any Plesk update, since some upgrades have been known to reset DNSBL fields to their pre-DQS defaults. - Document the DQS key and where it is configured (Plesk field vs. raw
main.cf) so the next admin doesn't waste hours rediscovering the same fix.
DNSBL misconfiguration is one of the more time-consuming email issues to diagnose precisely because the error message points at the sender's IP rather than your own resolver setup. If your team is spending recurring hours chasing mail delivery issues like this one across Plesk servers, CloudHouse's server management service handles DNSBL, Postfix, and mail queue configuration as part of ongoing proactive server monitoring, so these issues get caught before they generate support tickets.
6. How This Differs From a Genuine IP Blacklist Listing
It is worth separating this issue clearly from the more familiar "my server's IP is on a blacklist" problem, because the remediation paths are completely different. A genuine Spamhaus listing (SBL, XBL, or PBL) means your server's own outbound IP has a history of sending spam, running compromised scripts, or being part of a botnet, and the fix involves cleaning malware, rotating credentials, and requesting delisting through Spamhaus's removal process. The open resolver error, by contrast, has nothing to do with your server's sending reputation at all — it is purely about how your server performs DNS lookups when checking incoming mail against Spamhaus's list. A server with a spotless sending reputation can still throw this error on every single inbound connection if its resolver configuration is wrong.
This distinction matters operationally because teams often burn hours on the wrong remediation: requesting IP delisting, rotating SMTP credentials, or auditing outbound mail logs, when the actual fix is a five-minute DNSBL zone change. Before escalating a mail delivery incident, always check the maillog for the specific "open resolver" string first — it tells you immediately which of the two problems you are actually dealing with.
FAQs
Why does the Spamhaus error show the sender's IP instead of mine?
The error message logs the IP of the server attempting to deliver mail to you, since that is the address being checked against the blocklist. The actual cause of the rejection is your own server's DNS resolver path, not the sender's reputation.
Is the free Spamhaus DQS key enough for a small Plesk server?
Yes. Spamhaus's free DQS tier covers the query volume of most small and mid-sized mail servers. Only very high-volume senders or shared hosting nodes with heavy inbound traffic are likely to need a paid tier.
Will removing Spamhaus from the DNSBL list hurt my spam filtering?
It reduces one layer of spam filtering, since Spamhaus's zen zone is one of the most widely trusted blocklists. Treat removal as a temporary measure only, and re-add it via DQS as soon as possible.
Does this issue affect outgoing mail too?
No. This specific error affects incoming mail checks that your Plesk server performs against senders. Outbound deliverability problems (your IP being blocked by other providers) are a separate issue requiring SPF, DKIM, DMARC, and IP reputation checks.
Do I need to restart Plesk services after changing the DNSBL zone?
Restarting Postfix (systemctl restart postfix) is sufficient in most cases. A full Plesk mail service restart is only needed if the GUI field does not appear to apply after a Postfix restart.