The Shared Redirect Problem

01 The answer

Where a domain points predicts its blacklist status almost perfectly. Nothing else does.

The raw correlation "domains with mailboxes are 60.7% listed versus 30.3% without" is pure confounding. Deployed domains happened to sit on the bad hosts. The effect disappears completely inside every server group.

Which blocklist fires also depends on the host. 52.15.49.97 produces SURBL listings only, while the Vultr addresses drive Spamhaus DBL at 77 to 98 percent. DBL is the one that actually damages inbox placement.

02 The smoking gun

Two purchase batches accidentally ran a controlled experiment for us.

Ten domains, one three-second window, opposite outcomes

On 14 July 2026 we bought ten domains between 07:18:07 and 07:18:10. One registrar, one account, all .pro, same naming style. Six landed on one forwarding server, four on another.

Same name, same second, different server

From the 7 January batch, the same base names were bought in the same second across different TLDs and split across servers:

This single comparison eliminates purchase timing, batch size, registrar, account, name pattern, TLD, age, and client, all at once.

03 What we ruled out

Every theory we walked in with, tested against our own fleet.

04 Which layer is actually the problem

Not the registrar's parking, and not the nameservers. It is step five.

Email and web are two independent paths on the same domain. MX handles mail, the A record handles web visitors. Everyone in cold email watches the first path because that is where sending reputation lives. The blocklists were reacting to the second.

SURBL is specifically a URL blacklist. Its job is scanning links found in spam and clustering by where they lead. A server hosting hundreds of freshly registered lookalike domains is exactly the fingerprint it hunts. Our domains get caught in that net without sending anything.

The forwarding server drives SURBL

Holding the DNS account constant at pns61-64, the forwarding server decides SURBL entirely:

But the DNS account drives Spamhaus DBL, and that is worse

An earlier draft of this report concluded "it is not the nameservers." That was wrong, and the error is worth naming: the comparison above holds the DNS account constant, so it could only ever test SURBL. 52.15.49.97 happens to carry zero DBL, which hid the second mechanism entirely. Splitting the fleet by ClouDNS account instead:

Inside the bad account, the forwarding server makes almost no difference to DBL. Even domains with no website at all are listed:

05 Who is affected right now

426 domains sit on poisoned servers. 276 of them are actively sending client campaigns today.

06 Fixing the live clients

Ordered by urgency. Steps A and B need no purchases and can start today.

07 What is still worth testing

Most of the original test matrix is now answered and should not be paid for.

Drop these arms

• Registrar comparison (A/B/C). Answered. Registrar is not the variable.
• Bulk versus single purchase. Answered, and the correlation runs mildly backwards.
• Redirect destination arms (D1/D2/D3). Answered. Destination brand is irrelevant.
• Name pattern arm (F). No support anywhere in the data.

Keep these

• E1 versus E2, the factory test. Now the entire point of spending money. Buy two matched sets, point one at factory landing pages and leave the other on the provider default, then watch both for 21 days. This is the only arm that tests something we cannot already answer.
• A dark control. A handful of domains bought and left with no DNS at all. This settles the one genuine ambiguity below.
• A resurrection arm. Take matched groups of currently listed domains from retired clients only, never live ones. Group one: repoint to own landing page. Group two: remove DNS entirely. Group three: leave untouched as control. This measures whether delisting actually follows a fix, which is what step D above depends on.

The one real ambiguity

Of the 320 domains that resolve to nothing at all, those with mailboxes are 57.2% listed and those without are 1.6%. We cannot see DNS history, so we cannot tell whether they were listed while previously parked on a poisoned server and then taken dark. This is the one place a sending effect could still be hiding, and the dark control arm is what resolves it.

08 Monitoring

The audit that produced this report should become a standing job, not a one-off.

The tooling already exists and ran end to end for this report. Turning it into monitoring means scheduling it and keeping history.

What to record, per domain, daily

• Blocklist status with the specific list name, separating real reputation listings (SURBL, Spamhaus DBL) from age-based auto-listings that expire on their own (SEM-FRESH, Spamhaus ZRD). Conflating these inflates the numbers badly.
• Current A record and nameservers, so a domain silently moving onto a poisoned server is caught the same day.
• Mailbox count, warmup state and emails sent, joined from the inbox provider.
• Registrar, purchase date and owning account.

What to alert on

• Any domain whose nameservers change to pns71-74, or whose A record changes to a known-poisoned address. Both are simple set membership checks and together they are the highest value alerts we can build.
• Any new IP appearing across our fleet that we have not classified yet, with its running listing rate.
• Any client whose listed percentage moves more than a few points week over week.
• First Spamhaus DBL hit on any domain, separately from SURBL, since DBL is materially more damaging.

The comparison that makes it useful

Keep two scoreboards, not one: a DNS account scoreboard tracking DBL rate per ClouDNS account, and an IP scoreboard tracking SURBL rate per forwarding address. Splitting them is what exposed the second mechanism; a single blended "listed %" hides it. For every address and account our domains touch, record the running count of domains on it and the percentage listed on each blocklist separately. That table is what turned a year of confusing anecdotes into this report, and it is the thing to watch permanently. A server flipping from clean to dirty is the early warning that matters.

09 Caveats and open questions

What this report does not establish.

• This is observational, not randomised. Every theory was killed by a real contrast inside our own fleet, which is strong evidence, but nothing here was a designed experiment. The factory test is what converts it to proof.
• Coverage may be partial. The audit used one Porkbun account and one Dynadot account, with no Spaceship access at all. If the account pool is larger than that, some of the fleet is missing from these numbers.
• We cannot see listing dates or DNS history. We only observe current status, so we cannot say when a domain was listed or what it pointed at previously. Historical DNS would sharpen the no-A-record question considerably.
• 207.207.210.x behaves differently from every other host: 0 of 55 listed without mailboxes, but 21 of 46 with. It is the one address where deployment clearly matters, and we do not yet know why.
• What decides server assignment is unknown. Within a single three-second purchase, some domains went to a clean host and some to a poisoned one. Until we know what drives that, we cannot prevent it, only detect and correct it.