SURBL blacklist check: why clean domains still get filtered

A SURBL blacklist check tells you whether a domain has been seen inside spam messages. SURBL is a URI blocklist, which means it indexes the domains that appear within an email rather than the domain the email was sent from. So the usual sequence goes: check the sending domain, get a clean result, conclude nothing is wrong, keep landing in spam. The listed domain was the tracking link.

That gap between what people check and what filters look up is the whole subject of this post.

What a SURBL blacklist check is actually looking at

SURBL describes its own dataset as something you use to "filter or tag unsolicited messages based on links in the message body, regardless of sender IP addresses." Read that second half again. Sender identity is explicitly not the input.

This is a different job from the lists most cold email content talks about. Here is the split:

The middle row is why the two get conflated. The DBL is deliberately dual purpose, so a DBL check on your sending domain is a meaningful check. SURBL is not built that way. A domain lands on SURBL because it showed up inside mail that people did not ask for, which for most cold email setups is never the From domain.

A separate nuance that trips people up: what a filter feeds into a lookup is its own decision. Rspamd, for example, can run the email addresses found in the body, the DKIM signing domain and the extracted URLs against the same zone in one query. So your sending domain can absolutely be queried against SURBL. It just is not the kind of domain that gets added to it.

If the Spamhaus half of that table is unfamiliar, the SBL, XBL and PBL explainer covers which of those lists are yours to fix.

The domain nobody checks is usually the tracking domain

Open a cold email you send and count the domains a receiving filter can extract from it. The From domain. The tracking domain behind the open pixel. The tracking domain behind every rewritten link. The domain of whatever you actually linked to, which for cold email is usually a calendar booking page or a landing page. Sometimes a shortener on top of that. Sometimes an unsubscribe host that belongs to the platform.

Six domains is normal. People check one.

SURBL is unusually direct about this category. It runs a Click Tracker list specifically for domains used to track clicks in email from senders without confirmed opt-in. Not a side effect, not an accident of classification. A published list for exactly the thing every cold email platform installs by default.

Now the honest version of what that listing does, because this is where a lot of writing on the subject overreaches. Rspamd ships default weights for each SURBL sublist. They are public:

A click tracker listing scores zero by default. On its own it is a label, not a punishment. The Abuse list at 5.0 is the one that moves a verdict. Spamhaus DBL's spam category sits at 6.5 in the same file for comparison.

So the useful conclusion is not "a CT listing kills you." It is that the domains inside your message are being independently evaluated, on lists that were designed with tracking infrastructure in mind, while you were looking somewhere else. If your tracking domain is your platform's shared default, you also inherited whatever every other customer on it has been doing. That trade is worth reading in full in should you turn off open tracking.

A blocklist answer has three outcomes, not two

The second thing that makes SURBL checks unreliable in practice: people treat the answer as a boolean.

Blocklists answer over DNS. A listed domain resolves to a 127.x.x.x address whose last octets encode which sublist matched. Not listed returns NXDOMAIN. So far so binary. The problem is that refusals are encoded the same way, with no two lists agreeing on the codes.

SURBL states it plainly: "If you get a result of 127.0.0.1 when doing a DNS query into the public nameservers, then it means your access is blocked." Spamhaus uses 127.0.1.255 for a prohibited query on the DBL and the 127.255.255.x range for a blocked one, typically an unauthorised public or datacenter resolver.

A checker that tests for startsWith("127.") reads every one of those as a listing.

You do not have to take my word for how much this matters. Rspamd carries dedicated zero weight symbols for it: SURBL_BLOCKED for "query blocked by policy/overusage", URIBL_BLOCKED for "query refused", DBL_BLOCKED_OPENRESOLVER for "you are querying Spamhaus from an open resolver". Production mail filters model "I was refused" as its own state because reading it as either answer is wrong.

This is not a rare edge case for a web tool. Public blocklist zones commonly refuse datacenter resolvers, which is precisely where a hosted checker runs. A green result from a VPS can mean the zone never answered.

There is a 60 second way to find out whether any checker is telling you anything. Both lists publish permanent test entries, so query them from the same network the checker uses:

nslookup test.surbl.org.multi.surbl.org
nslookup dbltest.com.dbl.spamhaus.org

The first should come back with a 127.0.0.x listing bit. Getting 127.0.0.1 means SURBL is refusing you. The second should return 127.0.1.2. Getting 127.255.255.x means Spamhaus is refusing you. If a list will not confirm its own permanently listed test domain, nothing else it told you counts.

Our free Spamhaus blacklist checker reads every refusal code as "could not check" rather than as clean or listed, for this reason.

The same listing hurts very differently depending on who you email

This is the part that explains why two agencies with identical listings report completely different damage.

SpamAssassin and Rspamd weight URI blocklist hits heavily. Both add a URI hit into a numeric total that decides the verdict. Rspamd's shipped weight for a SURBL Abuse listing is 5.0, rising to 7.5 for phishing or malware, against thresholds administrators usually set in the single digits. A URI listing can be most of a spam verdict by itself.

Gmail and Microsoft do not work that way. Neither publishes which third party blocklists it consults. Google's guidance for senders is about your own reputation with Gmail. Gmail's rejection strings say so directly, refusing mail on "very low reputation of the sending domain" with no list named anywhere. Google also has its own view of malicious links through Safe Browsing, which is not SURBL.

The practical read:

• Selling into small and mid sized companies, agencies, hosting providers, anyone self hosting mail? Your prospects sit behind SpamAssassin and Rspamd. A URI listing is close to fatal there.
• Selling into a Gmail and Outlook heavy list? A listing is a symptom of something the big providers are probably also unhappy about, but it is not the mechanism blocking you. Fixing only the listing will not move your numbers.

Either way, delisting is not the same as recovery. The full sequence for a listed domain covers why the numbers stay flat for weeks after the listing clears.

Listings are not permanent, so a check has a short shelf life

Blocklist listings decay. Most are automated, expiring once the activity behind them stops. That cuts both ways.

In one small batch of a dozen flagged domains that we re-checked several weeks later, nine were still listed and three had cleared on their own. Small sample, no claim about the general rate. The point it makes is the one that matters: a clean check is a snapshot, as is a dirty one. A check from three weeks ago is not evidence about today, in either direction.

Two behaviours follow from that. Do not retire a domain on the strength of a single lookup, because some listings clear without you doing anything. Do not file a removal request while the cause is still running, because the domain will earn the listing back and the second request is reviewed against the first.

How to run a URI blocklist check properly

1. Inventory the domains in one real message. Send yourself a live campaign email, view the source, list every domain in it: From, tracking pixel host, rewritten link host, destination domain, calendar link, shortener, unsubscribe host.
2. Check each one, not just the sending domain. Against Spamhaus DBL and SURBL at minimum. Most of the time the sending domain is the least interesting entry on the list.
3. Verify the resolver first. Run the two test point lookups above from the same network. If a zone will not answer, its verdict is unknown rather than clean.
4. Treat refusal codes as unknown. 127.0.0.1 from SURBL and 127.0.1.255 or 127.255.255.x from Spamhaus are not listings.
5. Re-check on a cadence, not on panic. Weekly beats a frantic lookup the morning after reply rates fall off a cliff.
6. Stop the cause before requesting removal. A dirty list, a spam trap hit, or a shared tracking domain you never replaced.

The free deliverability checker runs the blacklist lookups alongside SPF, DKIM, DMARC, MX and domain age in one pass, which is worth doing together because authentication gaps and listings tend to arrive as a pair.

Where this quietly goes wrong at agency scale

One operator with one domain can hold all of this in their head. The failure mode is structural rather than technical.

An agency running fifteen client workspaces has a sending domain inventory in the dozens, plus a linked domain inventory that is larger still, because every client links to their own site, their own calendar, their own landing pages. Nobody audits that second list. It is not that the check is hard. It is that the check has no owner, so the domain that gets a client filtered is usually one that never appeared on anyone's list of things to watch.

ColdOps tracks blacklist status and deliverability signals across every sending domain in your Instantly, Smartlead, EmailBison and Apollo workspaces, so a listing shows up as an alert rather than as a client asking why the replies stopped.

Start with the diagnosis though. Pull up one real campaign email, list every domain inside it, then run them through the free Spamhaus blacklist checker. The one that comes back dirty is rarely the one you would have checked.