SPFBL check blocked: complete technical diagnosis (SPF hard fail, Microsoft 365, and relay path)

Encountering a SPFBL check blocked error for a legitimate sender is one of the most frequent and complex support incidents in high-volume mail servers running Exim and cPanel. This specific rejection occurs when the logical origin of the sender (e.g., Microsoft 365, Google Workspace) does not align with the actual physical IP performing the delivery to your MTA.

This article details a real-world troubleshooting scenario where the sender's domain published a strict SPF record with the -all (Hard Fail) qualifier, but their emails were routed through an intermediate relay (such as an antispam gateway or corporate smarthost). This setup triggered a technical SPF failure, causing the local SPFBL engine to block the legitimate communication.

1) Observable symptoms in production#

The first sign of the incident surfaces in the Exim SMTP transaction log, showing that legitimate messages are rejected during the RCPT TO command:

rejected RCPT <[email protected]>: SPFBL check blocked

To monitor these incoming rejections in real-time, execute:

tail -f /var/log/exim_mainlog | egrep -i "spfbl|rejected RCPT|spf"

To extract and audit the delivery history associated with a specific sender domain:

grep -i "@sender-domain.com" /var/log/exim_mainlog | tail -n 200

2) Pre-requisite SPFBL daemon status checks#

Before making any changes to the antispam database, ensure the local SPFBL service is online and listening on its default port (8001 or 9877):

# 1. Check the systemd process manager status
systemctl status spfbl

# 2. Check status via the local SPFBL REST API
curl -s http://localhost:8001/api/v1/status | head -5
# Note: If the REST API is not enabled, use the command line query check:
# spfbl check 127.0.0.1 [email protected] [email protected]

# 3. Check for active running spfbl processes in the OS
ps aux | grep spfbl | grep -v grep

# 4. Verify that the daemon is listening on the expected ports
ss -lntp | grep -iE "8001|9877|spfbl"

# 5. Check the local SPFBL binary version
spfbl version

# 6. View configuration settings
cat /etc/spfbl/spfbl.conf 2>/dev/null | head -20

3) Pre-requisite rules database backups#

Ensure you have a recent backup of the whitelists and rules databases before modifying RBL exceptions:

# 1. Back up all current SPFBL whitelist rules
spfbl white show > /root/spfbl-whitelist-backup-$(date +%Y%m%d).txt

# 2. Backup the physical SQLite SPFBL database file
# Paths may vary depending on local installation defaults (/var/lib/spfbl/ or /var/spfbl/)
sudo cp /var/lib/spfbl/spfbl.db /root/spfbl-backup-$(date +%Y%m%d).db

4) Technical diagnosis and delivery routing#

Correct diagnosis requires examining the actual path taken by the email message and checking the DNS settings of the sender.

4.1 checking real mail flow in spool headers#

If a message is stuck in the queue or triggers intermediate logs, you can view the Received: headers to map the routing hops:

# View spool headers of a specific message ID
exim -Mvh MESSAGE_ID

Trace the physical IP of the final hop that established the SMTP connection to your MTA.

4.2 auditing queue status and active connections#

To measure the impact of the block on system delivery queues:

# 1. Count total messages in the active Exim queue
exim -bpc

# 2. View the first 20 entries in the active mail spool
exim -bp | head -20

# 3. Monitor active Exim processes to check for transport queues congestion
ps aux | grep exim | grep -v grep

5) DNS validation and SPF check#

SPFBL blocks the connection when the sender publishes a strict policy (-all) and the intermediate relay's IP is not explicitly defined in their records.

5.1 verification of DNS propagation#

Query multiple public DNS resolvers to rule out propagation delays:

# Query the TXT record of the domain across Cloudflare, Google, and OpenDNS
for dns in 8.8.8.8 1.1.1.1 208.67.222.222; do
    echo "DNS $dns: $(dig @$dns domain.com TXT +short | grep spf1)"
done

5.2 checking the DNS time to live (TTL)#

Determine the record's caching time to evaluate when updates will be parsed by your mail server:

dig domain.com TXT | grep -A1 "ANSWER SECTION"

6) Relay reputation and TLS security audits#

When emails arrive via intermediate relays (e.g. SpamExperts, antispamcloud.com, or Mimecast), you must audit both the reputation and TLS transport capability of that channel.

6.1 checking the intermediate relay reputation#

Avoid whitelisting relays with bad reputation scores or known spam issues. Verify using API tools:

# 1. Query the relay IP reputation score on AbuseIPDB
curl -s "https://api.abuseipdb.com/api/v2/check?ipAddress=45.xx.xx.x" \
  -H "Key: YOUR_API_KEY_HERE" \
  -H "Accept: application/json"

# 2. Perform a reverse DNS lookup (PTR) to verify the relay FQDN
dig -x 45.xx.xx.x +short

6.2 checking TLS configuration on the relay#

Ensure the SMTP transmission channel between the relay and your MTA is encrypted:

# 1. Verify STARTTLS capability on the relay port 25
openssl s_client -connect gateway-out.servidor-antispam.com:25 -starttls smtp

# 2. Verify the validity dates of the SSL certificate on the relay
echo | openssl s_client -connect gateway-out.servidor-antispam.com:25 2>/dev/null | openssl x509 -noout -dates

# 3. Check for recent TLS connection handshakes in the Exim log
grep -i "tls" /var/log/exim_mainlog | tail -n 10

7) Exim logs audits and blast radius#

Investigate if the SPFBL blocking behavior is systemic or limited to specific domains.

7.1 advanced Exim log filtering#

Use detailed commands to isolate SPFBL rejections and delivery routes:

# 1. Extract recent SPFBL check block errors
grep -i "spf\|rejected\|blocked" /var/log/exim_mainlog | tail -n 50

# 2. Monitor successful deliveries for the target domain
grep -i "=>.*domain.com" /var/log/exim_mainlog | tail -n 20

# 3. Check for specific gateway/relay delivery logs
grep -i "relay\|gateway" /var/log/exim_mainlog | tail -n 20

7.2 multi-domain impact audits#

Identify if other hosted domains are failing delivery through the same relay infrastructure:

# List and count the top 20 domains blocked by SPFBL
grep -i "spfbl check blocked" /var/log/exim_mainlog | \
  awk '{print $6}' | sort | uniq -c | sort -rn | head -n 20

# Check other sender domains using the same antispam relay host
grep -i "antispamcloud.com" /var/log/exim_mainlog | \
  awk '{print $6}' | sort -u

8) Scoped whitelisting: the safe solution#

Using a simple domain-level whitelist (spfbl white add domain.com) is a security risk because it allows anyone to spoof that domain from any IP address.

The correct approach is to restrict the whitelist to the sender domain AND the specific relay's HELO/EHLO domain signature:

/usr/local/bin/spfbl white add "@sender-domain.com;antispamcloud.com"

Rule semantics#

• @sender-domain.com: Restricts whitelisting only to mailboxes within the specified domain.
• ;antispamcloud.com: Requires that the SMTP delivery connection originates from a server with HELO/EHLO belonging to the trusted relay host.

9) Post-fix verification and alert monitoring#

After updating the database, perform health tests to confirm that emails bypass the block.

9.1 test SPFBL verdict resolution#

Verify if the database exception is correctly recognized by the daemon:

# The tool should output the matched whitelist exception rule
spfbl check RELAY_IP [email protected] [email protected]

9.2 real-time log monitoring#

tail -f /var/log/exim_mainlog | grep -iE "@sender-domain.com|spfbl"

9.3 automated log monitoring and cron alerts#

Add an automated check to cron to alert you if SPFBL blocks occur frequently:

# Add this task to the root crontab (/etc/crontab or crontab -e):
# */5 * * * * /usr/bin/grep -c "spfbl check blocked" /var/log/exim_mainlog | xargs -I{} test {} -gt 10 && echo "Alert: More than 10 SPFBL blocks detected in recent logs." | mail -s "SPFBL Blocks Alert" [email protected]

10) Checklist: SPFBL blocking incident recovery#

Use this checklist during field audits of mail blocking events:

Phase 1: Diagnostics and health check#

• [ ] SPFBL Daemon: Checked daemon status (systemctl status spfbl) and verified port 8001 is listening.
• [ ] Exim Logs: Collected the rejection signature in /var/log/exim_mainlog.
• [ ] Spool Headers: Inspected spool headers (exim -Mvh) to map out the IP route.
• [ ] Software version: Confirmed the running version (spfbl version) and config parameters.

Phase 2: Security and DNS audits#

• [ ] TLS Transport: Inspected if STARTTLS is supported and validated certificate dates on the relay.
• [ ] Relay Reputation: Checked the relay IP on AbuseIPDB and reverse DNS hostname.
• [ ] Multi-DNS Checks: Verified the sender's SPF record across Google, Cloudflare, and OpenDNS resolvers.
• [ ] Spool Queue: Checked for mail spool bottlenecks (exim -bpc).

Phase 3: Mitigations and acceptance testing#

• [ ] Preventive Backup: Exported the current whitelists to a backup file.
• [ ] Scoped Whitelisting: Added the exception restricted to the domain and its relay HELO/EHLO.
• [ ] Rule Validation: Tested the database query output using spfbl check.
• [ ] Log Auditing: Monitored Exim logs to verify that new messages are delivered without RBL blocks.

References#

• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1.
• RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security.
• SPFBL Project Documentation: Official guidelines for integrating post-fix mail servers, whitelists, and HELO/EHLO scopes.

See also

Email The Exim black hole, DMARC alignment failures, and restoring IP reputation

Email Domain Whitelist vs. RBL Blocking in cPanel and Exim: Why Whitelisting Fails and How DNSBLs Operate

Infrastructure Infra diary: taming antispam gateways, SPF failures, and Bash filters

This post is licensed under CC BY-NC.