When your neighbours get your IP blacklisted
An IP blacklist does not know your name. A listing attaches to an address — sometimes to a whole range of addresses — and every mail server that consults the list judges whoever currently sends from that address by its recorded past. If you hold the address exclusively and behave, that is fair enough. But much of the internet sends from addresses it merely rents or shares: a shared hosting account, a cloud instance with a recycled public IP, an office behind a carrier NAT pool. In those setups you inherit the address’s history and share its present, and a stranger’s spam run can become your delivery problem overnight. This article explains how neighbour and inherited listings happen, how to tell them apart from a listing you earned yourself, and what actually works when one lands on you. Start by running the Blacklist Checker on the address you send from, and note the listing dates it reports — dates are the whole story here.
The listing belongs to the address, not to you
DNS blacklists are keyed by IP address because that is the one thing a receiving server can verify during the SMTP conversation: the connecting address is a fact of the TCP handshake, not something the sender can forge in a header. The standards that describe these lists, RFC 5782 and RFC 6471, are written entirely in terms of addresses and ranges — there is no field for “but the tenant changed last Tuesday”. A receiving server that trusts the list therefore treats the address’s accumulated record as your record, whoever you happen to be.
And it is not always a single address. When abuse from a range persists, list operators escalate: one address becomes a /24, and occasionally a much wider block, precisely to pressure the network owner into dealing with the tenants causing it. Spamhaus’s SBL, for example, lists ranges used by spam operations and can widen a listing when the operator responsible will not act. That escalation is deliberate collateral pressure — the list is leaning on the landlord because the tenant will not listen. If your address sits inside such a range, your mail is collateral too, and nothing about your own behaviour caused it or can cure it directly.
The previous tenant: inheriting a dirty address
Cloud addresses are recycled fast. An instance is terminated in the morning, its public IP returns to the pool at noon, and by evening it is attached to your brand-new mail server — carrying whatever the last holder earned: open listings, a burned reputation at the big mailbox providers, and sometimes a place on internal blocklists that no public lookup will ever show you. The public listings at least expire or can be removed; the private reputation data held by large receivers simply decays with time, and you cannot appeal to a system that does not publish itself.
So check the address before you build on it, not after the bounces start. Run the Blacklist Checker, look at the address’s reverse DNS and what is publicly known of its history, and send test mail to the major mailbox providers before you migrate anything real. If the address arrives dirty, the cheapest fix is at the very start: release it and request another, or ask the provider for a clean replacement, before DNS records, SPF includes and customer configurations have cemented you to it. Swapping after a month of warm-up wastes the month; swapping on day one costs minutes.
If you keep the address, treat its past as a documented fact rather than a mystery. Save the listing evidence with its dates — most inherited listings predate your tenancy, and that gap is your strongest asset in every conversation that follows, with your provider and with list operators alike. Then set the basics the previous tenant may have neglected: a meaningful PTR record that forward-confirms, working SPF, DKIM and DMARC for your domain, and a sensible HELO name. None of that removes you from a list by itself, but it separates “new tenant doing things properly” from “same operation, new name” — which is exactly the distinction reviewers look for.
The current neighbours: sharing an address today
Inheritance is a one-off event; a shared address is a standing exposure. On classic shared hosting, dozens or hundreds of unrelated sites send through the host’s mail IP, and one compromised neighbour — a hijacked web form, a phished mailbox — can list the address for everyone on it. The same shape appears at larger scale: the shared sending pools of email service providers, where your campaigns leave alongside strangers’, and carrier-grade NAT pools, through which whole districts of broadband customers appear as a handful of public addresses. In each case the listed behaviour is real. It just is not yours.
The symptoms differ from a listing you earned, and that is how you recognise them. Delivery degrades in waves that match nothing you sent; bounces cite volumes or timestamps from when your server was quiet; the stated reason describes content you have never produced. You cannot fix a neighbour’s compromise, and you cannot win delisting on the strength of your own innocence while abuse continues from two doors down — the address will simply be listed again. The actor who can change things is whoever controls the address: the host, the ESP, the carrier. Your levers are evidence, escalation and ultimately exit — a ticket carrying the exact listing references and your own clean sending logs, a request to be moved to a different address or pool, and a willingness to leave if the pool keeps burning. A deliverability check such as the Email Deliverability Check helps separate what your domain controls from the address-level reputation you merely borrow.
Dedicated or shared: the honest trade-off
A dedicated sending IP buys control at the price of sole responsibility. Everything it does is yours, good and bad, and nobody else can burn it — but it also starts cold, and reputation systems reward a steady, recognisable history. A low-volume or irregular sender on a dedicated address may never accumulate enough good history to outweigh one bad week, and will often deliver worse than it did from a pool. Dedicated addresses earn their keep at sustained, consistent volume, where your own history is deep enough to be an asset and a neighbour’s behaviour is a genuine risk to it.
A reputable shared pool is the opposite bargain: borrowed reputation, shared risk. Good providers police their pools aggressively — throttling or ejecting abusive senders fast, spreading customers across many addresses, watching list status continuously — because the pool’s reputation is their product. For most small and mid-size senders, that borrowed reputation is a real advantage, and neighbour risk becomes the provider’s full-time job rather than your hobby. The failure mode to avoid is the worst of both worlds: a cheap, unpoliced pool where nobody is watching at all. Whichever you choose, choose it as a decision about who manages address reputation — you, or a provider whose business depends on it — not as a default you fell into.
When it lands on you: the playbook
First, prove the shape of the problem. Compare the listing date and its evidence window against the date the address was assigned to you and what your own logs show. If the listing predates your tenancy, or cites traffic your logs prove you never sent, you have an inherited or neighbour case, and paperwork is the fix: allocation or assignment records from your provider, invoices or instance-creation timestamps, the date your PTR record changed. Providers and list operators both respond far better to “this address was assigned to us on the 14th; the listing cites the 3rd” than to any volume of protest.
Second, work both exits at once. Ask your provider to move you to a clean address or a different pool — for inherited listings this is usually the fastest resolution that exists, and competent providers do it routinely, because they know their pools recycle addresses. In parallel, file the removal request with your evidence attached; the step-by-step of the delisting process itself is covered in how to get off a DNS blacklist. And while you wait, route the mail that cannot afford to bounce — password resets, invoices, alerts — through a reputable relay, so the business is not held hostage to an address dispute.
Third, make it a monitored condition rather than a surprise. Check every address you send from on a schedule, and check any new address before it carries production mail, exactly as you would check a domain before buying it. Keep the tenancy paperwork: the day you can prove when an address became yours is the day an inherited listing shrinks from a week of downtime into an afternoon of emails. An IP address is rented land. Keep the lease, watch the neighbourhood, and do not be the only tenant surprised by the street’s reputation.