SURBL Blacklist: What It Lists and How to Get Removed

A blocklist checker returns a red row for SURBL, and the first instinct is to look at the sending domain. That is the wrong place. SURBL, the reputation service at surbl.org whose FAQ expands the name as Spam URI Realtime Block List, does not evaluate who sent a message. It evaluates the domains that appear inside it, which means the listed name is frequently a link shortener, a click-tracking host or a partner site, and frequently belongs to somebody else entirely.

Getting that backwards is expensive, because a removal request filed for a domain you do not own goes nowhere, and the remedy that does work takes about ten minutes.

What is SURBL?

SURBL is a reputation service, run by SURBL BV from surbl.org, that publishes lists of domains and IP addresses found in the links inside messages. A mail filter looks up each linked domain over DNS, and a match lets it filter or tag the message, in the homepage's words, "based on links in the message body, regardless of sender IP addresses".

Its own lists page describes the datasets as intelligence "that can be used to filter or tag application data", usable with programs that check message body web sites, and notes that most of its current use cases are no longer about email at all: DNS firewalls, hosting providers looking for bad actors in their own customer base, and botnet mitigation.

The distinction that matters for a sender is stated most plainly in SURBL's FAQ, in a passage about configuring local exclusions. The entries, it says, "should only apply to domains and IPs (hosts) that appear in message body URIs. They should not apply to mail server names, sender domains, message headers, etc."

That is the whole mechanism in one sentence. Your sending IP, your envelope sender and your HELO hostname are not what is being tested. The implementation guidelines say it again from the other side: "Please do not use our intelligence to check sender IP addresses."

In a cold email that leaves five kinds of domain to look up: the click and open tracking domain, any link shortener, the destination of every link including your own landing page, a partner or case-study site named in the copy, and anything in the signature, a calendar booking host included. By SURBL's own description, the sending domain matters only where it also appears as a link in the body.

The homepage also lists private datasets that are not available on its public DNS servers, among them Fresh, a list of domains recently added to TLD zone file delegations. That is a different product from the SEM-FRESH list of domains registered in the last 5 days, which Spam Eating Monkey runs.

From: the sending domain · Envelope sender and HELO hostname: not what is being tested

Every link in the copy is wrapped by the click and open tracking domain. 1

A case study sits behind a link shortener. 2

The call to action points at your own landing page. 3

The signature carries a website and a calendar booking host. 4

1. 1The tracking domain. CT lists tracking domains used by senders mailing without confirmed opt-in, so a shared one carries every customer's behaviour.
2. 2Any link shortener in the body is looked up as its own domain, and its operator has no reason to prioritise one sender's campaign.
3. 3The destination of every link, including your own landing page and any partner or case-study site named in the copy.
4. 4Anything in the signature, a calendar booking host included. The sending domain matters only where it also appears as a link in the body.

The complementary problem, which of your four domains is being tested and at which point in the delivery, is worked through in blacklist domain name checks.

invaluement's ivmURI list reads the same body links and names surbl.org as its comparable, so the same diagnosis applies to a row against it.

The SURBL blacklist is six lists behind one name

SURBL is not a single list. Its lists page names six datasets, each with a different source and a different meaning, and combines them into one public zone.

ABUSE covers spam and abused sites, described as mainly general abused sites such as pills, counterfeits and dating, with data from anti-abuse, ISP and ESP communities alongside SURBL's own research.

PH is phishing, drawing on PhishTank, PhishLabs, URLAbuse and other sources. MW is malware sites, including data from abuse.ch and others.

CR is cracked sites. SURBL's description is worth knowing because it explains a listing that looks impossible: criminals break into sites through vulnerabilities in a CMS such as WordPress or Joomla and add malicious content, and in SURBL's own wording, "Cracked sites usually still contain the original legitimate content". A perfectly ordinary company website can be listed without its owner noticing anything.

DM is disposable email domains, described as domains that classify as disposable email solutions, on the reasoning that somebody signing up with one is most likely hiding their identity. What that class does to a list you bought is in disposable email.

CT is the one that matters most to anybody running cold outbound, and it is worth quoting exactly. The CT list, in SURBL's own words, "contains domains used for tracking clicks in emails", and then: "We only list domains used by senders that send emails to mailboxes without confirmed opt-in (e.g. emails also sent to spamtraps)."

Read that twice if you run outbound. The criterion for the click-tracker list is not malware or fraud. It is sending to addresses that never confirmed opt-in. A shared click-tracking domain on a sending platform carries the aggregate behaviour of every customer using it, and a single customer running an unverified list is enough to put that domain into the population the CT list describes. Your own copy, your own list quality and your own sending discipline do not protect a domain you share.

SURBL multi: reading the answer, not just the red row

SURBL multi is the combined public zone, multi.surbl.org, into which every public list is folded. A domain has one entry there, and the last number of the address it returns names its lists: 4 for DM, 8 for PH, 16 for MW, 32 for CT, 64 for ABUSE and 128 for CR. A domain on several lists returns the sum of their values.

SURBL publishes how to decode it. Bitmasking, its lists page explains, "means that there is only one entry per domain name or IP address, but that entry will resolve into an address (DNS A record) whose last octet indicates which lists it belongs to."

The bit positions sit on the same page, written as "4 = listed on DM" through to "128 = listed on CR", with 8 for PH, 16 for MW, 32 for CT and 64 for ABUSE in between. A domain on more than one list returns the sum, so a last octet of 80 means the entry sits on both MW and ABUSE, because 16 plus 64 is 80.

SURBL's lists page adds that the octets other than the first and last are reserved for future use and should be ignored, so the last number is the whole answer.

That number is the diagnosis, and most aggregated checkers throw it away. A response of 127.0.0.32 puts the domain on the click-tracker list, which points at opt-in and list quality. A response of 127.0.0.128 puts it on the cracked-sites list, which points at a security incident on somebody's server and has nothing to do with mail at all. The two findings have no remedy in common, and a red row reading only SURBL cannot tell them apart.

A row that names Sender Score is a different confusion again, a rating mistaken for a list, and the Sender Score blocklist page separates the score from the Return Path Blocklist behind it.

Each listed entry also carries a TXT record naming its lists. The lists page says those are meant for human readers, for example in non-delivery messages, and that software should read the A record, which is why a bounce string can quote SURBL's own wording.

Two operational details sit alongside it. SURBL publishes a default TTL of 60 seconds for the live multi data, and says the data "is highly dynamic and on average gets updated every 30-40 seconds". A listing can therefore appear and clear faster than a daily monitoring job will ever see, which argues for reading your bounce strings rather than trusting a scheduled scan.

How to run a SURBL lookup or check

A SURBL lookup is a DNS query. Put the domain in front of the public zone, as in example.com.multi.surbl.org, and ask for its A record. No record (NXDOMAIN) means the domain is on no list. An address such as 127.0.0.32 means it is listed, and the last octet names the list. For a one-off check, SURBL's Lookup page does the same by hand.

The web form takes "a Fully Qualified Domain Name or valid IP", and its notes ask for IP addresses in normal order, such as 10.20.30.40, which it checks and displays reversed. The same notes ask that nobody point automated lookups at it: "Please do NOT use this web site for any automated lookups." Scripts use DNS, as the implementation guidelines describe.

Those guidelines add three rules that stop a check from lying. Perform no name resolution on the domain first, because SURBL compares names with names. Reverse an IP address found in a link before the query, so http://10.20.30.40/ is checked as 40.30.20.10.multi.surbl.org. And query the domain as it appears, because on the wildcarded public zone a subdomain of a listed domain matches the listed domain.

Two answers are not listings. A result of 127.0.0.1 from the public nameservers, the lists page says, "means your access is blocked". The usage policy reserves the free query service for organisations with fewer than 1,000 users or scanning fewer than 250,000 messages per day, and sends heavier users to its paid data feed. And a resolver that rewrites failed lookups, which the FAQ says some ISP nameservers do, can make a clean domain look listed. The guidelines' basic test is that a genuine answer starts with 127.

Before trusting a clean result, query the permanent test point, surbl-org-permanent-test-point.com, which the FAQ says answers 127.0.0.126. If that comes back empty, the check is broken, and a clean row means nothing.

Getting removed, and the faster alternative

SURBL's FAQ and its lists page give the same single route for every dataset: start at the Lookup page and follow the instructions on the removal form.

For three of the lists the lists page sets a precondition. Before a removal request for CR, PH or MW, it asks the owner to remove and secure everything malicious on the site and on "all computers used to upload content to the web site", and warns that "Systems that are not properly secured may be broken into again." It also notes that DNS control panels have been cracked to add malicious subdomains, so the domain's DNS needs securing too.

That route only applies where the listed domain is yours. Where it is a shortener, a shared tracking host or a third-party site, the request would have to come from whoever owns the name, and a shortener operator has no reason to prioritise one sender's campaign.

Replacing a shared tracking domain with a dedicated one is a platform configuration rather than a campaign change, and it is the single highest-value fix in this whole area, because it converts a reputation you cannot influence into one you can. A campaign sent with tracking switched off carries no tracking domain to look up at all.

What a listing is worth worrying about, and what it is not

A URI listing and a sender reputation problem produce different symptoms and respond to different work, so the first question is which one you have. Refusals that name a list, arrive suddenly and cluster at particular receivers point at a listing. Mail that is accepted and lands in spam while reply rates fall points at reputation, which no operator publishes and no form fixes. How to improve domain reputation, step by step is the work that follows in that case, and the delisting paths for the sender-side lists are in email blacklist check and recovery.

Where the named list is Abusix, the return code says which of its lists answered and the delisting needs a confirmed account first, as the Abusix blacklist page sets out.

Reading the refusal itself is how that question gets settled, and the digits a receiver returns carry the verdict while the text after them carries the reason.

Weighting matters too. SURBL data is consumed by content filters and by the various server-side integrations its own links page catalogues, and a listing on a domain in your body copy is a real problem at every receiver that consults it. It is a different event from a listing on the list that gates inbox placement at the large consumer providers, and treating every red row on an aggregated checker as equally urgent produces a lot of work with no delivery improvement attached. Weight the row by which dataset fired and by whether any of your bounce strings has ever named it.

The widest of the sender-side lists, which names a whole provider rather than an address, is UCEPROTECT Level 3, and the same bounce-string test applies to it.

RevenueFlow's own operating rule takes that weighting to its end: a SURBL row on a sending domain is not, by itself, a reason to retire that domain or its inboxes. Bounce rates are judged as rates, and a refusal that names SURBL is read for which domain it names.

Another operator publishing both an address list and a domain list is ZapBL, which refuses third party reports outright and escalates a whole block at three listings, as its listing and removal policy sets out.

At the other end of that spectrum sits the PSBL blacklist, which lets anyone remove an address the moment it is listed and expires the rest on its own.

The structural answer costs less than either remedy. Sending domains stay separate from the corporate domain so a listing can never reach the mail that matters. One purpose per domain, so outbound cannot contaminate transactional mail. Tracking domains are dedicated rather than shared. Links in the body point at domains you own. The rest of that architecture is in email domain reputation and the wider cold email deliverability guide.

A report that names SpamRATS is answered the same way, list by list, and the SpamRATS blacklist page decodes which of its four lists fired before anything is filed.

The short version

SURBL checks the domains linked in a message body, never the sending IP, the envelope sender or the HELO hostname. Six datasets sit behind the name, and CT, the click-tracker list, is the one an outbound programme hits, because its criterion is senders mailing "mailboxes without confirmed opt-in".

A lookup is an A record query on the domain prepended to multi.surbl.org. No record means not listed, 127.0.0.1 means the query was blocked, and any other answer's last octet, 4 for DM through 128 for CR, names the dataset and therefore the cause.

Removal starts at SURBL's Lookup page and only applies to a domain you own. For everything else the fix is removing the name from the message: a full link in place of a shortener, a dedicated tracking domain in place of a shared one, then a resend to the part of the audience that was never attempted.

If you would rather run on infrastructure where tracking domains are dedicated and every link in the body points at a domain you control, we plan the first campaign for free.

Dataset descriptions, the multi bitmask values, the lookup mechanics, the usage limits and the removal route are taken from SURBL's own lists page, implementation guidelines, usage policy and FAQ. Verify current list behaviour with the operator before relying on it.