Programmable RevenueBuilder Edition Subscribe
Issue 01 The Mechanism Field

SURBL checks your links, not your sender: why we removed every link from cold email

SURBL evaluates the domains inside the message body, not the sending domain. One listed link affects every message carrying it. So we removed links from cold email, and each sending domain now serves its own page.

Thomas Cornelius August 22, 2026 8 min read
Technical schematic: a pipeline from message body through link extraction to a multi.surbl.org DNS query returning 127.0.0.64 = listed.
The check runs on what the message links to, not who sent it.

The confusing part of the incident was that domains with clean records were still getting filtered. The sending domain was fine. The mail was not.

The explanation sits in how SURBL works, and it changed how we write every cold message. This is the mechanism in full, because once you see it, half the deliverability folklore you have heard starts making sense.

How a URI blocklist actually works

Most people picture a blocklist as a list of bad senders. SURBL is not that. It is a list of domains found inside message content. Its documented input is the URIs in the body of an email, not the sending domain and not the sending IP.

The mechanics matter. When a message arrives, the receiving side extracts every URI from the body and takes the domain from each one. Checking a domain is a DNS query: append the list’s zone to the domain and look it up. An answer in 127.0.0.x means listed; the specific value encodes which of SURBL’s internal lists matched. No answer means not listed. The whole check costs the receiver one DNS round trip per domain.

message body extract URIs, take the domain query as DNS name: answer: html + text parts track.vendor.com.multi.surbl.org 127.0.0.64 no answer (NXDOMAIN) = not listed, message unaffected 127.0.0.x = listed; the bits say which SURBL sublist matched, and every message carrying the domain inherits the verdict
One DNS round trip per linked domain. The sender is never part of the query.

A blocklist is a public lookup table that mail servers consult mid-delivery, the way a bouncer checks a name against a list at the door. The twist with SURBL: the name being checked is not the sender’s. It is the name of every website linked inside the message. Your email can be vouched for perfectly and still get bounced for the company it links to.

Play it forward

Three messages leave three different sending domains, all with clean reputations. All three carry the same link in the body, a tracking host, a redirect, a link back to the main site. If that linked domain is listed, all three messages are affected. The reputation of the sender never enters into it.

from: domain 1 from: domain 2 from: domain 3 reputation: clean reputation: clean reputation: clean same link in body this is what gets checked if it is listed, all three messages are hit
The linked domain carries the risk. Sender reputation never enters into it.

Which means a shared tracking host or a shared redirect target is one attribute stamped across your entire fleet. One listing, every message, whatever the senders’ reputations look like.

The tracking host you forgot you had

Here is where builders coming from marketing or sales should slow down, because this part is about a feature you probably rely on.

Click tracking works by rewriting links. You write yoursite.com/pricing; the platform swaps in track.vendor.com/abc123, which records the click and then redirects the reader onward. That rewritten hostname is what actually appears in the message body, and on most platforms it is the same hostname for every customer, in every message, across the whole vendor.

If you have ever noticed that the links in your outbound tool’s emails do not match the address you typed, that is click tracking. The convenience is real. The cost is that your messages now carry a stranger’s domain in their body, and its reputation travels with every email you send.

So the exposure is double. Your fleet shares one linked domain internally, and that domain may also be shared with every other customer of your tooling. When it gets listed, the listing does not care whose campaign caused it.

What we changed

We removed links from cold email entirely. Each sending domain now serves its own landing page directly, no redirect and no masking proxy back to a main site, so no shared tracking host and no shared redirect target appears in message content anywhere in the fleet. Where tracking is needed, each sending domain uses its own tracking subdomain rather than one hostname shared across the fleet, and every hop after a click belongs to the domain that sent the message.

A SURBL listing also began to matter more than it used to. We cannot see what Google and Microsoft feed into their filtering, but listings started correlating with inbox placement in a way they had not before. Removing links from cold email changed our results.

The one URL that stays

One URL remains in every cold message: opt out of future emails. It sits beside a line saying the message was intended for that named recipient.

The engineering behind that link is worth copying even if you copy nothing else. Every message carries a token signed for that single recipient, so opting out needs no login, no lookup, and no confirmation page. One click removes them. We process opt-outs within two hours, and they apply across every rail we run, not only the one that sent the message.

Taking the exit away is worse than carrying it, because the alternative a reader reaches for is the spam button, and a complaint costs far more than an opt-out. A complaint is a signal to the receiving provider about your sending identity. An opt-out is a row in your own suppression table. You want the second one every time.

Check it for yourself

Take any message your system sent, as a raw .eml file, and look at what a receiver sees inside it.

# Every hostname that appears inside the message body
grep -Eo 'https?://[^/"[:space:]]+' message.eml | sort -u
#   https://track.vendor.com
#   https://yoursite.com

# Check each LINKED domain against SURBL, not the sender
dig trackingdomain.com.multi.surbl.org +short
#   (no answer)  = not listed
#   127.0.0.64   = listed

If the first command returns a hostname that also appears in every other message your fleet sends, that hostname is a shared attribute, and its reputation is your reputation. If it belongs to your vendor, so is every other customer’s.

Who this applies to

Any outbound that routes clicks through a shared tracking host, which is most sending tools in their default configuration. It does not argue against links everywhere: our newsletter rail keeps content links, served through each domain’s own subdomain, because a consented list on isolated infrastructure carries a different risk. The rule both rails share is that every URL in a message points at the domain that sent it.

Still open

We removed the links and results improved, but we cannot see inside Google’s or Microsoft’s filtering, so we cannot prove which share of the improvement the links explain. And whether content links could safely return to cold email behind fully isolated per-domain tracking is a test we have not run, because the downside risk lands on domains that take weeks to warm.

The principle

The message body is part of your sending identity. Receivers treat it that way, so we build that way. If you audit nothing else this week, list every hostname that appears inside your outbound messages and ask how many other senders share it.

Build with graph8