IPQS False Positive: How a Legitimate New Domain Got a 95 Risk Score

Pred Gray — Sun, 30 Aug 2026 03:24:46 GMT

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

The plan was simple. I wanted a permanent email address based on my last name, something like first@lastname.me. I registered the domain for ten years because this was not a disposable project, sketchy marketing funnel, or temporary startup experiment.

It was supposed to be my long-term email identity.

I set everything up correctly:

Valid DNS
SPF enabled
DMARC enabled
No spam
No malware
No hosted phishing page
No impersonation
No credential collection
Not parked for sale

Then I checked the domain with IPQualityScore, better known as IPQS.

This was the result:

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

Read that again.

IPQS confirmed that the domain had valid DNS and email authentication. It found no spam, no malware, no hosted content, and no recognizable content category.

Then it labeled the domain as phishing and assigned it a risk score of 95 out of 100.

I submitted a correction request about a month ago.

I received no evidence, no explanation, no verification request, no ticket update, and no human response. As of August 29, 2026, the classification is still there.

That is not a harmless technical glitch.

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

If you sell suspicion as a service, you need to answer for it when your suspicion is wrong.

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

A Risk Score of 95 Is an Accusation

According to the IPQS malicious URL scanner documentation, scores of 85 or higher represent high risk. IPQS says 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.

A score of 95 is not presented as:

We do not have enough information about this domain.

It is presented as a strong security finding.

To be precise, 95 may not represent a mathematically valid 95 percent probability of malicious activity. IPQS calls it a confidence score, and the formula behind it is proprietary.

That distinction will not matter much to an automated fraud system, a security analyst, or a support employee reviewing a blocked account. They will see phishing: true and a score of 95.

IPQS provides examples showing how customers can flag URLs when phishing is true, malware is true, or the score exceeds 85. It also promotes its products for screening domains during registrations, transactions, and email submissions through its malicious URL scanner API and domain reputation service.

These numbers are not decorative.

They are sold to influence real decisions.

A false phishing: true result can become:

A rejected signup
A blocked personal email address
A failed transaction
A security alert
A denied registration
A demand for additional identity verification
An account suspension
A manual investigation

IPQS may say that its customers make the final decision. Technically, that is true.

But IPQS sells the signal because it expects customers to act on it.

The company cannot take credit when its data blocks fraud, then act like a neutral observer when the same data punishes an innocent user.

The IPQS Report Contradicts Itself

The individual findings make the final verdict look even less credible.

IPQS 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 domain rank.

Then its system somehow jumps to:

Phishing: true
Risk score: 95

What exactly was the phishing evidence?

Was there a cloned login page?

Was there a credential collection form?

Was the domain impersonating a bank, crypto exchange, social network, or government agency?

Was there malicious JavaScript?

Was the domain linked from a phishing email?

Was there an abusive redirect chain?

Did it match a verified threat feed?

Was there a complaint from an IPQS customer?

Did a machine-learning model dislike the domain name?

Did the score inherit bad reputation from shared infrastructure?

The public result does not say.

That is the core problem. IPQS presents a highly specific and potentially damaging conclusion while hiding every meaningful detail behind the score.

“Insufficient reputation” would be a reasonable description of a new domain.

“Phishing: true” is an allegation of malicious behavior.

Those statements are not interchangeable.

One means the system does not know enough. The other claims that the domain is connected to cybercrime.

IPQS should not blur that line just because its scoring model is uncomfortable with uncertainty.

Apparently, `.me` Is a “Risky TLD”

IPQS also marked the .me extension as risky.

Its documentation describes risky_tld as a signal that a domain belongs to a top-level domain frequently associated with malware, scams, abuse, or phishing. That field appears in both the URL scanner documentation and the email validation documentation.

What the documentation does not clearly explain is:

Which TLDs are considered risky
What time period is measured
What abuse rate triggers the label
How frequently the list changes
Whether legitimate registration volume is considered
How much risky_tld affects the final score

TLD-level statistics are not completely useless. Abuse rates can vary among registries and extensions.

Spamhaus discusses this in its report on the world’s worst top-level domains and its reputation statistics FAQ. It also acknowledges that these 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 obvious choice for a personal website or personal email address. Treating the extension as inherently suspicious, without explaining the relevant abuse rate or its effect on the score, is crude profiling.

It is guilt by neighborhood.

A ZIP code can have an above-average fraud rate. That does not make every resident a fraudster.

A phone carrier can have more spam reports. That does not make every customer suspicious.

A hosting company can have abusive customers. That does not make every website on its network malicious.

These signals may justify taking a closer look. They do not prove that a specific domain committed fraud.

If .me materially increased my score, IPQS should explain how.

If it did not, displaying Risky TLD: true without context looks like little more than a way to make the report appear scarier.

New Does Not Mean Malicious

Yes, criminals register new domains.

Nobody disputes that.

Domain age can be useful when combined with real evidence, such as:

Brand impersonation
Fake login pages
Credential harvesting
Suspicious scripts
Malicious email campaigns
Verified abuse reports
Confirmed threat-feed matches

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 little traffic and no established reputation.

The absence of reputation is not negative reputation.

IPQS even says on its domain reputation page that not every newly created or unusual website is malicious and that individual signals rarely prove abuse by themselves.

That sounds reasonable.

The result it gave me was not reasonable.

It did not say:

This domain is new, unranked, and does not have enough history for a confident evaluation.

It said:

Phishing: true.

A new domain should be classified as unknown, unrated, unverified, or lacking sufficient history unless there is actual evidence of abuse.

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

If all it knows is that the domain is new, unranked, uses .me, and redirects somewhere, then it does not know the domain is phishing.

It is guessing.

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

A Normal Redirect Is Not Phishing

IPQS also marked the domain as redirected.

That might sound scary to someone who does not work with websites, but redirects are everywhere.

Websites routinely redirect:

From HTTP to HTTPS
From a root domain to www
From an old URL to a new one
From a personal domain to a hosted profile
From one landing page to another
From a shortened URL to its destination

Redirects are a basic part of the web.

Yes, phishing campaigns can use redirect chains to conceal their 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 in its response parameter documentation. It does not say that every redirect is malicious.

If the redirect increased my score, IPQS should explain what was suspicious about it.

Was the destination on a verified threat feed?

Did the destination contain a fake login page?

Was the redirect obfuscated?

Did it behave differently based on location, browser, or device?

Was it part of a known malicious chain?

Without that context, Redirected: true is just a technical observation.

It is not phishing evidence.

A Cloudflare IP Does Not Identify the Domain Owner

The report also displayed a Cloudflare IP address.

According to Cloudflare’s documentation on Cloudflare IP addresses, proxied hostnames use shared IP ranges. Those IP addresses are part of Cloudflare’s anycast network and can be shared by many unrelated domains.

Visitors see a Cloudflare IP instead of the origin server’s address.

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

Thousands of unrelated domains may use the same infrastructure. Some will be legitimate. Some may be abandoned. Some may be compromised. A few may be malicious.

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

The public IPQS report does not reveal whether the Cloudflare IP affected the score.

That lack of transparency is part of the problem.

If shared infrastructure hurt the domain’s reputation, IPQS should explain how it separated one hostname’s behavior from unrelated Cloudflare customers.

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

Any domain reputation system that cannot properly handle CDNs, reverse proxies, shared hosting, and cloud platforms is not ready for the modern web.

IPQS Is Not a Small Side Project

IPQualityScore is not a random browser extension maintained by one developer.

According to its About IPQS page and homepage, the company has operated since 2011 and serves thousands of businesses.

It sells products for:

IP reputation
Proxy and VPN detection
Email validation
Phone intelligence
Device fingerprinting
Bot detection
Transaction scoring
Malware scanning
Domain reputation
URL reputation

IPQS says its intelligence comes from sources that include honeypots, blocklists, forensic analysis, machine learning, customer feedback, and information reported through its fraud-prevention network. It describes some of these capabilities on its proxy and VPN detection page.

Its privacy policy and terms of service also describe the types of data customers can submit for fraud analysis, including IP addresses, email addresses, phone numbers, device identifiers, URLs, and domains.

That creates a powerful network effect when the data is accurate.

It creates a dangerous feedback loop when it is not.

A bad signal can enter the system, influence a customer decision, generate another fraud report, and then start looking “confirmed” because it has circulated through multiple systems.

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

I am saying that a feedback-driven reputation network makes fast corrections and high-quality evidence absolutely essential.

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

What I got was silence.

The Score Can Travel Far Beyond a Lookup Page

IPQS displays well-known customer logos and publishes reviews and testimonials, along with case studies involving companies such as Bolt, Phone.com, Toluna, and ZinQ Media.

That does not prove every company uses the exact domain reputation product that flagged my domain.

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

Still, the reach of the ecosystem matters.

IPQS promotes fraud-prevention integrations with security platforms and investigation tools. Its product is also listed in the CrowdStrike Marketplace.

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

It can appear inside:

Registration systems
Transaction reviews
Security dashboards
Automated playbooks
Fraud investigations
Account verification workflows
Email screening systems

The affected person may never know that IPQS was involved.

They may only receive a generic message saying their registration was denied, their domain was suspicious, their transaction failed, or additional verification is required.

That is why “it’s only a score” is a weak excuse.

The score is the product.

The Accuracy Claims Need Evidence

IPQualityScore markets itself with strong accuracy claims, including claims about low false-positive rates and high data accuracy. These claims appear across its reviews and testimonials page, About page, and account creation fraud detection page.

Those are major claims.

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

I did not find a public:

Representative benchmark dataset
Confusion matrix
Ground-truth methodology
False-positive breakdown by product
False-positive breakdown by domain age
False-positive breakdown by TLD
False-positive breakdown by region
False-positive breakdown by hosting provider
Independent validation study

Maybe IPQS has that research internally.

If it does, it should publish it.

An accuracy percentage without transparent methodology is marketing, not validation.

IPQS also acknowledges in its documentation that stricter settings can increase false positives. That warning appears in its malicious URL scanner advanced options and proxy detection advanced options.

So the company knows false positives happen.

The real questions are:

How often do they happen?
How serious are they?
How quickly are they corrected?
Are customers notified after a correction?
Does IPQS remove bad data from every system that received it?
Can affected people reach an actual reviewer?

The marketing does not provide useful answers.

The Fine Print Is Much Less Confident

IPQS marketing emphasizes accuracy, fraud prevention, and protecting legitimate users.

Its legal language is considerably less confident.

The IPQS terms of service 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.

That kind of language is common in technology contracts.

Context still matters.

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

The marketing asks customers to trust the conclusions.

The legal terms warn that those conclusions may be wrong.

Meanwhile, the third parties harmed by those mistakes may have no contract with IPQS and no practical way to challenge the result.

That is not accountability.

It is a system where the vendor sells the accusation, the customer acts on it, and the person affected gets stuck trying to prove a negative.

“Submit a Form and Hope” Is Not an Appeals Process

IPQS provides a contact page and a false-positive reporting form.

The false-positive form appears heavily focused on IP address classifications.

That is a strange gap for a company selling domain reputation and malicious URL detection.

A real domain appeal process should include:

A dedicated domain and URL form
A confirmation email
A case number
A clear review timeline
Domain ownership verification
A status page
A final decision
A basic explanation
An escalation option

I used the available channel and reported the false classification.

A month passed.

Nothing happened.

Maybe the request was lost.

Maybe domain reports go into a different queue.

Maybe non-customers receive lower priority.

Maybe someone reviewed it and refused to change the result.

I have no idea because nobody responded.

When your system labels someone’s domain as phishing, “send us a message 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 public while the person challenging it receives no meaningful response.

IPQS Customers Should Care About This Too

This is not just a problem for domain owners.

It is also a problem for companies buying IPQS data.

A false positive can:

Block a legitimate customer
Reject a valid email domain
Delay a real transaction
Waste a security analyst’s time
Increase support costs
Trigger unnecessary identity checks
Cause a business to lose a sale
Push a customer to a competitor

Bad alerts also damage trust in security systems.

When employees repeatedly encounter false positives, they begin ignoring warnings. Teams create broad allowlists. Support agents invent unofficial workarounds. Analysts waste time clearing harmless activity instead of investigating actual threats.

False positives are also easy to hide.

If a company blocks 1,000 users because IPQS marked them as risky, how does it know how many were real attackers?

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

The system says the users were risky, so every blocked user gets counted as fraud prevented. The fact that they were blocked is then presented as evidence that the system worked.

That is circular reasoning.

Responsible customers should measure:

Appeals
Manual verification results
Customer complaints
Reversed decisions
Successful transactions after review
Legitimate users incorrectly blocked
Support tickets caused by automated risk rules

Otherwise, they are not measuring accuracy.

They are only measuring how often IPQS told them to say no.

A Risk Score Should Be a Clue, Not a Verdict

IPQS says in its privacy policy and data processing agreement that customers are responsible for their decisions and should provide appropriate review when those decisions significantly affect users.

That is the right principle.

The product should be designed to support it.

A responsible reputation system should clearly distinguish between:

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 report would include 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 abuse report received
Brand impersonation detected
Credential form detected
Malicious script detected
Verified phishing-feed match
Automated heuristic classification
Human-reviewed classification
Review currently pending

That would let customers make informed decisions instead of blindly trusting a two-digit number.

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

IPQS flattened that difference into the same kind of alarming verdict.

“Our Algorithm Said So” Is Not Evidence

Machine learning can detect patterns humans miss.

Threat feeds can identify attacks faster than manual reviews.

Automated scoring has a legitimate role in fighting fraud.

But automation does not turn assumptions into facts.

A model can be useful overall and still be completely wrong in an individual case.

My domain is new.

It has little public history.

It has no traffic rank.

It uses a TLD that IPQS considers risky.

It redirects.

It uses shared Cloudflare infrastructure.

Those facts may create uncertainty.

They do not create a phishing page.

They do not create stolen credentials.

They do not create malicious email.

They do not create victims.

A pile of weak correlations does not become direct evidence because an algorithm converts it into the number 95.

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

If it does not, phishing: true is not an aggressive security precaution.

It is an irresponsible label.

What IPQualityScore Should Change

IPQS does not need to reveal every model weight, detection rule, or proprietary data source. Doing that could help criminals evade detection.

It can protect its methods without treating innocent domain owners like acceptable collateral damage.

At a minimum, IPQS 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 process.
Acknowledge every appeal and provide a case number.
Publish a realistic review timeline.
Provide high-level reason codes.
State whether a classification came from scanning, cached data, customer reports, third-party feeds, heuristics, or machine learning.
Show the date and age of the evidence.
Explain how risky_tld is calculated.
Disclose how much risky_tld affects the final score.
Handle shared CDN and cloud infrastructure carefully.
Publish independently verifiable false-positive measurements for each product.
Notify customers when a classification is corrected.
Give domain owners a meaningful escalation path.
Recommend 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.
Show when a classification was created, updated, and reviewed.
Offer unknown and insufficient data as legitimate outcomes.

None of this would weaken fraud detection.

It would make the product more credible.

What I Want From IPQS

My request is straightforward.

I want IPQualityScore to manually review the domain.

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 the score.

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

I want to know whether there was:

An actual abuse report
A blacklist match
A scan result
A customer complaint
A threat-feed match
A phishing email
A malicious page
Or just a collection of weak assumptions

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

If IPQS 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 reveal its entire model.

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

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

That is basic accountability.

Suspicion Is Easy. Accuracy Is Hard.

I understand why fraud-detection companies are aggressive.

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

That does not excuse reckless output.

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

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

It is easy to sell fear reduction to companies 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 every one of those hard parts.

It took a legitimate personal domain with valid DNS, SPF, and DMARC. Its own report found no spam, no malware, no hosted content, and no demonstrated abuse.

Then it labeled the domain as phishing with a risk score of 95.

When I asked for a review, IPQS 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.

You can find me and my work on my personal website.

IPQS