ivmSIP and ivmSIP/24: Which One Listed Your IP

Somebody searches for ivmSIP after finding it on a blocklist report, and almost every page that comes back is about a different list. The results describe ivmSIP/24, the removal instructions describe ivmSIP/24, and even MXToolbox's problem page filed under the ivmSIP name opens with a sentence about the /24 list. The two are not the same object, they get listed for different reasons, and one of them is not about anything you did.

Sorting out which one you are on is the entire job, and it takes one lookup.

Who runs the lists

invaluement is a commercial anti-spam data provider that publishes three DNS lists rather than one. Its own site describes the set as "1 URI DNSBL & 2 IP DNS lists", and its about section says the lists launched in 2007 out of a business that had shifted from web hosting into spam filtering three years earlier. The subscriber base it describes is mail administrators buying an add-on for a filter they already run, which matters for the weighting question at the end of this page.

The three lists are ivmURI, ivmSIP and ivmSIP/24. Only the last two can list a sending address, and they are the pair the search results conflate.

What each of the two IP lists actually lists

The operator's descriptions are worth reading side by side, because they describe two different events.

ivmSIP is about an individual address. In invaluement's words it is "an anti-spam list consisting of IP addresses which either only send spam or which emit an extremely high percentage of spam", and the population it names is "botnets, very elusive snowshoe spammers, or irresponsible ESPs", plus short-term listings of otherwise legitimate low-volume senders whose systems have been compromised. A listing here is a statement about the address, and by extension about whoever is sending from it.

ivmSIP/24 is about a neighbourhood. The operator describes it as "an anti-spam list which preemptively lists" the ranges and subnets of spammers, "where patterns of spam-sending from those blocks have been detected". The word doing the work is preemptively. A range can be listed on the strength of patterns observed at other addresses inside it, before the address you happen to hold has sent anything at all. The operator claims restraint here, saying the list "does a great job of NOT listing those nearby IP ranges which are owned by innocent bystanders", and that claim is the operator's rather than an independent finding.

ivmSIPA single address

• Lists addresses that only send spam or emit an extremely high percentage of it
• Names botnets, snowshoe operations and irresponsible senders as the population
• Short term listings for compromised systems that are otherwise legitimate
• A statement about the address, and about whoever sends from it
• The address holder can act on the cause

ivmSIP/24A range around it

• Lists ranges and subnets preemptively, on patterns detected in the block
• Can list a range before the specific address inside it has sent anything
• Aimed at snowshoe operations spread thinly across a block
• A statement about the block, which usually belongs to a hosting provider
• The address holder often cannot act on the cause at all

The practical difference is who can fix it. An ivmSIP listing names something happening at your address. An ivmSIP/24 listing frequently names something happening at somebody else's, inside a range your provider allocated.

Finding out which one you are on

Start at the operator, not at an aggregator. invaluement publishes a fast lookup for research and a separate delist-request path, and its navigation labels them separately, with the lookup carrying a note that it does no delisting. The lookup is where you get an answer that is current rather than cached, and it is the only place that distinguishes the two lists cleanly.

MXToolbox publishes problem pages for both under separate names, and reading them together shows the conflation in the open. The page filed as the ivmSIP problem opens by saying that a listing "indicates that your IP address has been identified as a spam-sending server", and the page filed as ivmSIP24 opens with the same sentence extended: a listing indicates the address "has been identified as a spam-sending server or is in a range of IP addresses of a host-provider that includes spam-sending servers". Both pages were read on 2 September 2026. A reader who lands on the first page and stops there will treat a range listing as an accusation about their own sending.

Whose address to check is a separate question from which list is involved, and it is the one people get wrong most often. If mail leaves through Google Workspace, Microsoft 365 or any relay, the connecting address belongs to the provider. The rule that settles it is to check the address quoted inside the rejection message rather than the one your browser reports, and whose IP a blocklist lookup is checking works through why those are usually different addresses.

Removal, and what the operator publishes about it

invaluement runs a delist-request path and links to it from the top of every page, labelled for delisting an IP or a domain name. It is a form rather than an address to negotiate with, and it is separate from the research lookup by design.

One honest limitation belongs in this section. The delist page returned HTTP 403 to a scripted fetch on 2 September 2026, on both a plain request and a headless browser render, so what that form asks for is left out here. What the operator's readable pages establish is that the route exists and where it starts. Search results carry specific turnaround figures for invaluement removal requests; none of those figures appears on a page that could be fetched, so none of them is repeated here.

The sequence that actually matters is the same one every list operator states in some form, and it is worth doing in order.

1. Step 1Read the rejection

   Take the address quoted inside the refusal rather than the one a browser reports

2. Step 2Look it up at the operator

   invaluement's own lookup distinguishes ivmSIP from ivmSIP/24, which an aggregated row does not

3. Step 3Decide whose event it is

   An address listing is yours to fix, a range listing usually belongs to the provider who allocated the block

4. Step 4Fix the cause first

   A removal granted before the cause is gone buys days and costs credibility on the next request

5. Step 5File only for what is yours

   A request for a range you do not own has to come from whoever does

What it means for a cold outbound programme

Three readings, in descending order of how often they apply.

You send through a provider, and the address is not yours. This is the common case, and it makes an ivmSIP/24 row an observation about your provider's estate on the day you asked. There is no request for you to file and no configuration on your side that changes it. What it does justify is asking whether the sending infrastructure is worth the price, because a block full of spam-sending neighbours is a block your mail leaves from every day.

You run your own outbound infrastructure and the range is listed. Then the lever is the provider relationship rather than the list. The operator's description of the /24 list points at patterns across a block, so the party who can change the pattern is whoever allocated it. The realistic ask is a different range, not an appeal.

Your own address is listed on ivmSIP. Then the description is pointed at you, and the causes the operator names are worth checking honestly: a compromised account sending mail nobody on the team wrote, an unverified list producing a bounce spike, or volume that stepped rather than ramped. The diagnosis before any delisting request covers the order to work through, and the list-quality half of it sits in what verification actually removes.

Weight the row honestly either way. invaluement sells its data to mail administrators as a supplement to a filter they already run, so the receivers consulting it are the ones who bought it. That is a real population and a narrower one than the lists the large mailbox providers use, and the honest test is whether any rejection string you have ever received names the zone. A row nobody has ever bounced you for has probably never cost a send, and the same weighting logic applies to the Suomispam reputation lists.

The structural answer costs less than any of the remedies. Outbound leaves on sending domains kept away from the corporate estate, one purpose per domain, and enough spare warmed capacity that a bad address is swapped rather than argued over. That posture is set out in email domain reputation, and it is what turns a range listing you cannot influence into a routing decision you can.

The short version

invaluement publishes three lists and the search results merge two of them. ivmSIP lists individual addresses that send only spam or an extremely high proportion of it. ivmSIP/24 lists ranges preemptively on patterns detected across a block, which means it can name a range before your address inside it has sent anything.

MXToolbox files them as separate problem pages whose descriptions overlap, so the aggregated row alone will not tell you which event you are looking at. The operator's own lookup will.

Removal starts at invaluement's delist page, which the site links from every page. That page refused a scripted fetch on the day this was written, so what the form asks for and how long it takes are left out, along with the turnaround figures circulating in search results.

For a team sending through a provider, an ivmSIP/24 row is usually a statement about the provider's address space rather than about the campaign, and the useful response is a decision about infrastructure rather than a delisting request.

If you would rather send from infrastructure where the address space is chosen rather than inherited, we plan the first campaign for free.

The list descriptions, the three-list structure and the delisting route are taken from invaluement.com's own pages, fetched 2 September 2026. The two problem-page descriptions are taken from MXToolbox's ivmSIP and ivmSIP24 pages, fetched the same day. The operator's delist page returned HTTP 403 to both a plain and a headless fetch, so no claim here rests on it. Verify current list behaviour with the operator before relying on it.