ivmURI Blacklist: The Domain List Behind the Links You Send

A blocklist report shows ivmURI against a domain, and the report is filed under the sending domain's name, so the first move is to check the sending server. That is the wrong object. ivmURI is invaluement's domain list, and the operator's own page says it is built from what appears inside the clickable links in the body of a message. The listed name is whichever domain a receiver's filter pulled out of a link, and in a cold email that is as likely to be a tracking host, a booking page or a case-study site as the domain the message came from.

This page follows the operator's pages through the list: what ivmURI lists and keys on, who queries it, the listing causes the operator states, how a lookup and a removal request are separated, what the operator's removal page could not be read to say, and what a sender changes so the name does not come back. The two invaluement lists that DO list sending addresses, ivmSIP and ivmSIP/24, are a different object with a different remedy, and they are worked through in ivmSIP and ivmSIP/24.

What ivmURI lists and keys on

invaluement publishes three lists, and its home page, fetched on 19 September 2026, titles the set "invaluement anti-spam lists, 1 URI DNSBL & 2 IP DNS lists". The URI list is the one this page is about, and the operator's own definition is precise about the object. The list, it says, is an anti-spam URI dnsbl, "similar to surbl.org and uribl.com." It continues that, unlike an RBL, and sometimes called a domain dnsbl, "it actually lists both domain names and a few IPs, which are all found within the clickable links in the body of spams".

That sentence carries the whole mechanism. The list is keyed on names found inside the body of a message, which means a listing is a statement about a link, not about a connection. Your sending IP, your envelope sender and your HELO hostname are tested by the operator's other two lists and by every sender-side list on the report; ivmURI is not looking at them. The comparable list the operator names, SURBL, works the same way and is taken apart in the SURBL page, which is the shape this page follows.

MXToolbox files the list under its RHSBL problem pages rather than its IP blocklist pages, and its description matches the operator's. On the page read on 19 September 2026: "Listing in the Invaluement URI list (a domain blacklist) indicates that your domain has been found within the clickable links in the body of unsolicited emails by the Invaluement team." The phrase that matters is "found within the clickable links". Which of your domains that was is the entire diagnosis, and the report does not say.

Who queries it

ivmURI is a commercial list, and that shapes who sees a listing. Access is by subscription, in two forms the operator's sign-up page describes: direct DNS queries against a hostname the operator assigns, or rsync of rbldnsd-formatted zone files for larger installations. The how-it-works page, fetched on 19 September 2026, describes the direct route: the subscriber copies a host name the operator assigns, and then, in the page's words, "paste that into a form field in your spam filter, hit 'save', and start enjoying better spam filtering." The sign-up page draws the line between the two routes at mailbox count: "Direct Query access is more economical for those with FEWER than 5,000 mailboxes." and "RSYNC access to rbldnsd-formatted files is more economical for those with MORE than 5,000 mailboxes."

Two consequences follow for a sender. The first is that the querying population is the population that pays for it: mail administrators and filter vendors who bought the data as an add-on to a filter they already run, plus the categories the sign-up page names as unusual users, among them "responsible ESP using the data to vet new customers and/or shut down outbound spam, to protect their IP reputation." and lookup forms of the kind MXToolbox runs. The second is that the query hostname is private. HetrixTools, a monitoring service, explains on its RBL page (published 26 January 2017, read on 19 September 2026) why it hides it: "Because this is a private/paid RBL, we cannot make their query hostnames public." You cannot query the zone yourself the way you can query a public list; you read the row on a checker that licenses the data, or you use the operator's own lookup.

The operator also says plainly that nobody gets the data without identifying themselves: "Anonymous access to our data is NEVER allowed." That is a statement about subscribers, and it is why third-party pages describe the list at one remove.

Why a domain gets listed

The operator states the population it lists and the exception it makes. Domains found in spam links, its home page says, "are generally not seen in legitimate e-mails, except for rare instances when a normally-innocent domain has been hijacked by criminal spammers." And then, of the listed names, the page says most "are actually owned by spammers."

So two listing causes exist in the operator's own account. The first is that the domain belongs to a spammer, which for a legitimate programme means a shared name you do not own: a link shortener, a shared tracking host on a sending platform, or a third-party site your copy pointed at, whose other traffic put it on the list. The second is the hijacked domain, an innocent site broken into and used to host spam links, which can be your own landing page or a partner's without anybody having noticed.

The operator also explains why a domain list exists alongside its IP lists, and the explanation is the most useful sentence on the page for anybody who sends from a large provider: "Also, much spam is sent from the MTAs of very large ISPs/hosters and, therefore, cannot be blocked with a senders-IP list without causing massive FPs." followed by the claim that many of those spams "can be safely blocked with" the URI list instead. A receiver that cannot afford to block a large provider's shared addresses blocks on the links instead. That is why a cold email sent from a well-known provider's infrastructure can be filtered on a domain in its body when nothing about its sending address is wrong. The message below is invented, to show which names a list of this kind can read out of an ordinary cold email; nothing in it was sent to anyone.

Looking it up, and the removal path

The operator separates research from removal, and it does so on purpose. Its lookup page, fetched on 19 September 2026, is a chooser with two doors: Delist Requests, described on the page as delist your ip or domain name, and Fast Lookups, described as "faster lookups, no delists". The research lookup is where you get a current answer for a name; the delist door is where a request starts.

How the query itself works, for anybody reading a raw response, is on the how-it-works page. A DNS anti-spam list is queried by appending the name to the list's zone, and then, in the operator's words, "that anti-spam list either returns an NXDOMAIN value (domain not found), or, if the particular domain or IP is in fact listed, then it 'resolves' that DNS query to an IP, typically 127.0.0.2, or some variation of that." A not-found answer is a clean result; a loopback answer is a listing.

One honest limitation belongs here. The operator's delist page and its research page both returned HTTP 403 to a scripted fetch on 19 September 2026, on a plain request and on a headless browser render alike, behind a challenge page. What the removal form asks for, and what happens after it is submitted, therefore comes from no first-hand read of the operator's page and is not stated here as fact. Two third parties describe it, and their descriptions are reported as theirs. HetrixTools' RBL page says the procedure is to "input your domain or hostname in their delisting form" after which "you will receive delisting instructions on the following page, which involve you sending them an email with custom subject and body requirements". GlockApps' tutorial (published 20 October 2020, modified 13 August 2025, read on 19 September 2026) says "InvaluementURI reviews requests manually and does not require any fees." and that a request requires an email with a specific subject line and an explanation of the listing. Neither statement has been checked against the operator's form, and a reader should treat them as a description of the door, not the room behind it.

What the operator's readable pages do establish is the order. Look the name up on the research door first, because the aggregated row does not say which domain in your message was read. Then decide whose name it is, because a request for a shortener or a scheduling vendor's domain has to come from whoever owns it. Only then does the delist door apply, and only for a name you control.

What a sender changes so it does not recur

The remedy for a domain list is structural, and it is cheaper than any removal request. Every link in a cold email is a domain a receiver can read, the LinkedIn profile in the signature included, and every shared domain carries the aggregate behaviour of everybody else who uses it. The operator's own listing logic, spammer-owned names plus hijacked innocent names, tells you what to change.

Tracking domains are dedicated, never shared. A click-tracking host that every customer of a sending platform uses is exactly the shared object the operator's list describes, and one customer sending to a bad list is enough to put it there. A dedicated tracking domain converts a reputation you cannot influence into one you can, and it is a platform setting rather than a campaign change.

Links point at domains you own, on a domain that is not the corporate one. A shortener is a shared name with no reputation you control, so a full link on your own domain replaces it. Sending domains stay separate from the corporate domain, so a listing on an outbound name can never reach the mail the business runs on, and one purpose per domain keeps transactional mail out of the blast radius. The architecture is in email domain reputation.

The hijacked case is a security task before it is a deliverability one. A landing page that has been broken into hosts somebody else's links, and cleaning it is what removes the cause; a request filed before that is a request that will be granted and then reversed. The same is true of a partner's site your copy linked to, except that the cleaning is theirs to do, and the honest fix on your side is to stop linking to it until it is done.

Weight the row by who consults it. ivmURI is queried by subscribers who bought it, which the operator's own access rules make plain, and by the checkers that license it. That is a real population and a narrower one than the lists the large mailbox providers consult. The test that settles how much a row matters is whether any rejection string or filter header you have received has ever named the list; if none has, the row is a name to fix in the message rather than an emergency. The order to work a mixed report in, and the sender-side lists whose delisting paths are worth learning, are in email blacklist check and recovery.

The short version

ivmURI is invaluement's domain list, described by the operator as a URI dnsbl similar to SURBL and URIBL that lists domain names and a few IPs found within the clickable links in the body of spam. It does not test the sending address, the envelope sender or the headers; those belong to ivmSIP, ivmSIP/24 and the sender-side lists.

It is queried by paying subscribers over an assigned hostname or by rsync, and by checkers that license it; the query hostname is private and anonymous access is never allowed, so a sender reads the row on a checker or on the operator's own research lookup. A listing means a name inside the message was read as a spam link: most listed domains are spammer-owned in the operator's account, the rest are innocent domains that were hijacked, and a shared tracking host or shortener can be either.

The operator separates fast lookups from delist requests on its lookup chooser. Its delist page refused both a plain and a headless fetch on the day this was written, so what the form asks for is reported only as two third parties describe it and not as fact. The fix that does not depend on the form is removing the listed name from the message: a dedicated tracking domain, full links on a domain you own, a cleaned page, no third-party links until they are safe.

If you would rather run on infrastructure where tracking domains are dedicated and a listed name is replaced before it costs a campaign, we plan the first campaign for free.

The list definition, the listing population, the access methods, the anonymous-access rule, the lookup chooser and the query mechanism are taken from invaluement.com's home, how-it-works, lookup and subscribe pages, fetched 19 September 2026. The operator's delist and research pages returned HTTP 403 to a plain fetch and to a headless render the same day, so no claim here rests on them; the two third-party descriptions of the removal form are from HetrixTools' RBL page and GlockApps' tutorial, read the same day and attributed as theirs. MXToolbox's description is from its RHSBL ivmURI problem page, read the same day. Verify current list behaviour with the operator before relying on it.

Sources: invaluement, invaluement how it works, invaluement lookup chooser, invaluement subscribe, MXToolbox RHSBL ivmURI, HetrixTools on ivmURI, GlockApps on delisting from ivmURI