SPFBL check blocked: complete diagnosis (SPF hard fail, Hotmail/Outlook, and relay path)

SPFBL check blocked on legitimate senders is common when logical sender origin and actual delivery hop differ. In this case, sender SPF used -all while final delivery arrived from a third-party relay.

1) Production symptom

Observed pattern in exim_mainlog:

rejected RCPT <recipient@domain.com>: SPFBL check blocked

Real-time monitoring:

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

2) Root cause: SPF -all with delivery outside authorized sender path

Sender SPF:

v=spf1 include:spf.protection.outlook.com -all

Meaning:

• Microsoft infra allowed by include;
• all non-listed origins must fail due to -all.

If mail is relayed by a third-party gateway, SPF hard fail can be triggered, then blocked by SPFBL.

3) Validation workflow used

Check delivery hop headers:

exim -Mvh MESSAGE_ID

Check sender SPF record:

dig +short TXT domain.com

Test SPFBL decision directly:

spfbl check SOURCE_IP sender@domain.com recipient@yourdomain.com

4) Why basic whitelist can fail

Basic domain allow rule:

spfbl white add domain.com

In hard fail scenarios, this can be insufficient because engine decisions may still prioritize strict SPF path validation.

4.1) Hotmail/Outlook through third-party relay

This is a frequent production trap: sender identity is legitimate, but the final delivery hop is a third-party gateway with different reputation.

Example:

H=gateway-out.servidor-antispam.com [45.xx.xx.x] rejected RCPT: SPFBL check blocked

In this pattern, evaluate both sender policy and relay reputation before creating any exception.

5) Applied fix: qualified whitelist

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

This scopes trust to sender domain plus known delivery relay.

6) Post-fix validation

Check rule is present:

spfbl white show | grep -i "domain.com\|antispamcloud.com"

Retest decision:

spfbl check SOURCE_IP sender@domain.com recipient@yourdomain.com

Expected:

First WHITE match: @domain.com;antispamcloud.com

Validate Exim delivery outcome:

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

7) Hardening practices

1. Prefer scoped whitelist over global sender whitelists.
2. Monitor SPFBL blocks in Exim logs continuously.
3. Track client SMTP route changes.
4. Keep exceptions documented and periodically reviewed.

Quick checklist:

1. Confirm route with exim -Mvh.
2. Validate SPF with dig TXT.
3. Reproduce with spfbl check.
4. Apply minimal scoped exception.
5. Record and review exception lifecycle.

Rollback command:

spfbl white drop "@domain.com;antispamcloud.com"

This incident class is transport-policy mismatch, not necessarily sender fraud. With header inspection, SPFBL decision testing, and qualified exceptions, the fix stays stable and auditable.

This post is licensed under CC BY-NC.