ivmSIP and ivmSIP/24: Which One Listed Your IP

Somebody finds ivmSIP on a blocklist report and goes looking for what it means. invaluement, the company behind it, publishes two IP lists with nearly the same name, ivmSIP and ivmSIP/24, which MXToolbox files as ivmSIP24, and the descriptions in circulation blur them. 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 starts with the address quoted in the rejection.

What is ivmSIP?

ivmSIP is one of three DNS blocklists sold by invaluement, a commercial anti-spam data provider. It lists single IP addresses that, in the operator's words, "either only send spam or which emit an extremely high percentage of spam". Its sibling ivmSIP/24 lists whole ranges, and ivmURI lists domains found in the links inside messages.

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.

Access is by subscription. The how-it-works page says a subscriber pastes "a particular host name (that we will assign you)" into the spam filter, the free-trial form says "Anonymous access to our data is NEVER allowed", and the price is calculated from the number of mailboxes the subscriber protects. A receiver that consults these lists has signed up and paid to.

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.

ivmSIP vs ivmSIP/24 (ivmSIP24): what each list lists

ivmSIP/24, written ivmSIP24 on MXToolbox, is invaluement's range list. It lists spammers' IP ranges or subnets preemptively, "where patterns of spam-sending from those blocks have been detected", so a /24 row can name a block before your own address in it has sent anything. ivmSIP lists the single address.

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.

The name refers to a /24, the block of 256 addresses that share their first three numbers; invaluement's own description says ranges or subnets.

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.

What is ivmURI?

ivmURI is invaluement's third list, and the only one that reads links. The operator calls it an anti-spam URI dnsbl "similar to surbl.org and uribl.com": it lists domain names, and a few IPs, found in the clickable links in the body of spam. It cannot name your sending IP, and it can name a domain your message links to.

invaluement adds that most of the domains on it are owned by spammers, with rare cases of a normally innocent domain hijacked by criminal spammers. The mechanics match SURBL's, where the linked domain is judged and the sending server is not, which is set out in what the SURBL blacklist checks.

Finding out which one you are on

Start at the operator. invaluement publishes a fast lookup for research and a separate delist-request path, and its navigation labels them separately, with the lookup marked "faster, but no delists". The lookup page refused every scripted fetch, a plain request with HTTP 403 and a headless browser with a challenge page, so what it displays is not described here.

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". 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.

ivmSIP delist: what the operator publishes about removal

An ivmSIP delist starts at invaluement's Delist Requests page, which the site's menu labels "delist your ip or domain name" and keeps apart from Fast Lookups. Fix the cause first, then file only for an address you hold: a listing on the /24 list usually names a block your provider allocated, and a request for a range you do not own has to come from whoever does.

invaluement links the delist-request path from the top of every page, and it is separate from the research lookup by design.

One honest limitation belongs in this section. The delist page refuses scripted fetches, a plain request with HTTP 403 and a headless browser with a challenge page, 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. None of invaluement's readable pages states a turnaround time, so none is given here.

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

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.

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.

Your situation	Whose event	Useful response
You send through a provider and the address is not yours	The provider's estate	Ask whether the infrastructure is worth the price
You run your own infrastructure and the range is listed	Whoever allocated the block	Ask the provider for a different range
Your own address is listed on ivmSIP	Yours	Check for a compromised account, an unverified list or a volume step

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 refuses scripted fetches, so what the form asks for and how long it takes are left out.

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, the access terms and the delisting route are taken from invaluement.com's own pages. The two problem-page descriptions are taken from MXToolbox's ivmSIP and ivmSIP24 pages. The operator's delist and lookup pages refuse both plain and headless fetches, so no claim here rests on them. Verify current list behaviour with the operator before relying on it.

Sources: invaluement, MXToolbox ivmSIP, MXToolbox ivmSIP24