IPQS Branded My New Domain as Phishing With a 95 Risk Score

A little over two months ago, I registered a new domain for personal use. I wanted a permanent, professional email address based on my last name—something like first@lastname.me.

I registered the domain for ten years. This was not a disposable marketing campaign, a temporary startup test, or a throwaway project. I wanted an email identity I could keep for the long haul.

I configured the domain correctly. It has valid DNS. SPF is enabled. DMARC is enabled. It is not parked for sale. It is not sending spam, distributing malware, impersonating a bank, copying a crypto exchange, or pretending to be a government agency.

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

• PhishingTrue
• SuspiciousTrue
• Risk score95
• SpammingFalse
• MalwareFalse
• SPFEnabled
• DMARCEnabled
• DNSValid
• ParkedFalse
• Hosted contentFalse
• CategoryN/A
• Domain rank0
• Risky TLDTrue

Read that combination again. IPQS acknowledged valid DNS and email authentication. It found no spam, no malware, and no hosted content. It assigned no content category. Yet it still branded the domain as phishing and gave it a risk score of 95 out of 100.

I submitted a correction request roughly one month ago. I received no explanation, no evidence, no verification request, no ticket update, and no human response. As of August 29, 2026, the classification remained unchanged.

A score of 95 is not a gentle warning

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

A score of 95 is not presented as “we lack enough data.” It is presented as a strong security finding.

To be precise, 95 does not necessarily represent a mathematically validated 95 percent probability of malicious activity. IPQS calls it a confidence score, and its formula is proprietary. But that nuance is unlikely to matter to an automated fraud system or an analyst staring at a bright red result.

IPQS provides examples in which customers flag a URL when phishing is true, malware is true, or the risk score exceeds 85. It also markets domain screening for signups, transactions, and email submissions.²

These are not decorative numbers. They are designed to trigger action.

“Phishing: true” combined with a score of 95 can become a rejected signup, blocked email, failed transaction, security alert, denied registration, or demand for extra verification.

IPQS may say that its customers make the final decision. Technically, they do. But IPQS sells the signal precisely because it expects customers to act on it.

The company cannot claim credit when its data stops fraud, then pretend to be a passive bystander when the same data punishes an innocent user.

The IPQS report contradicts itself

The report’s individual findings make its final verdict even harder to defend.

No malware. No spam. No parked page. No hosted content. Valid DNS. SPF and DMARC confirmed. No content category. No traffic rank.

Then, with no public explanation, IPQS leaps to “phishing: true” and a risk score of 95.

What was the actual phishing indicator?

• Was there a cloned login page?
• Was there a credential-harvesting form?
• Was a company or brand being impersonated?
• Was a malicious script detected?
• Was the domain used in a verified phishing email?
• Was there a malicious redirect chain?
• Did an IPQS customer submit a complaint?
• Was there a match against a third-party blacklist?
• Was the verdict inferred from the domain name?
• Was reputation inherited from shared infrastructure?

The public result does not say.

That is the core failure. IPQS presents an extremely specific and potentially damaging conclusion while hiding the category of evidence behind it.

“Insufficient reputation” is a reasonable description of a new domain. “Phishing: true” is an allegation of malicious conduct. Those statements are not remotely interchangeable.

One means there is not enough information. The other says the domain is associated with cybercrime. IPQualityScore should not erase that distinction merely because its model finds uncertainty inconvenient.

Apparently, .me is a “risky TLD”

The result also marked the .me extension as risky.

IPQualityScore defines risky_tld as a signal that a domain uses a top-level domain frequently associated with malware, scams, abuse, or phishing. Its public documentation does not clearly disclose the complete list, measurement period, triggering abuse rate, update schedule, or the weight this flag receives in the final score.³

TLD-level abuse statistics are not completely useless. Researchers do measure differences in abuse among domain extensions. Spamhaus explains that a TLD may develop a bad reputation because of a high ratio or large volume of abusive domains. It also acknowledges that these measurements involve judgment 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 site or personal email address. Treating that extension as categorically dangerous, without explaining the underlying statistics or their influence on a score of 95, is crude profiling.

It is guilt by neighborhood.

A ZIP code with an elevated fraud rate does not make every resident a fraudster. A carrier with more spam reports does not make every subscriber suspicious. A hosting company with abusive customers does not make every site on its infrastructure malicious.

These may be reasons to look more carefully. They are not evidence that a particular domain committed fraud.

If .me materially influenced the score, IPQS should explain how. If it did not, displaying “Risky TLD: true” without meaningful context appears designed mainly to make the report look more alarming.

New is not the same as malicious

Criminals use newly registered domains. That is real, and domain age can be useful when combined with actual evidence: a fake login page, brand impersonation, credential theft, malicious scripts, abusive email activity, or verified threat reports.

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

Every legitimate domain was new once. Every family domain, portfolio, local company, nonprofit, open-source project, personal blog, custom email address, and startup began with no traffic rank and no long reputation history.

The absence of reputation is not a negative reputation.

IPQualityScore itself acknowledges that unusual or newly created sites are not automatically malicious and that individual signals rarely prove abuse on their own.⁵

That would be sensible—if the product reflected it.

A fair result would have said: “This domain is new, unranked, and lacks enough history for a confident classification.”

Instead, it said:

Phishing: true.

Those are radically different messages.

An unknown, unrated, unclassified, or low-confidence result would have been reasonable. A score of 95 paired with a phishing label was not.

If IPQS has direct evidence, it should identify the type and date of that evidence. If all it knows is that the domain is young, unranked, uses .me, and redirects, then it does not know the domain is phishing.

It is guessing—and presenting that guess as a near-certain security verdict.

A normal redirect is not phishing

The report also marked the domain as redirected. That can sound ominous to a nontechnical reader, but redirects are everywhere.

Websites redirect from HTTP to HTTPS, from a root domain to www, from old pages to new pages, or from personal domains to hosted profiles. Redirects are a basic part of the web.

Malicious campaigns can abuse redirect chains to obscure a destination. But a redirect alone proves nothing.

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

If the redirect affected the score, what exactly was suspicious? Was the destination on a verified threat feed? Did it contain a fake login form? Was the redirect obfuscated or conditional? Did it involve compromised infrastructure?

Without that context, “Redirected: true” is merely a technical fact. 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 on its anycast network. Many unrelated domains may appear behind the same Cloudflare addresses, while visitors see Cloudflare’s address instead of the origin server.⁷

A Cloudflare IP is not a unique identity for the domain behind it.

The same shared infrastructure may serve legitimate, abandoned, compromised, and malicious sites. Their owners do not know or control one another.

The public IPQS report does not reveal whether the displayed Cloudflare IP negatively affected the score. That lack of transparency is part of the problem.

If shared infrastructure affected the classification, IPQS should explain how it separated one hostname from thousands of unrelated Cloudflare customers. If the IP did not matter, IPQS should disclose what did.

A reputation product 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 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 products.⁸

According to IPQS, its intelligence draws from sources including honeypots, blocklists, forensic analysis, machine learning, client feedback, and information reported through its fraud-prevention network.⁹

Its privacy materials describe the submission of IP addresses, email addresses, phone numbers, device identifiers, URLs, and domains for fraud analysis. They also describe using data and metadata to improve fraud-detection systems.¹⁰

That network effect may be powerful when the data is right. It is dangerous when the data is wrong.

A bad signal can affect a customer decision, produce another fraud report, and potentially gain the appearance of confirmation as it circulates.

I cannot prove that this happened to my domain, and I am not claiming it did. I am saying that IPQS’s own description of its data ecosystem makes fast corrections and strong evidence standards essential.

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

What I found was silence.

How far can an IPQS score travel?

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

Public materials do not establish that every company associated with IPQS uses the exact domain-reputation product that flagged my domain. Some may use proxy detection, email validation, device fingerprinting, or other services.

It would be irresponsible to claim that every IPQS customer automatically blocks domains using the same API response.

The broader reach is still significant.

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

A score can travel far beyond a free lookup page. It can influence registration systems, transaction reviews, analyst investigations, security alerts, and automated response playbooks.

The affected person may never learn that IPQualityScore was involved. They may see only a generic message:

• Registration denied
• Suspicious email domain
• Transaction could not be completed
• Access blocked for security reasons
• Additional verification required
• Contact customer support

That is why “it is 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 contain complaints from people who say IPQualityScore classified legitimate sites or residential IP addresses as scams, proxies, VPNs, or sources of abusive activity. Some say they requested corrections and received no meaningful response.¹³

These accounts require caution. Online reviews are not laboratory evidence. People can misunderstand results, omit context, exaggerate, or write while angry. Individual posts should not automatically be accepted as proven technical findings.

Still, patterns matter.

When unrelated people describe questionable labels followed by an unresponsive correction process, it stops looking like one isolated technical glitch. It starts looking like a quality-control problem.

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

I do not dismiss those reviews. IPQS may provide real value against real abuse.

But a product can catch plenty of bad activity while still causing unacceptable collateral damage.

Business reviewers are often the customers buying the protection. Public complainants are often the people being blocked, scored, or labeled.

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 entry in its database. That makes me very easy to ignore.

The marketing claims are remarkably confident

IPQualityScore markets itself with extremely strong claims about data accuracy and low false-positive rates.¹⁵

Those claims demand evidence.

I could not find enough public information to independently evaluate them. I did not find a comprehensive public benchmark dataset, representative sample description, confusion matrix, detailed ground-truth methodology, or false-positive breakdown by product, TLD, domain age, 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.

IPQS documentation also acknowledges that stricter settings may increase false positives.¹⁶

The company therefore knows that false positives happen. The serious questions are how often, how severely, how quickly they are corrected, and whether customers are notified after bad data has already been distributed.

The marketing provides no meaningful answers.

The fine print tells a different story

IPQualityScore’s marketing emphasizes accuracy and fraud prevention. Its legal terms are considerably less confident.

The terms provide the services “as is,” disclaim warranties concerning accuracy and reliability, and contain limitations of liability and other restrictions.¹⁷

Such clauses are common in technology contracts. Context still matters.

IPQS is not selling a color picker or a note-taking app. It sells 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 conclusions. The contract warns that those conclusions may be wrong.

Meanwhile, third parties affected by those conclusions may have no contract with IPQS, no access to the underlying evidence, and no effective route to challenge the result.

That is not a credible accountability model.

The support promises led to an appeal into a void

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

That alone exposes a gap.

A company selling domain reputation and malicious URL detection should have a clearly labeled domain and URL appeal process. It should provide a case number, confirmation email, review deadline, status page, and final explanation.

I used the available channel and challenged the classification.

A month passed. Nothing happened.

Perhaps the message was lost. Perhaps domain reports use a different queue. Perhaps noncustomers receive lower priority. Perhaps someone reviewed the domain and refused to change the result.

I do not know, because nobody responded.

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

Why IPQS customers should care

False positives are not only a problem for domain owners. They also impose direct costs on companies buying IPQS data.

• A legitimate customer may be unable to register.
• A valid transaction may be rejected or delayed.
• A personal email domain may be treated as abusive.
• An analyst may waste time investigating a harmless domain.
• A support team may have to reverse an unexplained block.
• A business may lose a sale without understanding why.
• Users may stop trusting security warnings.
• Teams may create broad allowlists that weaken security.
• Legitimate customers may move to a competitor.

False positives are also difficult to measure.

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

Without manual investigation of a meaningful sample, the vendor’s score can become its own proof. IPQS calls users risky, the customer blocks them, and the block is then counted as fraud prevented.

That is circular.

Customers should measure appeals, successful manual verifications, complaints, reversals, and blocked users later found to be legitimate.

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

IPQualityScore says customers remain responsible for their decisions and for appropriate review when those decisions significantly affect users.¹⁹

That principle is correct. The product should support it.

A responsible reputation system should clearly distinguish among at least four outcomes:

1. Verified malicious activity
2. Strong evidence of likely malicious activity
3. Limited, indirect, or conflicting evidence
4. 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 provide high-level reason codes:

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

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

An IPQS score should preserve that distinction. In my case, it did not.

“Our algorithm said so” is not evidence

Machine learning can detect patterns humans miss. Threat feeds can identify attacks faster than manual review. Automated 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 badly wrong in an individual case—especially when it is evaluating sparse data.

My domain is new. It has limited public history. It has no traffic rank. It uses a TLD that IPQS considers risky. It redirects. It sits behind 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 pile of weak signals does not become direct evidence simply because an algorithm compresses it 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 disclose every model feature, weight, threshold, or data source. Publishing its entire detection logic would help criminals evade it.

Protecting detection methods does not justify total opacity or a broken appeal process.

At a minimum, IPQualityScore should:

1. Stop using “phishing: true” when the available evidence shows only that a domain is new or unfamiliar.
2. Create a dedicated domain and URL false-positive form.
3. Acknowledge every appeal and issue a case number.
4. Publish a realistic review deadline and meet it.
5. Provide high-level reason codes.
6. Disclose whether a verdict came from live scanning, cached data, customer reports, external feeds, heuristics, or machine-learning inference.
7. Show the date and age of the evidence.
8. Explain how risky_tld is calculated and how much it influences the final score.
9. Avoid transferring reputation between unrelated users of shared CDN or cloud infrastructure.
10. Publish independently verifiable false-positive measurements for each product.
11. Notify customers when a distributed classification is corrected.
12. Give domain owners a meaningful escalation path.
13. Encourage additional verification instead of automatic blocking for new or unrated domains.
14. Reserve the strongest labels for direct evidence.
15. Separate verified abuse from statistical suspicion.
16. Let domain owners prove control through DNS or email.
17. Publish a status history showing when a classification was created, reviewed, and changed.
18. Offer “unknown” and “insufficient data” as genuine outcomes.

What I want from IPQS

My request is not complicated.

• Manually review the domain.
• Remove the unsupported phishing label.
• Explain which signal categories produced a score of 95.
• State whether .me materially raised the score.
• State whether the displayed Cloudflare IP played a role.
• Confirm whether there was an abuse report, blacklist match, scan result, customer complaint, or merely an automated inference.

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

If IPQualityScore has verified evidence that the 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 short explanation would be enough to begin a meaningful review.

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

That is basic accountability.

Suspicion is easy. Accuracy is hard.

Fraud detection is difficult. Criminals move quickly, rotate infrastructure, register disposable domains, abuse free services, hide behind proxies, and exploit every delay in detection.

None of that excuses reckless output.

It is easy to label anything new, uncommon, redirected, or low-traffic as suspicious. It is easy to turn weak correlations into a number that looks scientific. It is easy to sell fear reduction to businesses that will never meet the legitimate 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 phishing with a risk score of 95.

When I requested a review, the company ignored me.