Net Shaker

Written by: Tim Davis Created: 03 August 2026

Category: Net Shaker

New!Hits: 50Reading time: 05:24

The short version: A client's brand-new server couldn't send a single email — because the IP address his hosting company assigned to it was already on a spam blacklist, burned by whoever had it before him. He inherited someone else's bad reputation on day one.

Read the full technical breakdown ↓

Here's what happened. A client of ours had his website moved to a brand-new virtual server at one of the big-name hosting companies. New hardware, new control panel, new IP address — a fresh start. Then his email stopped arriving. Every message he sent came back with a bounce notice. Gmail rejected him. Outlook rejected him. He couldn't even reply to his own support ticket at the hosting company, because those replies bounced too.

At first glance this looks like a settings problem — something wrong with DNS, or a password, or a mail app. It wasn't. Everything on his end was set up correctly, and incoming mail worked perfectly the whole time.

The real problem was the IP address itself. Every server on the internet has one, and mail providers like Google and Microsoft keep long memories about how each address has behaved. This one had a history. Before it was assigned to our client's shiny new server, it had belonged to someone else — someone who used it to send spam. The blacklists that protect your inbox don't block people, they block addresses. So when the hosting company recycled that address and handed it to our client, the block came with it. His server had sent only a handful of legitimate emails in its entire life. Didn't matter. The address was burned before he ever touched it.

Why the hosting company couldn't see it

This is the part worth sitting with. Big hosting companies are built to handle the common cases at enormous scale — and at that, they're genuinely good. But their support systems run on checklists: is DNS right, is the password right, is the account in good standing? Our client's situation passed every item on the checklist, so the ticket went in circles. Nobody on the front line was positioned to say, "the address we assigned you was already blacklisted when we assigned it" — even though the company itself had created the problem. A unique situation, caused by the host, was invisible to the host's own support process.

What we did about it

We audited the server's entire sending history to prove the block wasn't earned — a few dozen legitimate emails, all from the client's own office, zero spam, ever. That evidence turned a round-in-circles ticket into a specific, provable request: the address you issued was blacklisted before assignment; provide a clean one, verified against the blacklists before it goes live, along with the handful of settings that give a mail server a proper identity. We gave the client that script in plain language, ready to hand to his host.

One honest note about hosting in general. Clients who host with Cybersalt sometimes pay more than the big-name price. What they get for the difference showed up in this story twice: when something unusual breaks, they talk to someone who will actually dig into it — and more often, things don't get to the breaking point at all, because we're keeping an eye on the servers our clients live on. Most of our clients contact support less than they used to, not because they've learned to live with problems, but because we usually see the problem first.

The technical breakdown

The rest of this post is for fellow IT and security folks who want the receipts. If you came for the summary, you're done — thanks for reading.

Discovery

The client reported that outbound mail from every mailbox on his domain was bouncing. The NDRs told the story immediately — two different providers, two different mechanisms, same target:

550 5.7.1 ... [the server's IP] blocked using Spamhaus

That's Microsoft, rejecting at connection time on a public DNSBL. Gmail's rejection came after the DATA phase and cited its own internal reputation system:

... [the server's IP] ... an unusual rate of unsolicited mail ... has been blocked

Meanwhile inbound mail flowed flawlessly. That single fact eliminated half the usual suspects: the DNS zone, MX records, and the domain itself were fine. Receivers weren't rejecting the domain — they were rejecting the connecting IP.

Findings

The server's lifetime sending history exonerated it completely. The mail logs covered the machine since the day it was provisioned. Total authenticated outbound submissions, ever: a few dozen. Every one originated from the client's own office IP. No foreign-IP logins, no spam bursts in any rotated log. A server with that history cannot have earned "an unusual rate of unsolicited mail" — the reputation predated the tenant. The host had issued a recycled IP that was already listed on Spamhaus ZEN.

The reverse DNS was still the provider's generic pool name. The PTR record identified the IP as anonymous pool inventory rather than a branded mail host — a small trust penalty on its own, and a tell that the address had been sitting in a recycled pool.

A verification gotcha that cost us a wrong answer: the server's own resolver pointed at Google Public DNS — and Spamhaus refuses queries arriving via public resolvers, returning empty answers that look exactly like "not listed." Our first check wrongly cleared the ZEN listing because of this. Ground truth came from the receivers' own rejection messages and a web-based lookup. Two lessons in one: check DNSBLs from a path Spamhaus will actually answer, and note that a mail server resolving through public DNS is also quietly degrading its own inbound spam filtering, since SpamAssassin's DNSBL checks hit the same wall.

One IP wearing every hat. The VPS had exactly one IPv4 address, serving the website, the control panel, both nameservers, and outbound mail. No spare IPs, no per-domain outbound override configured. Web reputation, DNS, and mail reputation all fused to a single burned address — nothing to fail over to.

A side finding worth its own paragraph: the SPF record was one upstream change away from breaking. The record inherited from the host's boilerplate chained through the provider's include tree and hit exactly 10 DNS lookups — the RFC 7208 hard ceiling. If the provider added one more include upstream, the record would silently become PermError for every receiver. The replacement we recommended does the same authorization in 2 lookups, and stops authorizing the host's entire shared infrastructure to send as the client's domain:

v=spf1 ip4:<the server's mail IP> a mx ~all

Remediation

An IP-level block can't be fixed with DNS settings — SPF, DKIM, and DMARC help a reputation recover, but they can't lift a blacklist entry on an address that earned it under a previous owner. The leverage is with the host, so the remediation took the form of a specific, evidence-backed request list:

1. A clean replacement IP for mail — verified against the DNSBLs before acceptance. Recycled pool IPs carry prior history; that's how this one got burned. Never accept an assigned IP without checking it first.
2. PTR set to a branded hostname matching the mail server's HELO — no generic pool names.
3. SPF and DKIM re-established against the new IP, plus a DMARC record (starting at p=none for monitoring).
4. The Gmail unblock/escalation form for the address, backed by the lifetime-log evidence.

Structurally, the better long-term shape is a dedicated mail IP separate from the web/DNS IP, so a future website issue and the mail reputation can never take each other down. Where a host won't provide a clean IP, an authenticated smarthost relay is the durable fallback.

Lessons filed away

• Brand-new ≠ clean history. A freshly provisioned server can inherit a burned IP. Check any newly-assigned address against the major DNSBLs on day one, before pointing production mail at it.
• Inbound working + outbound bouncing = look at the connecting IP, not the zone file.
• Read the actual bounce messages. Both providers named the mechanism precisely; the NDRs were the fastest diagnostic in the whole engagement.
• Never trust a DNSBL "not listed" answer that came through a public resolver. Spamhaus returns silence, and silence looks like innocence.

← Back to the plain-English summary

Interesting blog? Like it on Facebook, Post it or share this article on other bookmarking websites.