IPQS False Positives: How a New Domain Got a 95 Risk Score

Pred Gray — Sat, 29 Aug 2026 18:14:03 +0000

A little over two months ago, I registered a new domain for personal use.

The idea was simple. I wanted a permanent, professional email address based on my last name, something like first@lastname.me. I registered the domain for ten years because I wasn’t building a disposable project, launching a marketing funnel, or testing some short-lived startup idea. I wanted an email identity I could keep for the long haul.

I configured the domain properly. It has valid DNS. SPF is enabled. DMARC is enabled. It isn’t parked for sale. It isn’t sending spam. It isn’t distributing malware. It isn’t impersonating a bank, crypto exchange, social network, government agency, or anyone else.

Then I checked it with IPQualityScore, also known as IPQS.

The result was absurd:

Phishing: true
Suspicious: true
Risk score: 95
Spamming: false
Malware: false
SPF enabled: true
DMARC enabled: true
DNS valid: true
Parked domain: false
Hosted content: false
Category: N/A
Domain rank: 0
Risky TLD: true

In other words, IPQS acknowledged that the domain had valid DNS and email authentication, found no spam, found no malware, found no hosted content, assigned it no content category, and still labeled it as phishing with a risk score of 95 out of 100.

I submitted a correction request about a month ago.

I received no explanation. No evidence. No request for verification. No ticket update. No human response. As of August 29, 2026, the status is still unchanged.

That isn’t a harmless technical oddity.

IPQualityScore sells reputation and fraud-risk data that businesses can use to block users, reject signups, review transactions, investigate security alerts, and decide whether a domain, email address, IP address, phone number, or device should be trusted.

If you’re going to sell suspicion as a service, you need to be accountable when your suspicion is wrong.

IPQS, in my case, has been neither accurate nor accountable.

A score of 95 is not a gentle warning

IPQualityScore’s documentation describes its URL risk score as an estimate of confidence in malicious URL detection. It says scores of 85 or higher represent high risk and that these domains are likely to have a poor reputation or be malicious. Its phishing field indicates that a URL is associated with malicious phishing behavior.¹

That matters because a score of 95 is not presented as “we don’t know enough about this domain yet.”

It is presented as a very strong finding.

To be precise, a score of 95 does not necessarily mean there is a mathematically valid 95 percent probability that a domain is malicious. IPQS calls it a confidence score, and its internal formula is proprietary. But an ordinary user, security analyst, fraud team, or automated system will naturally read 95 as nearly certain danger.

IPQS provides examples showing how customers can flag a URL when phishing is true, malware is true, or the risk score is above 85. The company also says organizations can use its domain reputation products to screen domains during signups, transactions, and email submissions.²

These are not decorative numbers.

They are designed to influence decisions.

A “phishing: true” result paired with a risk score of 95 can become a rejected signup, a blocked message, a security alert, a denied registration, a failed transaction, or a demand for additional verification.

IPQualityScore may argue that its customer makes the final decision. Technically, that is true. But IPQS sells the signal with the expectation that customers will act on it.

It cannot take credit when its data prevents fraud and then pretend to be a passive bystander when the same data harms an innocent user.

The IPQS report contradicts itself

The individual findings in my report make the final verdict even harder to defend.

It says there is no malware.

It says there is no spam.

It says the domain is not parked.

It says there is no hosted content.

It says DNS is valid.

It confirms SPF and DMARC.

It has no content category.

It has no traffic rank.

Then, somehow, the IPQualityScore system jumps to “phishing: true” and a risk score of 95.

What was the actual phishing indicator?

Was there a cloned login page?

A credential collection form?

A fake brand?

A suspicious JavaScript payload?

A phishing email linked to the domain?

A malicious redirect chain?

A complaint from an IPQS customer?

A match against a third-party blacklist?

A machine-learning pattern based on the domain name?

An association inherited from shared infrastructure?

The public result doesn’t say.

That is the heart of the problem. IPQS presents a highly specific and potentially damaging conclusion while hiding the evidence behind it.

When a system says “insufficient reputation,” that is a reasonable description of a new domain.

When it says “phishing: true,” that is an allegation of malicious behavior.

Those are not remotely the same thing.

One means there isn’t enough information. The other claims that the domain is connected to an actual form of cybercrime.

IPQualityScore should not blur that distinction just because its scoring model finds uncertainty inconvenient.

Apparently, `.me` is a “risky TLD”

The IPQS result also marked the .me extension itself as risky.

IPQualityScore defines risky_tld as a signal that a domain belongs to a top-level domain frequently associated with malware, scams, abuse, or phishing. Its public documentation does not explain which TLDs are on that list, what period is measured, what abuse rate triggers the label, how frequently the list changes, or how heavily this factor affects the final risk score.³

I’m not arguing that TLD-level abuse statistics are completely useless.

Security researchers do measure differences in abuse rates among top-level domains. Spamhaus, for example, explains that a TLD can develop a poor reputation because of a high ratio of abusive domains or a large total volume of abuse. It also acknowledges that such measurements involve judgment calls and do not cover the entire domain population.⁴

That is exactly why TLD reputation should be a weak contextual signal, not a shortcut to guilt.

A .me domain is an entirely natural choice for a personal website or personal email address. Treating the extension as categorically risky, without explaining the underlying abuse rate or how that rate influenced a score of 95, is crude profiling.

It amounts to guilt by neighborhood.

A ZIP code may have a higher-than-average fraud rate, but that does not make every resident a fraudster. A phone carrier may have more spam reports, but that does not make every customer suspicious. A hosting company may have abusive customers, but that does not prove every website using its infrastructure is malicious.

Those facts may be useful signals for deciding where to look more carefully. They are not evidence that a particular domain committed fraud.

If .me materially influenced the risk score, IPQualityScore should explain how.

If it did not materially influence the score, displaying “Risky TLD: true” without context seems designed mainly to make the report look more alarming.

New is not the same as malicious

Yes, criminals use newly registered domains.

That is real.

Domain age can be relevant when it is combined with a fake login page, brand impersonation, suspicious scripts, credential harvesting, malicious email activity, or verified abuse reports.

But “new” is not a synonym for “phishing.”

Every legitimate domain was new once.

Every family domain, portfolio, local business, nonprofit, open-source project, personal blog, custom email domain, and startup begins with no traffic rank and no long history of positive behavior.

The absence of reputation is not a negative reputation.

IPQualityScore itself says that not every newly created or unusual site is malicious and that individual signals rarely confirm abuse on their own.⁵

That is sensible language.

The trouble is that the output I received did not say:

This domain is new, unranked, and does not yet have enough history for us to evaluate confidently.

It said:

Phishing: true.

Those are radically different messages.

A low-confidence, unknown, unclassified, or unrated result would have been fair. A warning that the domain lacked sufficient history would have been understandable.

A phishing label with a score of 95 was not.

If IPQS has direct evidence of phishing, it should identify the type and date of that evidence.

If it only knows that a domain is two months old, has no traffic rank, uses .me, and redirects somewhere, then it does not know that the domain is phishing.

It is guessing.

Worse, it is presenting that guess as a near-certain security verdict.

A normal redirect is not phishing

The IPQualityScore report also marked the domain as redirected.

That may sound ominous to someone who doesn’t work with websites, but redirects are everywhere.

Domains routinely redirect from HTTP to HTTPS, from a root domain to www, from one landing page to another, from an old page to a new one, or from a personal domain to a hosted profile.

Redirects are a basic part of how the web works.

Redirect chains can be part of phishing campaigns, of course. They can hide the final destination or route victims through compromised infrastructure.

But a redirect by itself proves nothing.

IPQS defines the field as indicating whether a URL redirects to another domain. Its documentation does not say that every redirect is inherently malicious.⁶

If the redirect contributed to the score, IPQualityScore should explain what was suspicious about the destination or redirect chain.

Was the destination on a verified threat feed?

Did it contain a fake login page?

Was the redirect obfuscated?

Was it conditional based on browser, device, or location?

Without that context, “Redirected: true” is just a fact about how a website behaves. It is not evidence of phishing.

The Cloudflare IP tells us almost nothing about the owner

The report also displayed a Cloudflare IP address.

Cloudflare explains that proxied hostnames use shared IP ranges. Those addresses are part of its anycast network and may be shared by many unrelated domains. Visitors see a Cloudflare address instead of the origin server’s address.⁷

That means a Cloudflare IP is not a unique identity for the website behind it.

Many unrelated domains can appear on the same infrastructure. Some may be legitimate. Some may be abandoned. Some may be compromised. Some may be malicious.

Their owners do not know one another and do not control one another.

I cannot tell from the public IPQS report whether its scoring system used the displayed Cloudflare IP as a negative factor. IPQualityScore does not provide enough detail to know.

That uncertainty is itself a problem.

If shared infrastructure affected the score, IPQS should explain how it separated the reputation of one hostname from unrelated Cloudflare customers.

If the shared IP did not affect the score, IPQualityScore should explain what did.

A domain reputation system that cannot properly account for CDNs, reverse proxies, shared hosting, and large cloud platforms is not fit for the modern web.

What IPQualityScore actually sells

IPQualityScore is not a small hobby project or an anonymous browser extension.

The company says it has operated since 2011 and serves thousands of businesses. It sells IP reputation, proxy and VPN detection, email validation, phone intelligence, device fingerprinting, bot detection, transaction scoring, malware scanning, and domain and URL reputation services.⁸

According to IPQS, its intelligence comes from sources that include honeypots, blocklists, forensic analysis, machine learning, customer feedback, and data reported through its fraud-prevention network.⁹

Its privacy policy says customers can submit IP addresses, email addresses, phone numbers, device identifiers, URLs, and domains for fraud analysis. It also describes ways data and related metadata may be used to improve fraud-detection systems.¹⁰

That creates a powerful network effect when the system works.

It also creates a serious risk when it doesn’t.

A bad signal can enter a scoring system, affect a customer decision, generate another fraud report, and gain the appearance of confirmation as it circulates through an ecosystem.

I cannot prove that this happened to my domain, and I am not claiming that it did.

I am saying that IPQS’s own description of its feedback-driven network makes correction speed and evidence quality extremely important.

A company operating that kind of system needs an exceptional appeals process.

What I found was silence.

Who uses IPQS?

IPQualityScore publicly displays well-known company logos and publishes customer stories and case studies involving multiple businesses.¹¹

Those relationships matter because they demonstrate the potential reach of IPQS data.

An important caveat is necessary. Public material does not prove that every company associated with IPQS uses the exact domain reputation product that flagged my domain.

Some customers may use IP intelligence, proxy detection, email validation, device fingerprinting, or another product.

It would be irresponsible to claim that every IPQualityScore customer automatically blocks domains based on the same API response.

The broader ecosystem is still significant.

IPQS promotes integrations with security platforms, fraud tools, threat-intelligence systems, and investigation products. Its integrations can place reputation data inside enterprise dashboards and automated workflows.¹²

That means an IPQS score can travel far beyond a free lookup page.

It can enter registration systems, transaction reviews, security alerts, automated playbooks, and analyst investigations.

The person affected by the score may never know that IPQualityScore was involved. They may simply see a generic message saying that registration was denied, an email domain was considered suspicious, a transaction could not be completed, or additional verification was required.

That is why “it’s only a score” is not an acceptable defense.

The score is the product.

Other people report similar false positives

My experience does not appear to be unique.

Reviews and online discussions include complaints from people who say IPQualityScore classified legitimate websites or residential IP addresses as scams, proxies, VPNs, or sources of abusive activity.

Some reviewers say they requested corrections or manual reviews and received no meaningful response.¹³

These reports must be treated carefully.

Online reviews are not laboratory evidence. Anyone can misunderstand a result, omit context, exaggerate, or write while angry. Individual reviews should not automatically be treated as proven technical findings.

Still, patterns matter.

When unrelated people describe inaccurate labels followed by an unresponsive correction process, it stops looking like one strange mistake.

It starts looking like a quality-control problem.

IPQualityScore also receives positive reviews on business software platforms. Paying customers report that the service helps detect bots, fake accounts, abusive proxies, suspicious payments, and other forms of fraud.¹⁴

I do not dismiss those reviews.

IPQS may provide real value to businesses dealing with actual abuse. A product can catch plenty of bad activity and still create unacceptable collateral damage.

The difference between the audiences is worth considering.

Business software reviews often come from paying customers who benefit when IPQS blocks more suspicious activity. Public complaints often come from people who were blocked, scored, or labeled by the system.

One group buys the protection.

The other group absorbs the mistakes.

If IPQS is wrong about my domain, I am not its customer. I am simply an object in its database.

That makes me easy to ignore.

The marketing claims are remarkably confident

IPQualityScore markets itself with extremely strong accuracy claims, including claims about very low false-positive rates and unusually high data accuracy.¹⁵

Those are substantial claims.

I could not find enough public information to independently evaluate them.

I did not find a public benchmark dataset, representative sample description, confusion matrix, detailed ground-truth methodology, or false-positive breakdown by product, domain age, TLD, region, hosting provider, or customer configuration.

Maybe IPQS has that research internally.

If so, it should publish it.

A percentage without a transparent methodology is marketing, not validation.

IPQualityScore’s technical documentation also acknowledges that stricter settings can increase false positives.¹⁶

The company clearly knows false positives happen.

The important questions are how often they happen, how serious they are, how quickly IPQS corrects them, and whether customers are informed after inaccurate data has already been distributed.

Its marketing does not provide useful answers to those questions.

The fine print tells a different story

IPQualityScore’s marketing talks about accuracy and preventing fraud without harming legitimate users.

Its legal terms are much more cautious.

The terms say the service is provided “as is” and disclaim warranties that results will always be accurate, reliable, error-free, or free from defects. The terms also contain limitations of liability and other restrictions.¹⁷

These clauses are common in technology contracts.

Context still matters.

IPQS is not selling a note-taking app or a color picker. It is selling risk judgments that may cause businesses to treat people, domains, email addresses, IP addresses, and devices as fraudulent or malicious.

The marketing asks customers to trust the company’s conclusions.

The legal terms warn them that those conclusions may be wrong.

The product can attach damaging labels to third parties, while the people affected by those labels may have no contractual relationship with IPQualityScore and no meaningful way to challenge the result.

That is not a balanced accountability system.

The support promises don’t match my experience

IPQS provides contact and false-positive reporting options, including a form that appears primarily focused on IP address classifications.¹⁸

That alone reveals a gap.

A company selling domain reputation and malicious URL detection should have a clearly labeled domain and URL appeal process.

The process should provide a case number, confirmation email, review timeline, status page, and final explanation.

I used the available contact channel and reported the false classification.

A month passed.

Nothing happened.

Perhaps my message was lost.

Perhaps domain reviews use a different queue.

Perhaps non-customers receive lower priority.

Perhaps somebody reviewed the domain and decided not to change anything.

I do not know, because nobody responded.

When your system labels someone’s property as phishing, “submit a form and hope” is not an appeals process.

Even a rejection would have been more useful than silence if it included a reason.

Instead, the accusation remains while the person challenging it receives no meaningful response.

Why IPQS customers should care

This is not only a problem for domain owners.

It is also a problem for companies buying IPQualityScore data.

A false positive can prevent a legitimate customer from creating an account. It can delay a valid transaction, block a personal email domain, waste a security analyst’s time, increase support costs, or cause a business to lose a sale without understanding why.

False positives also damage trust in security controls.

If employees repeatedly encounter bad alerts, they may start ignoring them. Teams may create broad allowlists that weaken security. Support agents may develop unofficial workarounds. Customers may move to competitors after being falsely rejected.

False positives can also be difficult to measure.

If a company blocks a thousand events because IPQS called them risky, how does it know how many were actual attackers?

Unless someone investigates a meaningful sample, the vendor’s score can become its own proof.

The system says the users were risky, so blocking them is counted as fraud prevented. The fact that they were blocked is then treated as evidence that the system worked.

That is circular.

A responsible customer should measure appeals, successful manual verifications, customer complaints, reversals, and the number of blocked users later found to be legitimate.

Otherwise, it is not measuring accuracy.

It is only measuring how often IPQS told it to say no.

A risk score should be a clue, not a verdict

IPQualityScore says its customers are responsible for their own decisions and for providing appropriate review where decisions significantly affect users.¹⁹

That is the right principle.

But the product should support that principle.

A responsible reputation system should distinguish among:

Verified malicious activity
Strong evidence of likely malicious activity
Limited or conflicting evidence
Insufficient reputation data

A new personal domain with little public history belongs in the last category unless there is actual evidence of abuse.

Calling it phishing is not cautious.

It is careless.

A useful result would provide high-level reason codes, such as:

Newly registered domain
Limited legitimate traffic history
TLD statistical risk
Redirect detected
Shared hosting or CDN infrastructure
Third-party report received
Brand impersonation detected
Credential form detected
Malicious script detected
Verified phishing-feed match
Classification based primarily on automated heuristics
Classification awaiting human review

Then customers could make informed decisions instead of blindly trusting a single number.

There is a huge difference between a domain that hosted a verified credential-harvesting page yesterday and one that is simply new, unranked, and hosted behind Cloudflare.

An IPQS score should preserve that difference.

In my case, it did not.

“Our algorithm said so” is not evidence

Machine learning can detect patterns that humans miss. Threat feeds can identify attacks faster than manual investigation. Automated risk scoring has a legitimate role in fighting fraud.

But automation does not turn assumptions into facts.

A model can be useful overall while still being wrong about individual cases.

My domain is new. It has limited public history. It has no traffic rank. It uses a TLD that IPQualityScore considers risky. It redirects. It uses shared Cloudflare infrastructure.

Those facts may create uncertainty.

They do not create phishing content.

They do not create a fake login page.

They do not create stolen credentials.

They do not create malicious email.

They do not create victims.

A collection of weak signals does not become direct evidence just because an algorithm combines them into a two-digit number.

If IPQS has stronger evidence, it should identify the category of that evidence.

If it does not, “phishing: true” is an irresponsible label.

What IPQualityScore should change

IPQS does not need to reveal every detection rule or model weight. That would make it easier for criminals to evade detection.

It can protect its methods while still providing a fair process.

At a minimum, IPQualityScore should:

Stop using “phishing: true” when the evidence only shows that a domain is new or unfamiliar.
Create a dedicated domain and URL false-positive form.
Acknowledge every appeal and provide a case number.
Publish a realistic review timeline and meet it.
Provide high-level reason codes.
Disclose whether a result came from live scanning, cached data, customer reports, third-party feeds, heuristics, or machine-learning inference.
Show the date and age of the evidence behind a negative classification.
Explain how risky_tld is calculated and how much it affects the score.
Treat shared CDN and cloud infrastructure carefully.
Publish independently verifiable false-positive measurements for each product.
Notify customers when a previously distributed classification is corrected.
Give domain owners a meaningful escalation path.
Encourage additional verification instead of automatic blocking for new domains.
Reserve the strongest labels for cases supported by direct evidence.
Separate verified abuse from statistical suspicion.
Allow domain owners to prove control through DNS or email verification.
Provide a history showing when a classification was created and reviewed.
Offer “unknown” or “insufficient data” as real outcomes.

None of that would weaken fraud detection.

It would make IPQS more credible.

What I want from IPQS

My request is not complicated.

I want IPQualityScore to review the domain manually.

I want the false phishing label removed.

I want to know which signals produced a risk score of 95.

I want to know whether the .me extension materially increased that score.

I want to know whether the displayed Cloudflare IP played any role.

I want to know whether there was an actual abuse report, blacklist match, scan result, customer complaint, or merely a collection of weak assumptions.

Most importantly, I want IPQS to acknowledge that falsely labeling a domain as phishing can cause real harm.

If IPQualityScore can show verified evidence that my domain hosted phishing content, collected credentials, distributed malicious links, or participated in an abusive campaign, it should identify that evidence.

It does not need to expose its entire detection model.

A date, evidence category, source type, and brief explanation would be enough.

If it cannot provide even that, the label should be removed.

That is how basic accountability works.

Suspicion is easy. Accuracy is hard.

I understand why fraud detection companies are aggressive.

Their customers deal with real attacks. Criminals move quickly, rotate infrastructure, register disposable domains, abuse free services, hide behind proxies, and exploit delays in detection.

The difficulty of the problem does not excuse reckless output.

It is easy to label anything new, private, uncommon, redirected, or low-traffic as suspicious.

It is easy to turn weak correlations into a score that looks scientific.

It is easy to sell fear reduction to businesses that will never meet the innocent users caught by the model.

The hard part is separating “unknown” from “malicious.”

The hard part is admitting uncertainty.

The hard part is responding when the system gets something wrong.

The hard part is correcting bad data before it spreads.

In my case, IPQualityScore failed at those hard parts.

It took a legitimate personal domain with valid DNS, SPF, and DMARC, no detected spam, no detected malware, no hosted content, and no demonstrated abuse, then labeled it as phishing with a risk score of 95.

When I asked for a review, the company ignored me.

A fraud-prevention vendor is allowed to be cautious.

It is not entitled to be careless.

When a company sells reputation scores to the rest of the internet, “our algorithm said so” is not good enough.²⁰

Sources and notes

IPQualityScore, “Malicious URL Scanner API Response Parameters,” accessed August 29, 2026. View source ↩
IPQualityScore, “Malicious URL Scanner API Overview” and “Domain Reputation Test,” accessed August 29, 2026. API overview and domain reputation ↩
IPQualityScore, “Malicious URL Scanner API Response Parameters” and “Email Validation API Response Parameters,” accessed August 29, 2026. URL scanner documentation and email validation documentation ↩
Spamhaus, “The World’s Worst Top Level Domains” and “Reputation Statistics FAQ.” TLD report and statistics FAQ ↩
IPQualityScore, “Domain Reputation Test,” accessed August 29, 2026. View source ↩
IPQualityScore, “Malicious URL Scanner API Response Parameters,” accessed August 29, 2026. View source ↩
Cloudflare, “Cloudflare IP Addresses.” View source ↩
IPQualityScore, “About IPQS” and IPQS homepage, accessed August 29, 2026. About IPQS and IPQS homepage ↩
IPQualityScore, “About IPQS” and “Proxy and VPN Detection.” About IPQS and proxy and VPN detection ↩
IPQualityScore, “Privacy Policy” and “Terms of Service.” Privacy policy and terms of service ↩
IPQualityScore, “Reviews and Testimonials” and published customer case studies. Reviews and testimonials, Bolt case study, Phone.com case study, Toluna case study, and ZinQ Media case study ↩
IPQualityScore, “Fraud Prevention Integrations,” and CrowdStrike Marketplace, “IPQS Fraud, Threat and Risk Scoring.” IPQS integrations and CrowdStrike Marketplace listing ↩
Trustpilot and Reddit user reports. These are anecdotal accounts and should not be treated as independently verified technical findings. Trustpilot reviews, HomeNetworking discussion, Cybersecurity Help discussion, and Tech Support discussion ↩
Capterra and G2 reviews of IPQualityScore. Capterra reviews and G2 reviews ↩
IPQualityScore, “Reviews and Testimonials,” “About IPQS,” and “Account Creation Fraud Detection.” Reviews and testimonials, About IPQS, and account fraud detection ↩
IPQualityScore, “Malicious URL Scanner Advanced Options” and “Proxy Detection API Advanced Options.” URL scanner options and proxy detection options ↩
IPQualityScore, “Terms of Service.” View source ↩
IPQualityScore, “Contact Us” and “Report a False Positive.” Contact page and false-positive form ↩
IPQualityScore, “Privacy Policy” and “Data Processing Agreement.” Privacy policy and data processing agreement ↩
Author’s personal website ↩

DEV Community: Pred Gray