Do not send e-mail to me!

DNSBL

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:

 

  • 127.0.0.2: listed due to bad reputation and confirmed by anonymous complaints e
  • 127.0.0.3: listed for suspected SPAM source, due to the difficulty of identifying the person responsible, without rDNS, because it is dynamic IP, with MTA not in compliance with RFC 5321 or SLAAC flag without valid and opened email service.

 

It is noteworthy that, in the case of returning 127.0.0.3, 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, 127.0.0.2 and 127.0.0.3.

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
meta CUSTOM_SPFBL (__RCVD_IN_SPFBL && __TO_BR)
describe CUSTOM_SPFBL HIT to BR
score CUSTOM_PSPFBL 6.0