RBL based on SPFBL

The reputation database is collected from our customers and contributors, where complaints are made by their own recipients and processed by our DNSBL server, which returns:


  • listed due to bad reputation and confirmed by anonymous complaints;
  • listed for suspected SPAM source, due to the difficulty of identifying the person responsible, without rDNS, because it is dynamic IP or SLAAC flag without valid email service and
  • listed for inappropriate use of the URL, such as phishing or used by spammer.


It is noteworthy that, in the case of returning, we block all IPs which we consider unsuitable for sending e-mail. In that case, the DNSBL does not only list systems that send spam, so it’s up to each administrator to decide how to use it (further down, integration tips for SpamAssassin, if you prefer, instead of rejection). Making an analogy with the RFC Ignorant list (now RFC Clueless), we also require a number of important settings, so we could be called the “SPF ignorant” or “FCrDNS ignorant” system. We believe it is important to identify spammers in order to punish them. More about our rules, in the our delist page.


Host: dnsbl.spfbl.net


IMPORTANT: We do not provide any guarantees, despite the best efforts to maintain a stable and coherent system. Use at your own risk and take into consideration that our systems works based on reputation, without privileges to any system, including Internet providers and email marketing systems, if they have a poor reputation. For this reason, we suggest you use our DNSBL to mark emails as spam, rather than by rejecting emails. Check your MTA documentation for details or, if it is not feasible, consider using SpamAssassin (see below), which has the downside of not normally scanning emails above a certain size.


IMPORTANT: Current limit is 100 ms per IP block. Lower frequencies require contribution. Please contact us informing your IP or range, for further details.

Alternate method of usage via SpamAssassin


This is a scenario that was helpful in a case in which the provider did not want to run the DNSBL for all its customers, rather only for Brazilian customers, based on the e-mail addresses of recipients, ending in .br. It is the same as using our DNSBL directly (dnsbl.spfbl.net host), however, for specific recipients. In this example, besides recipients with e-mail addresses ending in .br, we also added the recipient domains example1.com and example2.com, to be considered. The ideal is to increase the score in order to mark as spam. In the example below, the CUSTOM_SPFBL rule adds six points and verifies both result codes, and

header __RCVD_IN_SPFBL eval:check_rbl('spfbl-lastexternal','dnsbl.spfbl.net.')
describe __RCVD_IN_SPFBL Listed in dnsbl.spfbl.net.
tflags __RCVD_IN_SPFBL net

header __TO_BR TO =~ /\.br|exemplo\.com|exemplo2\.com/i


Domain queries on rspamd


Create a file called /etc/rspamd/local.d/surbl.conf with this:

rules {
suffix = "dnsbl.spfbl.net";
resolve_ip = false;
ips {

in /etc/rspamd/local.d/metrics.conf add

symbol "URIBL_SPFBL2" {
weight = 1;
score = 2.5;

symbol "URIBL_SPFBL3" {
weight = 1;
score = 2.5;