SPFBL delisting: return codes, abuse contacts and the self-service path

SPFBL is a collaborative anti-spam project that publishes a DNSBL at dnsbl.spfbl.net, alongside a URI list and a whitelist. Its reputation data comes from participating servers and complaint reports, and its coverage is strongest among Brazilian providers — so if you send to Brazil, this list is in your path, and if you do not, it is a minor one.

What makes it worth understanding is the specificity of its answers. SPFBL's return codes separate "you have a bad reputation" from "we cannot tell who is responsible for abuse here" from "this does not look like a mail server". Those are three unrelated problems.

Read the return code first

dig +short 9.113.0.203.dnsbl.spfbl.net        # reversed octets of 203.0.113.9
dig +short -t txt 9.113.0.203.dnsbl.spfbl.net

The TXT record is where the detail lives, and SPFBL's own query page gives a fuller answer than a bare DNS lookup.

Fixing each code

`127.0.0.2` — complaints. The familiar work, and the only one that is genuinely about your sending. Purge unverified addresses, suppress hard bounces and complainers immediately, stop sending to contacts with no engagement in 90 days, separate transactional from marketing from outreach, and reduce volume while reputation recovers.

`127.0.0.3` — responsibility and compliance. This is an infrastructure and contactability problem. Make your mail server behave like a well-run one: forward-confirmed reverse DNS, a HELO name that matches the PTR, valid SPF and DKIM with DMARC alignment, correct bounce handling, and a working, monitored abuse contact — abuse@ on the domain and in the whois record for space you control. If nobody can report abuse to you, a reputation system has no way to tell you apart from an abandoned host.

`127.0.0.4` — not a mail server. The address looks like residential or NAT space. No amount of correspondence fixes that judgement, and Spamhaus PBL will say the same thing. Relay through a provider instead of sending directly.

`127.0.0.5` — the range's abuse handling. This is about the network that owns the address, not you. Raise it with your provider, and if they will not engage, move. You are renting space whose operator's reputation you inherit.

The delisting path

SPFBL publishes a query-and-delist page with its own rules, so start there rather than emailing anyone: look the IP up, read the stated reason and the conditions attached to that reason, and follow them. Two things are consistent across codes.

First, the condition has to be gone before the request. For 127.0.0.4 that means correct reverse DNS and a static, mail-capable address. For 127.0.0.3 it means the abuse contact exists and works. For 127.0.0.2 it means the sending that produced complaints has actually stopped.

Second, reputation-based entries also decay as the complaint signal ages, so patience is a legitimate strategy for a one-off incident.

Because SPFBL's rules are set by the project and can change, treat the page's current wording as authoritative over any article, including this one — the codes above are what the project documents, the procedure is what its delist page says today.

What not to do

• Do not assume every code is about spam. Submitting a long explanation of your opt-in process against a 127.0.0.4 listing accomplishes nothing; the answer there is DNS and address type.
• Do not leave `abuse@` unmonitored. On this list specifically, unreachability is itself a listing reason.
• Do not delist repeatedly while the behaviour continues. Collaborative lists treat repeat offenders as more severe.
• Do not ignore it because it is regional. If Brazil is a market, your mail is being filtered on this data.
• Do not fix it in isolation. Complaint-driven listings here coexist with trap-driven listings elsewhere; check Spamhaus, Barracuda and the URI lists while you are in the logs.

The standards work pays off everywhere

Almost everything SPFBL asks for — forward-confirmed reverse DNS, a matching HELO, aligned SPF and DKIM with DMARC, correct bounce handling, a working abuse contact — is independently expected by Gmail, Microsoft and Yahoo. A listing on a regional list is an unusually explicit audit of fundamentals that affect every receiver.

MailPilot checks SPF, DKIM and DMARC alignment and sending infrastructure, warms mailboxes over OAuth or SMTP at a controlled pace, and measures per-provider inbox placement daily, so the effect of fixing those fundamentals is visible rather than theoretical.