IP list

Blacklist removal guide

How to remove your IP from SPFBL

SPFBL is a reputation blocklist driven by recipient complaints. Here is what a listing means and how to clear it.

What it is

The list, in plain terms.

SPFBL is an open-source, collaborative anti-spam system whose public DNS blocklist is published at dnsbl.spfbl.net and operated through spfbl.net. Reputation is built from abuse complaints contributed by the servers that use it, combined with checks on how your sending infrastructure is configured.

The list flags IP addresses, not domains. It is intended for spam scoring rather than hard blocking: the operator states the zone must not be used to reject mail during the SMTP transaction, only to weight messages in filters such as SpamAssassin or Rspamd so they land in the junk folder. In practice many receivers still consult it, so a listing can push your mail to spam across those systems.

Because the listing is reputation-based and partly automated, it clears only once the underlying cause is resolved and your IP meets the operator's delisting requirements. There is a free path and a separate paid path, both run by SPFBL itself.

Why you get listed

What a listing on SPFBL means.

Recipient complaints Contributing servers reported mail from your IP as spam. This is the core signal behind a confirmed listing (return code 127.0.0.2).
RFC non-compliance The sending MTA does not comply with RFC 5321, or the party responsible for abuse on the IP cannot be identified — for example missing or mismatched rDNS and FCrDNS (return code 127.0.0.3).
No mail service at the address No mail server could be identified at the IP, or it appears to be a NAT router or a residential connection not expected to send mail directly (return code 127.0.0.4).
Unreliable abuse handling for the range The abuse team responsible for the IP range does not act on reports, so the range is treated as unreliable (return code 127.0.0.5).

How to get removed

Delisting, in order.

Removal is free. Fix the cause first — a listing you clear without a fix comes straight back.

  1. 1 Look up the IP and read the return code. Query your IP at spfbl.net/en/delist to see whether it is listed and which return code applies. The code tells you the cause — complaints, RFC non-compliance, no mail service, or an unreliable abuse range — and each points to a different fix.
  2. 2 Fix the cause first. Stop the outbound spam and secure any compromised account or relay for complaint listings. For configuration listings, set valid rDNS that resolves back to the sending IP (FCrDNS) in a domain you administer, and bring the MTA into RFC 5321 compliance. Delisting before the cause is gone will not hold.
  3. 3 Meet the free delist requirements. Free delisting requires valid FCrDNS with the rDNS in the MTA administrator's own domain (generic data-centre rDNS is rejected), a non-free TLD with public WHOIS that is not privacy-masked, an active postmaster account that responds for that domain, and an IP reputation below 25 per cent negative points. IPv6 SLAAC addresses must have port 25 open.
  4. 4 Submit the delist request. Once the requirements are met, complete the removal on the delist page at spfbl.net/en/delist. If your IP is on return code 127.0.0.5, the fix is handled through the FBL/DNSAL record rather than the standard delist form.
  5. 5 Re-check before resuming. After the request is accepted, re-query the IP on the same page and allow time for DNS to propagate before ramping your sending back up. If the cause reappears, the automated reputation checks will list the IP again.

The official route

Straight to the source.

Removal happens on SPFBL's own tool — never through a paid service.

SPFBL removal tool ↗

Return codes

127.0.0.2 Confirmed bad reputation from recipient complaints
127.0.0.3 Responsible party for abuse cannot be identified, or MTA not compliant with RFC 5321
127.0.0.4 No mail service found at the address; NAT router or residential connection
127.0.0.5 Abuse team for the IP range is unreliable; resolve via the FBL/DNSAL record

Common questions

About SPFBL, specifically.

Is SPFBL removal free? There is a free delist path at spfbl.net/en/delist, but it requires your IP to meet strict conditions: valid FCrDNS in your own domain, public WHOIS, an active postmaster, and reputation below 25 per cent negative points. IPs that cannot meet these can only use the operator's separate paid delist. Note that any third-party service charging to remove an SPFBL listing is a scam — only SPFBL controls its own list.
Why is my IP on dnsbl.spfbl.net when I never sent spam? SPFBL also lists on configuration and infrastructure grounds. Return code 127.0.0.3 means your MTA is not RFC 5321 compliant or the responsible abuse party cannot be identified, and 127.0.0.4 means no mail service was found or the IP looks residential or behind NAT. Fix rDNS, FCrDNS and MTA configuration rather than looking for a spam incident.
What does the SPFBL return code mean? 127.0.0.2 is a confirmed bad reputation from complaints; 127.0.0.3 is an unidentifiable abuse contact or RFC 5321 non-compliance; 127.0.0.4 is no mail service, a NAT router or a residential connection; and 127.0.0.5 is an unreliable abuse team for the IP range. Query your IP at spfbl.net/en/delist to see which applies.
Why do I need a postmaster account and public WHOIS to delist? Free delisting is only granted to IPs the operator can verify as legitimately run mail servers. It requires FCrDNS in a domain you administer, public and non-masked WHOIS, and an active, responding postmaster account for that domain. These prove accountability; without them, the free path is not available.
Should I hard-block mail using dnsbl.spfbl.net? No. The operator states the zone must not be used to reject mail during the SMTP transaction. It is designed for scoring in filters such as SpamAssassin or Rspamd, where a listing weights a message toward the junk folder rather than bouncing it.
I delisted but got listed again — why? The listing is reputation-based and partly automated. If the outbound spam, the misconfigured rDNS or the RFC non-compliance is still present, the checks will relist the IP. Resolve the cause permanently before requesting removal.

Do not fix it blind.

See every list you are on and every authentication problem behind the listing in one 40-second check — then let monitoring tell you the day a listing comes back.