Count the payload. The report lists thirteen fields, and three of them are verdicts: phishing, suspicious, and the score [4]. Ten are observations. Seven of the ten point away from risk: spam false, malware false, DNS valid, SPF enabled, DMARC enabled, parked false, hosted content false [13]. That matches what the owner says he configured [3]. The three fields left over are an empty category, a domain rank of 0, and risky TLD true [4]. Two of those three say only that the service holds no history for this name, which is the expected reading a couple of months after registration [1].
Nothing in the payload names the artifact behind phishing true. The author walks through indicators he would expect to see attached to that verdict, including a cloned login page, a credential collection form, a malicious redirect chain and a third-party blacklist match, and reports that the public result identifies none of them [12].
Then the doc language. IPQS describes the URL risk score as an estimate of confidence in malicious URL detection and marks 85 and above as high risk, likely poor reputation or malicious [5]. The 95 clears that line by ten points [14]. Confidence in a detection is not the same quantity as probability of maliciousness, and the author flags the gap himself: IPQS calls it a confidence score and keeps the formula proprietary [11].
The integration detail is what makes this more than one person's grievance. IPQS publishes examples that flag a URL when phishing is true, when malware is true, or when the score is above 85 [7], and it positions domain reputation for screening during signups, transactions and email submissions [8]. A vendor threshold living in vendor sample code is the threshold most integrations keep.
Treat the 95 the way you would treat someone else's benchmark table. For it to transfer into your gate, the composite has to be reconstructible from fields you can show the rejected user, because eventually someone will ask. The correction loop has to close inside your onboarding window; here, roughly a month produced no explanation, no evidence, no verification request and no ticket update, with the status unchanged as of August 29, 2026 [10]. And the share of your legitimate signups arriving on young names has to be small enough that you can afford to lose them.
Practically, split the payload. The observation fields are measurements of the domain. The composite folds in priors you cannot inspect [11]. Block on measurements, route a high composite to a review queue with a published turnaround, and keep the score out of any path that returns a hard rejection. That is a larger change than editing a threshold constant, because the gate now needs a human on the other end of it.
The ten-year registration term, incidentally, is the one thing the buyer paid for that the report has no field for [15].
IPQS does not appear in the post in its own words [10], and one self-reported case gives you no false positive rate. What it gives you is a pattern to check against your own logs: every observation field clean, and a number ten points past the vendor's documented high-risk line. If you cannot say which field moved that number, the rejection page carries your logo and someone else's prior.
