Intermittent Spamhaus RBL Blocks for Outlook & GMX on HestiaCP/Exim

Community Support Mail
1

Hello Hestia community,

I’m running HestiaCP with Exim4, ClamAV and SpamAssassin on my mail server. Over the past few days, I noticed that incoming messages from both Outlook (Office 365) and GMX were being rejected with a “550 Rejected because is in a black list at zen.spamhaus.org” error. However, when I checked the same IPs on the Spamhaus website, they were reported as not listed.

After I reloaded Exim (sudo systemctl reload exim4) and flushed my DNS resolver cache, all pending Outlook and GMX mails started coming through immediately. This leads me to believe that Exim was querying a stale or slow DNSBL cache and acting on outdated blacklist status.

My questions to the community are:

  1. Has anyone else experienced intermittent RBL blocks for perfectly clean IPs, only to have them resolved by an MTA reload or DNS cache flush?
  2. Do you run any automation or cronjob to periodically flush DNS caches or reload Exim to avoid this?
  3. Are there recommended best practices or built-in Hestia/Exim settings to ensure the most up-to-date DNSBL lookups (e.g. configuring resolver timeouts, cache settings, or integrating a local Unbound/Bind instance)?

Any insights or configuration snippets would be greatly appreciated!

Maybe it helps.

Thanks

2

Hi everyone,

I ran into this issue again after removing my temporary whitelist entries. Now, GMX mail submissions are blocked with:

SMTP error from remote server for RCPT TO command, host: mail.domain.de (152.xx.xx.xx) reason: 550 Rejected because **212.227.15.19** is in a black list at zen.spamhaus.org

Yet when I check 212.227.15.19 on check.spamhaus.org, it shows not listed. A few observations:
https://check.spamhaus.org/results?query=212.227.15.19

  • Dynamic GMX IP pool: GMX seems to rotate through a set of outbound IPs
  • Stale DNSBL lookups: Exim must be caching old RBL responses or querying a slow/lagging resolver.
  • Temporary whitelist workaround: Whitelisting specific IPs in hostlist whitelist_mails works, but is not maintainable long-term given the rotating IPs.
18:42 ~ $ dig +short 15.15.227.212.zen.spamhaus.org TXT
18:42 ~ $ dig +short 15.15.227.212.zen.spamhaus.org A

No entries!

Questions for the community:

  1. How do you handle RBL lookups for large, dynamic providers like GMX or Office 365 in Exim on HestiaCP?
  2. Do you run a local DNS caching service (Unbound/Bind) or cronjob to flush resolver cache before each lookup?
  3. Have you found a way to automatically refresh or bypass RBL checks for entire provider ranges without disabling RBL entirely?

Any configuration snippets or tips on keeping DNSBL data fresh (resolver settings, cache TTLs, automation) would be hugely appreciated!

Thanks for your help!

3

Below is a concise report of the workaround I’m currently using to bypass the “550 … in a black list at zen.spamhaus.org” errors for GMX and Outlook IPs, followed by some questions about whether this is the best approach.

Summary

I added a directive in Exim’s global options to force all DNS and RBL lookups through my local BIND9 instance on 127.0.0.1, then flushed both Exim’s cache and the specific Spamhaus RBL entry. After these steps, emails from GMX and Office 365 now arrive without being rejected. However, I’m not entirely sure this is the most robust or recommended configuration, so I’d appreciate feedback from anyone who has handled similar issues.

Current Configuration Steps

sudo nano /etc/exim4/conf.d/main/00_local_options
# Force all DNS and RBL lookups to local BIND9
dns_servers = 127.0.0.1

This setting tells Exim to ignore the systemd-resolved stub on 127.0.0.53 and to send all DNS queries—MX lookups, callouts, and DNSBL checks—directly to BIND9 on localhost

sudo update-exim4.conf
sudo systemctl reload exim4

Reloads the Exim configuration so the new dns_servers directive takes effect.

sudo rndc flush
sudo rndc flushname 15.15.227.212.zen.spamhaus.org

Clears BIND9’s entire cache, then specifically evicts the Spamhaus lookup for the GMX IP, ensuring no stale “open resolver” error remains.

After performing these steps, test emails from GMX and Outlook no longer yield:

550 Rejected because <IP> is in a black list at zen.spamhaus.org

—they now successfully enqueue and deliver.

Questions & Concerns

  • Is dns_servers = 127.0.0.1 the best practice? Exim’s main configuration manual lists many global options but doesn’t explicitly document dns_servers in all distributions—has anyone else used this directive in production?
  • Automation of cache maintenance: Should I schedule periodic rndc flush (e.g., via cron) to prevent future “open resolver” glitches when provider IPs rotate?
  • Alternate resolver strategies: Some suggest running Unbound for better DNSSEC/QNAME handling or deploying Spamhaus’s Data Query Service (DQS) API—has anyone compared these approaches to the simple BIND9 setup?
  • Long-term stability: Could forcing Exim off the systemd stub have unintended side-effects for other DNS-dependent functionality (e.g., DKIM callouts, SPF checks)?

Any insight, configuration snippets, or pointers to official best-practice guides would be greatly appreciated!

4

What resolver are you using? Check if those resolvers are being blocked by spamhaus.

Run this to check: curl -sSL https://7j.gg/chksph2 | bash -s --
If those are being blocked, change them to:
76.76.2.0 & 76.76.10.0
Then check again via the command after restarting exim.

1 Like
5 
21:05 ~ $ curl -sSL https://7j.gg/chksph2 | bash -s --
Test 01: Listed by XBL, see https://check.spamhaus.org/query/ip/127.0.0.4
Test 02: Listed by XBL, see https://check.spamhaus.org/query/ip/127.0.0.4
Test 03: Listed by XBL, see https://check.spamhaus.org/query/ip/127.0.0.4
Test 04: Listed by XBL, see https://check.spamhaus.org/query/ip/127.0.0.4
Test 05: Listed by XBL, see https://check.spamhaus.org/query/ip/127.0.0.4
Test 06: Listed by XBL, see https://check.spamhaus.org/query/ip/127.0.0.4
Test 07: Listed by XBL, see https://check.spamhaus.org/query/ip/127.0.0.4
Test 08: Listed by XBL, see https://check.spamhaus.org/query/ip/127.0.0.4
Test 09: Listed by XBL, see https://check.spamhaus.org/query/ip/127.0.0.4
Test 10: Listed by XBL, see https://check.spamhaus.org/query/ip/127.0.0.4

Result is good, Spamhaus works fine with your current DNS Resolver 127.0.0.53

I can’t see the issue :confused:

6

Exim ignores that config file, so it doesn’t work (at least not if you haven’t changed the configuration). Hestia configures Exim to use a monolithic config file: /etc/exim4/exim4.conf.template

You should have split conf disabled:

$ grep split /etc/exim4/update-exim4.conf.conf
dc_use_split_config='false'

There isn’t an issue, at least not now. If you changed the dns resolver to use your local resolver, it should work fine. As you are using systemd-resolved, to check the dns resolvers used:

resolvectl status
1 Like
7

I edited /etc/systemd/resolved.conf to use Cloudflare’s public DNS:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=2606:4700:4700::1111 2606:4700:4700::1001
DNSOverTLS=yes

Then I ran:

systemctl restart systemd-resolved

Now systemd-resolved is correctly using those DNS servers, but whenever I send mail from Outlook or GMX to my server, I get this error:

Remote server returned message detected as spam
550 Rejected because 40.92.91.32 is in a black list at zen.spamhaus.org; Error: open resolver; https://check.spamhaus.org/returnc/pub/172.70.249.7/

If I switch to:

[Resolve]
DNS=127.0.0.1
# FallbackDNS=2606:4700:4700::1111 2606:4700:4700::1001
DNSOverTLS=no

mail delivery works again. However, I have been fooled into thinking that the setup was fine, only to discover later that it wasn’t. At the moment I can receive messages from Google and Outlook without issue.

Could someone explain why using Cloudflare’s DNS causes my server to appear as an “open resolver” and end up on Spamhaus, and how I can fix it?

The default DNS server looks faulty :neutral_face:

8
2 Likes