URI Blocklists - SURBL and URIBL

Here is the scenario that breaks people’s mental model: your IP is clean, your domain authenticates, your complaint rate is low - and your mail still lands in spam. The cause is often a URI blocklist: a list not of where mail came from, but of the domains inside the message body. URIBL states the principle in one line: it “lists domains that appear in spam, NOT where they were sent from.” If a domain you link to is listed, the message can be filtered no matter how spotless your sending infrastructure is. This page covers the two best-known URI lists - SURBL and URIBL - and the link-shortener and tracking-domain traps that pull you onto reputations you don’t control.

For the sending-IP and sending-domain side, see the Spamhaus blocklists page; for the broader split, see IP vs domain reputation; and for the full catalogue of lists and the query mechanics behind all of them, see the DNSBL directory. For where these inputs sit in a receiver’s filter, see the spam-filtering overview.

The 60-second version

• URI blocklists list domains found in message bodies, independent of the sending IP. SURBL: it filters “based on links in the message body, regardless of sender IP addresses.”
• A clean IP does not save you. One listed link, shortener, or tracking domain can get the whole message filtered.
• They tag, they don’t block. URIBL: “Our lists are intended to be used with antispam software to help TAG emails as spam. We do not BLOCK.” The receiver decides what to do.
• They query the registered domain, not the full URL - URIBL strips host parts before listing.
• Newness and shorteners are risk signals. SURBL tracks freshly delegated domains and abused shortener links as their own datasets.
• Spamhaus’s DBL is the same idea, on the IP-list provider’s side - domain-in-body filtering complements IP filtering.

Why a clean IP still gets filtered

IP-based blocklists catch where mail originates. URI blocklists catch what mail points to. The two are orthogonal by design, and that is exactly why they are effective together. A spam operation can rotate through fresh or hijacked IPs (evading the Spamhaus SBL/CSS/XBL) but it still has to link to the domain it is actually selling or phishing - and that destination domain is reused across the campaign. List the destination and you catch the campaign regardless of origin.

SURBL quantifies the combined effect: “Used together with sender lists, our intelligence datasets have proven to be a highly-effective way to detect 95% of unsolicited messages.” Spamhaus makes the same argument for its DBL: “If you are only filtering email using IP-based data, you are missing a simple, yet highly effective, step to increase your catch rates.”

The uncomfortable corollary for a legitimate sender: you inherit the reputation of every domain you put in your mail - your links, your images’ host, your click-tracking domain, your unsubscribe domain, and any shortener you use. A single listed one taints the message.

How a URI blocklist reads your message

A URI list cannot do anything until a receiver’s filter has pulled candidate domains out of the message and queried them. RFC 5782 describes the two places this happens: an IP-or-domain list can be checked “on every incoming SMTP connection,” but for content-based lists, “the IP(s) to test are usually extracted from ‘Received:’ header fields or URIs in the body of the message,” and “name-based DNSBLs have been used… to check the domains found in URLs in message bodies.” Spamhaus describes the same content-inspection stage for the DBL: it is applied “against domains in headers, body URLs, and contact addresses during content inspection.”

In practice the filter (SpamAssassin, Rspamd, a commercial appliance) does roughly this for every message:

1. Parse the body - both the HTML and plain-text parts - and extract every URL: links, image sources, the unsubscribe URL, anything clickable or fetchable.
2. Reduce each URL to a domain to query. Crucially, the list expects the registered domain, not the full host. URIBL is explicit: “We strip all host parts from URIs before addition,” so links.example.com is generally evaluated as example.com.
3. Query each domain against the list’s zone (domain.list.example -> A record) exactly as RFC 5782 lays out for name-based lists, the domain prepended to the zone rather than a reversed IP.
4. Score or act on a hit. Most receivers feed the result into a scoring system rather than an outright block - the same “score, don’t hard-block” discipline that the DNSBL directory covers - but a high-confidence list (a zero-false-positive zone) may be weighted heavily enough to be decisive.

Two consequences fall out of this. First, the number of domains you expose is part of your risk surface - more linked domains, image hosts, redirectors, and shorteners mean more chances that one of them is listed. Second, because lists strip to the registered domain, a subdomain does not insulate you: if the parent is listed, every *.parent link in your mail is listed too.

SURBL

SURBL has run since 2004: “Since 2004, our SURBL online database has been a trusted source of computer security data.” Its core dataset lists “domains of malicious or abused web sites. It can be used to filter or tag unsolicited messages based on links in the message body, regardless of sender IP addresses.” SURBL positions itself as complementary to IP filtering: “It ideally complements filtering based on known bad sender IPs.”

SURBL’s dataset portfolio shows how much of modern abuse is about new and redirected domains:

Dataset	What it lists	Availability
Multi	Domains of malicious/abused sites found in spam bodies	Public (DNS) + Private (RPZ)
Fresh	Recently delegated domains (newer domains are statistically more likely to be abusive)	Private
HashBL	Hashes of abused cloud providers, sender/reply-to addresses, full URIs, abused shortener links, crypto addresses, phone numbers	Private
Shortener domain list	Known URL-shortener services	Private
Abused shortener URI list	Recently appeared abused shortener URIs	Private
UriQ	API for full-URI queries (for cracked/abused sites that can’t be listed at host level)	Private

Two of these matter directly to legitimate senders. “Fresh” means a domain you registered last week is, by itself, a statistical risk signal - new domains have no reputation and are disproportionately abusive, so plan to age and warm a sending or link domain rather than launching cold. And the shortener datasets mean a public link shortener can carry abuse from other people’s links straight into your message’s evaluation.

URIBL

URIBL (operating since around 2005) is built on the same principle and is explicit about its scope and its limits. On scope: it “lists domains that appear in spam, NOT where they were sent from.” On limits: “Our lists are intended to be used with antispam software to help TAG emails as spam. We do not BLOCK.” URIBL provides scoring data; the email operator makes the final call. (URIBL is matter-of-fact about disputes: if you’re being blocked because you appear on it, “take it up with the person blocking you, not us!”)

URIBL public zones

Zone	What it lists	False-positive risk
black.uribl.com	Domains belonging to/used by spammers, including body-URI domains of UBE/UCE. Goal: zero false positives.	Very low
grey.uribl.com	Domains found in UBE/UCE that may honour opt-out; may include ESPs with no control over subscription methods	Can cause FPs depending on UBE/UCE definition
red.uribl.com	Automated: domains active in mail flow that are being monitored, very young, or using WHOIS privacy	Higher - “use at your own risk”
white.uribl.com	Legitimate domains explicitly excluded from the other lists	N/A
multi.uribl.com	Combined zone; one query returns which list(s) matched	Varies by bit

The multi zone encodes results as a bitmask in the 127.0.0.X answer:

X	Meaning
1	Query blocked (excessive volume)
2	black
4	grey
8	red

Note red.uribl.com: a domain can be flagged purely for being very young or for using WHOIS privacy. Spamhaus’s eBook independently warns against anonymised registration: “Do not use anonymized or unidentifiable WHOIS records. Legitimate businesses should have no reason to hide their online identity.” Two independent sources, the same advice - don’t make a brand-new sending or link domain look like a throwaway.

URIBL lists the registered domain

A critical query detail: URIBL normalises to the registered domain. “Our lists only have the top level domain information. We strip all host parts from URIs before addition, with the exception of a few domain names which tend to be heavily abused.” So links.example.com and track.example.com are generally evaluated as example.com. A subdomain does not isolate you from a listing on the parent - if the registered domain is listed, your subdomained links are too.

URIBL also lists destination IPs - “where the URI in the body is trying to take you,” not the sending IP - queried by reversed IPv4. For testing, the documented points are 2.0.0.127 and test.uribl.com.

Spamhaus DBL: the same idea from the IP-list side

SURBL and URIBL are not the only domain-in-body lists. Spamhaus’s Domain Blocklist (DBL), queried at dbl.spamhaus.org, is “a list of domain names with poor reputation” published in domain-DNSBL format, and it is used the same way - against domains in links, headers, and envelope fields. It is deliberately separate from the IP-based ZEN zone: “Zen is an IP address DNSBL zone… it does not include the DBL,” so a receiver has to query it on its own. (For the IP side, see the Spamhaus blocklists page.)

The DBL is worth understanding because its return codes are public and unusually descriptive - the A value tells the receiver why a domain is listed, in the 127.0.1.0/24 range:

Return code	What the domain is
127.0.1.2	spam domain
127.0.1.4	phish domain
127.0.1.5	malware domain
127.0.1.6	botnet C&C domain
127.0.1.102	abused-legit spam
127.0.1.103	abused/spammed redirector domain
127.0.1.104	abused-legit phish
127.0.1.105	abused-legit malware
127.0.1.106	abused-legit botnet C&C
127.0.1.255	IP query wrongly sent to the DBL (error, not a listing)

Three of these matter to a legitimate sender. The 127.0.1.103 “abused redirector” code exists precisely because shorteners and redirect domains get abused - Spamhaus advises shorteners “don’t string several shorteners/redirectors together” and to check the DBL at URL-creation time. The abused-legit codes (127.0.1.102 and up) are for “hostnames on domains that are legitimate, but are being abused” - usually a compromised CMS - which is the exact scenario where your own clean domain can be listed because someone hijacked a page on it. And the 127.0.1.255 code is a guard rail: the DBL “cannot be used to look up IP addresses,” and an IP query “always returns a positive (listed) return code” of 127.0.1.255, so a filter that wrongly points IP lookups at the DBL will reject everything - a self-inflicted outage, not a real listing.

The DBL also matches at the registered-domain level with wildcards: if example.tld is listed, “all hostnames and subdomains of that domain also return a ‘listed’ result.” Like URIBL’s host-stripping, this means a subdomain inherits the parent’s listing. Spamhaus delisting is always free and listings “expire automatically when listing criteria are no longer met.”

SURBL vs URIBL vs Spamhaus DBL at a glance

Aspect	SURBL	URIBL	Spamhaus DBL
What is listed	Domains of malicious/abused sites in spam bodies	Domains appearing in spam (in body URIs)	Domain names with poor reputation
Query zone	multi.surbl.org	multi.uribl.com	dbl.spamhaus.org
Destination-IP listings	Not the primary focus	Yes - destination IPs in body URIs (reversed IPv4)	No - domains only (IP query returns the 127.0.1.255 error)
Return codes	Bit-encoded in the 127.0.0.X answer	Bit-encoded: 2 black, 4 grey, 8 red	Descriptive in 127.0.1.X: .2 spam, .4 phish, .103 abused redirector
Public free zones	Multi	black, grey, red, white, multi	dbl (single zone)
Private/premium	Fresh, HashBL, Shortener, UriQ	gold, df, black_ns, black_nsip	DQS / RPZ via Spamhaus Technology
Semantics	Tag / score	Tag / score - “we do not block”	Tag / score; receiver decides
FP posture	High precision in Multi	Zero-FP goal on black.uribl.com	Automated + manual review; free auto-expiry
Since	2004	~2005	-

All three are tagging/scoring inputs to a receiver’s filter (commonly SpamAssassin and Rspamd), not standalone block authorities. The receiver’s configuration decides the consequence.

The shortener and tracking-domain trap

This is where well-meaning senders get caught. Two mechanisms:

1. Public link shorteners. A shared shortener domain carries everyone’s links - including spammers’. SURBL maintains a shortener domain list and an abused shortener URI list precisely because shorteners are a common abuse vector. When you wrap your links in a public shortener, you adopt that shortener’s aggregate reputation and the abuse flowing through it.
2. Tracking and link domains. Click-tracking rewrites your links to a tracking domain. If that domain is shared across many senders, or is brand-new, or hides behind WHOIS privacy, it becomes the weak link a URI list flags - and because URIBL strips to the registered domain, a fresh tracking domain that gets abused taints every message using it.

The defensive pattern that follows from the sources: prefer your own, aged, transparently-registered domains for links and tracking over public shorteners or shared throwaway domains, and keep every domain you reference as clean as the one you send from.

What senders should do

URI lists are mostly preventable, because you control the domains in your own mail. Concretely:

• Own your link and tracking domains. Use your own, transparently-registered domains for links, click-tracking, and unsubscribe rather than public shorteners. The SURBL “Fresh” and URIBL “red” datasets both treat brand-new domains as suspect, so age a new link/tracking domain before you rely on it, and avoid WHOIS-privacy on it (URIBL’s red zone flags privacy-registered domains, and Spamhaus’s eBook says outright “do not use anonymized… WHOIS records”).
• Audit every domain in the message, not just the From. Image hosts, redirectors, the unsubscribe domain, and any third-party content all get extracted and queried. Minimise the count and keep each one clean.
• Never chain shorteners or redirectors, and if you run a redirector, check the DBL/SURBL/URIBL at URL-creation time and again as traffic ramps - this is Spamhaus’s own advice to redirector operators, and it is what 127.0.1.103 (“abused redirector”) exists to catch.
• Secure the domains and CMS you link to. The “abused-legit” codes list compromised-but-legitimate hosts; a hijacked page on your own site can list a hostname on your domain. Keep CMS, plugins, and credentials current.
• Check your own domains, then fix the cause. Look your sending and link domains up on each operator’s site (and use the test points - 2.0.0.127/test.uribl.com for URIBL, dbltest.com for the DBL - to confirm your tooling works). If listed, fix the abusive footprint rather than just suppressing it; the trap hits and complaints that get a domain listed trace back to list quality - see suppression and consent.
• Expect tagging, not certainty. These are scoring inputs; a listing raises a message’s spam score at receivers that query the list, and the consequence depends on their configuration. Treat any listing as a signal to act on, weighted by the list’s reach (the DNSBL directory covers which lists carry weight).

Common confusion

• “My IP is clean, so I’m fine.” URI lists ignore your IP entirely. A listed link gets you filtered.
• “A subdomain protects me.” URIBL strips to the registered domain; links.example.com is judged as example.com.
• “These lists block my mail.” They tag/score; the receiver decides. URIBL: “We do not BLOCK.”
• “A short link is harmless.” Public shorteners carry others’ abuse; SURBL lists abused shorteners specifically.
• “A brand-new domain is neutral.” Newness is itself a risk signal - SURBL’s “Fresh” and URIBL’s “red” both treat young domains as suspect.
• “URI lists and Spamhaus are unrelated.” Spamhaus’s DBL is the same domain-in-body concept from the IP-list provider; they are complementary, not competing.

What this means for you, and what Egressif does

URI blocklists make one thing concrete: deliverability is not just about how you send, it’s about what you link to. Every domain in the message - links, tracking, unsubscribe, image hosts - is part of your reputation surface, and a single listed or shady-looking one can sink an otherwise clean send.

Egressif operates owned IP space and keeps the sending side clean, but we treat the content side as part of the same job: we monitor the blocklists - including the domain/URI lists covered here alongside Spamhaus’s DBL - so a listed link or tracking domain surfaces as an alert rather than a mystery placement drop. We favour transparent, aged, properly-registered domains over public shorteners and throwaway tracking domains, because the sources are consistent that newness, shared shorteners, and WHOIS privacy are themselves risk signals. And we handle complaints and suppression so the campaigns that would get a link-domain listed in the first place never build up the abusive footprint these lists are designed to catch.