Implementation Guidelines

1. Extract URIs from message bodies. (Extraction of URIs from message bodies should ideally include full resolution of redirections into the final target domain name. This can be a non-trivial problem.)

2. Extract base (registrar) domains from those URIs. This includes removing any and all leading host names, subdomains, www., randomized subdomains, etc. In order to determine the base domain it may be necessary to use a table of country code TLDs (ccTLDs) such as this partially-complete one SURBL uses. (Note that this file is only rarely updated. Please don't download it frequently.) For example, any domain found in the two level ccTLD list should have a three-level domain name extracted (like foo.co.uk) for matching against a SURBL. Domains not specifically on the two level ccTLD list (such as foo.com or foo.fr) should be checked at two levels.

3. Perform NO name resolution on these domains.

4. Look up the domain name in the SURBL by prepending it to the name of the SURBL, e.g., domainundertest.com.multi.surbl.org, then doing Address (A) record DNS resolution on the resulting combined name. A non-result (NXDOMAIN) indicates lack of inclusion in the list. An Address result indicates list inclusion, i.e., probable spam. (Individual lists return an A record of 127.0.0.2, but their use is deprecated in favor of multi.surbl.org as described in the note below.) SURBL matches also have a TXT record associated with them containing a descriptive reason for list inclusion, but the A record is the preferred query for machine use.

   ---

   When using the combined list multi.surbl.org, results will be bitmasked as described in the Lists section. In this case, membership in multiple lists is encoded according to respective bit positions in the returned Address value, and programs should decode these results into their respective individual lists.

   Future lists very likely will not be separate lists, therefore all SURBL applications should be written to use bitmasking and multi.

   ---

5. Handle numeric IPs in URIs similarly, but reverse the octet ordering before comparison against the RBL. This is a standard practice for RBLs. For example, http://10.20.30.40/ is checked as 40.30.20.10.multi.surbl.org. Numeric addresses should be in base-10 representation. If other representations of numeric IP addresses appear in messages, then they should be converted into four, reversed-order, dotted, base-10 octets before checking.

6. Include a local whitelist function to exclude certain known whitehat domains or IPs from SURBL checking. This is very important since it prevents many unnecessary queries against common domains like yahoo.com, w3.org, google.com, etc., which will never be blacklisted. It's described further in the FAQ.

7. An increasing number of DNS services are being deployed to protect end users against and to monetize typo, malware, phishing and spam sites by redirecting web service to an alternate site. Generally they do this by changing the IP address or NXDOMAIN responses to DNS queries. Unfortunately these changes can adversely affect SURBL DNS responses and create false positives or false negatives. One way to test for this is to make sure that responses to SURBL DNS queries are in 127/8, or more specifically 127.0.0.0/24. While this won't fully determine correct results, it's still a recommended and good basic input verification test. A good administrative solution is to run a local caching nameserver for DNS resolution, which can also improve performance. More information is in our FAQ.

Please DO NOT use SURBLs to check sender domains, sender IP addresses, sender IP address reverse DNS domains, mail servers, etc. Doing so may result in unexpected false positives!