SPF hard fail in production: SPFBL and SpamExperts fixes for DirectAdmin and cPanel

If you use SpamExperts as your filtering layer and users report incoming mail failures, especially from Outlook and Hotmail, you are likely hitting an SPF policy conflict in the delivery chain.

This guide explains the root cause and the server-side fix.

Diagnosis: SPF hard fail conflict

This issue is common when the sender domain uses SPF with -all (hard fail) and mail goes through SpamExperts before reaching your server.

Typical failure flow:

1. The sender sends the message (for example, Outlook/Hotmail).
2. SpamExperts receives and processes the email.
3. SpamExperts relays the message to your server (Exim on DirectAdmin/cPanel).
4. Your server validates SPF for the original sender, but sees the filter IP.
5. Since the filter IP is not authorized by sender SPF, Exim rejects the message.

In Exim logs (/var/log/exim/mainlog), you usually see:

rejected RCPT: SPF: [FILTER-IP] is not allowed to send mail from hotmail.com

Fix: whitelist trusted relay IPs

The fix is to explicitly trust SpamExperts relay ranges on the destination server so SPF does not incorrectly reject this relay path.

DirectAdmin: whitelist file update

On DirectAdmin, edit:

nano /etc/virtual/whitelist_hosts_ip

On cPanel, use:

nano /etc/trustedmailhosts

Add official SpamExperts ranges (common examples):

185.201.16.0/22
185.201.16.0/24
185.201.17.0/24
185.201.18.0/24
185.201.19.0/24
192.69.18.0/24
208.70.90.0/24
45.91.121.0/24
45.93.148.0/24
45.131.180.0/24
45.140.132.0/24
193.41.32.0/24
185.225.27.0/24
80.91.219.0/24
188.190.113.0/24
45.147.95.0/24
46.229.240.0/24
87.236.163.0/24
188.190.112.0/24
192.69.19.0/24
208.70.91.0/24
185.209.51.0/24
185.218.226.0/24

• Full list at: https://documentation.n-able.com/spamexperts/userguide/Content/Appendix/hc-deliv-ips.htm
• CSV: https://download.cdn.seinternal.com/public/delivery-subnets.csv

Note: always verify current ranges with official vendor documentation, because IP blocks can change.

Restart Exim:

service exim restart

Post-change validation

After applying the changes, monitor logs and retest delivery (for example, Outlook -> mailbox on your server):

tail -f /var/log/exim/mainlog

A successful case should show delivery/saved status, for example:

2026-01-27 15:56:17 ... <= mail@hotmail.com H=out13-256.antispamcloud.com [45.93.148.2] ... Saved

Spam filtering must not break legitimate delivery. Keeping trusted relay ranges updated (/etc/virtual/whitelist_hosts_ip on DirectAdmin and /etc/trustedmailhosts on cPanel) reduces SPF false rejections without sacrificing anti-spam protection.

Sender identity: the hidden noreply@ trap

Even with relay ranges fixed, blocks may continue when systems send from noreply@ addresses without a valid mailbox behind them.

Operational checks:

1. Confirm sender mailbox actually exists.
2. Validate routing with exim -bt.
3. Inspect logs for repeated sender identity failures.

Useful commands:

exim -bt noreply@yourdomain.com
grep -i "noreply@" /var/log/exim/mainlog | tail -n 200

Stable pattern:

• move from From: noreply@... to a real sender identity;
• preserve response flow via Reply-To;
• keep SPF/DKIM/DMARC aligned with the chosen sender.

This post is licensed under CC BY-NC.