IPQualityScore Labeled My Clean Personal Domain as Phishing

Just over two months ago, I registered a new domain for my personal use.

My goal was straightforward: I wanted a permanent, professional email address built around my surname, something in the form of first@lastname.me. I paid for a ten-year registration because this was not intended to be a disposable campaign, a temporary marketing funnel, or a short-lived startup experiment. I wanted an email identity that could remain mine for years.

I configured the domain correctly. Its DNS records are valid, SPF is active, and DMARC is enabled. The domain is not listed for sale, does not send spam, does not distribute malware, and does not impersonate a bank, cryptocurrency exchange, social platform, government institution, or any other organization.

I then ran the domain through IPQualityScore, commonly called IPQS.

The result was ridiculous:

Put differently, IPQS confirmed that the domain had valid DNS and proper email authentication. It detected no spam, no malware, and no hosted content. It assigned no content category. Despite all of that, it declared the domain to be phishing and gave it a risk score of 95 out of 100.

I filed a correction request approximately one month ago.

There was no explanation, no supporting evidence, no request for me to verify ownership, no ticket update, and no response from a person. As of August 29, 2026, the classification remains unchanged.

This is more than an inconsequential technical anomaly.

IPQualityScore sells reputation and fraud-risk intelligence that companies can use to block people, reject account registrations, review payments, examine security alerts, and determine whether a domain, email address, IP address, phone number, or device deserves trust.

A company that sells suspicion as a service must also accept responsibility when that suspicion is incorrect.

In my case, IPQS has demonstrated neither accuracy nor accountability.

A score of 95 is not a gentle warning

IPQualityScore describes its URL risk score as an estimate of confidence in malicious URL detection. According to its documentation, scores at or above 85 indicate high risk, with the affected domains likely to have a poor reputation or be malicious. The documentation says the phishing field identifies a URL associated with malicious phishing behavior.¹

This distinction matters because a score of 95 is not framed as, “We currently lack enough information about this domain.”

It is communicated as an exceptionally strong finding.

To be exact, 95 does not necessarily represent a statistically valid 95 percent probability that the domain is malicious. IPQS describes the value as a confidence score, while keeping the internal calculation proprietary. Nevertheless, a typical user, security analyst, fraud team, or automated system will naturally interpret 95 as an indication of almost certain danger.

IPQS publishes examples in which customers flag a URL if phishing is true, malware is true, or the risk score exceeds 85. It also promotes its domain reputation products as tools for screening domains during signups, transactions, and email submissions.²

These values are not merely decorative.

They exist to affect real decisions.

A result combining phishing: true with a risk score of 95 can lead to a rejected registration, blocked message, security alert, denied account, failed payment, or demand for extra identity verification.

IPQualityScore could respond that the customer ultimately decides what action to take. Technically, that is correct. Yet IPQS sells this signal precisely because it expects customers to use it.

The company cannot claim credit when its intelligence prevents fraud and then portray itself as a neutral spectator when the same intelligence harms an innocent person.

The IPQS report contradicts itself

The report's individual findings make its final conclusion even more difficult to justify.

It reports no malware.

It reports no spam.

It says the domain is not parked.

It detects no hosted content.

It confirms valid DNS.

It confirms both SPF and DMARC.

It provides no content category.

It provides no traffic rank.

Somehow, those findings still become phishing: true and a risk score of 95.

What, specifically, was the phishing indicator?

Was there an imitation login page?

Was there a form intended to collect credentials?

Was a legitimate brand being impersonated?

Was suspicious JavaScript detected?

Was the domain linked from a phishing email?

Was there a malicious redirect chain?

Did an IPQS customer submit a complaint?

Did the domain match an external blacklist?

Did a model react to a pattern in the domain name?

Was reputation inherited from unrelated users of shared infrastructure?

The public report provides no answer.

That omission is the central problem. IPQS makes a precise, potentially harmful allegation while concealing the basis for it.

Describing a new domain as having “insufficient reputation” would be reasonable.

Declaring phishing: true is an allegation of malicious conduct.

Those statements are not remotely equivalent.

The first says that there is not enough information. The second asserts that the domain is associated with a real category of cybercrime.

IPQualityScore should not erase that difference simply because its scoring model does not handle uncertainty well.

Apparently, .me is a “risky TLD”

The result also classified the .me extension itself as risky.

IPQualityScore defines risky_tld as an indicator that a domain uses a top-level domain frequently connected with malware, phishing, scams, or abuse. Its public documentation does not reveal which extensions are included, what measurement period is used, which abuse rate triggers the classification, how often the list is revised, or how much influence the signal has on the final score.³

I am not suggesting that abuse statistics at the TLD level are entirely worthless.

Security researchers do observe differences in abuse rates between top-level domains. Spamhaus, for example, explains that a TLD can acquire a poor reputation due to a high proportion of abusive domains or a high overall volume of abuse. It also notes that these measurements involve judgment and do not represent the complete domain population.⁴

That is precisely why TLD reputation should remain a weak, contextual indicator rather than becoming a shortcut to guilt.

A .me domain is an obvious and natural option for a personal website or personal email address. Categorically treating that extension as risky, without disclosing the relevant abuse rate or explaining its effect on a score of 95, is crude profiling.

It is guilt by neighborhood.

A postal code with an above-average fraud rate does not make each resident a fraudster. A mobile carrier with more spam complaints does not make every subscriber suspicious. A hosting provider with abusive customers does not prove that every site on its network is malicious.

Such information may help determine where closer inspection is appropriate. It is not proof that a specific domain committed fraud.

If the .me extension had a meaningful effect on my score, IPQualityScore should say how.

If it had no meaningful effect, presenting Risky TLD: true without context appears primarily intended to make the result more alarming.

New is not the same as malicious

Criminals do use recently registered domains. That is a real phenomenon.

Domain age can be relevant when it appears alongside a counterfeit login page, brand impersonation, suspicious scripts, credential theft, malicious email activity, or confirmed abuse reports.

But “new” does not mean “phishing.”

Every legitimate domain was new at some point.

Every family domain, personal portfolio, small business, nonprofit, open-source project, blog, custom email domain, and startup begins without a traffic rank or a long record of trustworthy activity.

Having no established reputation is not the same as having a bad reputation.

IPQualityScore itself states that not every unusual or newly created website is malicious, and that isolated signals rarely establish abuse on their own.⁵

That is a reasonable position.

The problem is that my result did not present a message such as:

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

Instead, it said:

Phishing: true.

Those messages communicate fundamentally different things.

An unknown, unrated, unclassified, or low-confidence result would have been reasonable. A notice explaining that the domain lacked sufficient history would also have been understandable.

A phishing classification combined with a score of 95 was not reasonable.

If IPQS possesses direct evidence of phishing, it should disclose the type of evidence and the date on which it was observed.

If all it knows is that the domain is two months old, unranked, uses .me, and redirects to another location, then it does not know that the domain is phishing.

It is making a guess.

Worse, it is presenting that guess as an almost certain security conclusion.

A normal redirect is not phishing

The IPQualityScore report also indicated that the domain redirects.

That may sound dangerous to a person unfamiliar with web infrastructure, but redirects are a routine part of the internet.

Domains commonly redirect from HTTP to HTTPS, from a root domain to www, from one landing page to another, from an outdated page to its replacement, or from a personal domain to a profile hosted elsewhere.

Redirects are a basic web mechanism.

Redirect chains can, of course, be used in phishing campaigns. Attackers may use them to obscure the ultimate destination or route victims through compromised systems.

A redirect alone, however, proves nothing.

IPQS defines the relevant field as an indication that a URL redirects to another domain. Its documentation does not claim that all redirects are inherently malicious.⁶

If the redirect affected the score, IPQualityScore should explain what was suspicious about either the destination or the redirect sequence.

Did the final destination appear on a verified threat feed?

Did it display a fraudulent login page?

Was the redirect intentionally obscured?

Did its behavior change according to browser, device, or geographic location?

Without such context, Redirected: true is simply a technical description of website behavior. It is not proof of phishing.

The Cloudflare IP tells us almost nothing about the owner

The report also showed an IP address belonging to Cloudflare.

Cloudflare explains that proxied hostnames operate through shared IP ranges. These addresses belong to its anycast network and can be shared by numerous unrelated domains. Visitors see the Cloudflare address rather than the origin server's address.⁷

A Cloudflare IP address is therefore not a unique identity for the website using it.

Many unrelated domains may appear behind the same infrastructure. Some will be legitimate, some abandoned, some compromised, and some malicious.

Their owners do not know one another and cannot control one another's actions.

The public IPQS result does not provide enough information to determine whether the displayed Cloudflare IP harmed the score. That lack of clarity is itself a concern.

If shared infrastructure influenced the classification, IPQS should explain how it separated one hostname's reputation from the conduct of unrelated Cloudflare customers.

If the shared address did not influence the result, then IPQualityScore should identify what did.

A domain reputation service that cannot correctly account for content delivery networks, reverse proxies, shared hosting, and major cloud platforms is not suitable for the modern web.

What IPQualityScore actually sells

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

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

According to IPQS, its intelligence draws from honeypots, blocklists, forensic investigation, machine learning, customer feedback, and information submitted through its fraud-prevention network.⁹

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

When the underlying system works correctly, this creates a powerful network effect.

When it fails, the same network effect creates a serious danger.

An inaccurate signal can enter a scoring system, influence a customer's decision, produce another fraud report, and gradually acquire the appearance of confirmation while circulating through the wider ecosystem.

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

My point is that IPQS's own description of a feedback-driven intelligence network makes evidence quality and rapid correction especially important.

A business running this type of system needs an excellent appeals procedure.

What I encountered was silence.

Who uses IPQS?

IPQualityScore displays logos of prominent companies and publishes customer stories and case studies involving multiple businesses.¹¹

Those associations matter because they illustrate the potential reach of IPQS data.

An important qualification is necessary: public information does not prove that every company associated with IPQS uses the particular domain reputation service that classified my domain.

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

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

Even so, the wider ecosystem remains significant.

IPQS advertises integrations with security platforms, threat-intelligence tools, fraud systems, and investigation products. These integrations can insert reputation information into enterprise dashboards and automated workflows.¹²

An IPQS score can therefore travel far beyond a public lookup page.

It may enter registration pipelines, transaction reviews, analyst investigations, automated playbooks, and security alerts.

The affected person might never learn that IPQualityScore played a role. They may only receive a generic message saying that their registration was rejected, their email domain appeared suspicious, their payment could not be processed, or extra verification was necessary.

This is why saying “it is only a score” is not an adequate defense.

The score is the product.

Other people report similar false positives

My experience does not seem to be isolated.

Public discussions and reviews include complaints from people who say IPQualityScore incorrectly categorized legitimate websites or residential IP addresses as scams, proxies, VPNs, or sources of abuse.

Some reviewers also say they requested corrections or human review but received no meaningful answer.¹³

These reports require caution.

Online reviews are not controlled technical evidence. People can misunderstand results, omit relevant details, exaggerate, or write while frustrated. A single review should not automatically be accepted as a proven technical finding.

Patterns still deserve attention.

When unrelated individuals repeatedly describe incorrect classifications followed by an unresponsive correction process, the issue begins to look less like one unusual error.

It begins to resemble a quality-control problem.

IPQualityScore also has positive reviews on business software platforms. Paying customers report that the service helps them identify bots, fake registrations, abusive proxies, suspicious payments, and other types of fraud.¹⁴

I do not disregard those reports.

IPQS may deliver genuine value to organizations facing actual abuse. A product can catch substantial malicious activity while still producing an unacceptable level of collateral damage.

The difference between the audiences is important.

Reviews on business software platforms often come from paying customers who benefit when IPQS blocks more suspicious activity. Public complaints frequently come from individuals who were classified, scored, or blocked by the system.

One group purchases the protection.

The other group bears the cost of mistakes.

If IPQS is wrong about my domain, I am not a customer entitled to customer support. I am merely an entry in its database.

That makes ignoring me easy.

The marketing claims are remarkably confident

IPQualityScore promotes its services using exceptionally strong accuracy statements, including claims of very low false-positive rates and unusually high data accuracy.¹⁵

Those are significant claims.

I was unable to find enough public information to evaluate them independently.

I found no public benchmark dataset, representative sample description, confusion matrix, detailed ground-truth method, or false-positive analysis organized by product, TLD, domain age, region, hosting provider, or customer configuration.

IPQS may possess such research internally. If it does, the company should publish it.

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

IPQualityScore's own technical material acknowledges that stricter settings may increase false positives.¹⁶

The company clearly understands that errors occur.

The relevant questions are how frequently those errors occur, how damaging they are, how quickly they are fixed, and whether customers are notified after inaccurate data has already been distributed.

The company's marketing does not provide meaningful answers.

The fine print tells a different story

IPQualityScore's marketing emphasizes accuracy and the ability to prevent fraud without hurting legitimate users.

Its legal terms are substantially more guarded.

Those terms state that the service is supplied “as is” and disclaim guarantees that results will always be reliable, accurate, error-free, or free of defects. They also contain liability limitations and additional restrictions.¹⁷

Such clauses are common in technology agreements.

Context nevertheless matters.

IPQS is not selling a simple note-taking application or a color-selection tool. It sells risk judgments that may cause organizations to treat domains, people, email addresses, devices, and IP addresses as fraudulent or malicious.

Its marketing asks customers to rely on the company's conclusions.

Its legal language warns those customers that the same conclusions may be wrong.

The product can attach damaging classifications to third parties who have no contract with IPQualityScore and no practical mechanism for challenging the result.

That is not a balanced accountability structure.

The support promises don't match my experience

IPQS offers contact and false-positive reporting channels, including a form that appears to focus mainly on IP address classifications.¹⁸

That focus exposes a gap by itself.

A company selling domain reputation and malicious URL detection needs a clearly identified appeal procedure for domains and URLs.

Such a process should issue a case number, send a confirmation email, provide a review deadline, show the case status, and conclude with an explanation.

I used the available channel to report the false classification.

A month passed without a result.

Perhaps the submission was lost.

Perhaps domains are reviewed in a separate queue.

Perhaps people who are not customers receive less priority.

Perhaps someone reviewed the domain and chose not to modify the result.

I have no way to know because no one replied.

When a system labels someone's property as phishing, “submit a form and hope” does not qualify as an appeal process.

Even a rejection would have provided more value than silence if it had included a reason.

Instead, the allegation remains in place while the person challenging it receives no substantive response.

Why IPQS customers should care

Domain owners are not the only people who should be concerned.

Companies purchasing IPQualityScore data also bear the consequences of false positives.

An incorrect result can prevent a legitimate customer from registering an account, delay a genuine transaction, block a personal email domain, waste an analyst's time, increase support expenses, or cause a lost sale without making the reason clear.

Repeated false positives also undermine confidence in security controls.

Employees who repeatedly encounter inaccurate alerts may begin ignoring them. Teams may establish broad allowlists that weaken protection. Support staff may invent informal workarounds. Falsely rejected customers may move to a competitor.

False positives can also be difficult to quantify.

If a business blocks one thousand events because IPQS classified them as risky, how does it determine how many were genuine attackers?

Without investigating a meaningful sample, the vendor's classification may become its own supposed proof.

The system declares that users are risky, so blocking them is counted as prevented fraud. The fact that they were blocked is then used as evidence that the system succeeded.

That reasoning is circular.

A responsible customer should track appeals, successful manual verification, complaints, reversed decisions, and the number of blocked people later confirmed to be legitimate.

Without those measurements, the customer is not actually measuring accuracy.

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

A risk score should be a clue, not a verdict

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

That principle is correct.

The product should be designed to support it.

A responsible reputation system should distinguish between:

• Confirmed malicious activity
• Strong evidence suggesting malicious activity
• Conflicting or limited evidence
• Insufficient reputation information

Unless actual evidence of abuse exists, a new personal domain with little public history belongs in the final category.

Calling it phishing is not cautious.

It is careless.

A useful report would provide high-level reason codes, including:

• Recently registered domain
• Limited history of legitimate traffic
• Statistical risk associated with the TLD
• Redirect detected
• Shared hosting or CDN infrastructure
• Third-party report received
• Brand impersonation identified
• Credential form identified
• Malicious script identified
• Verified match in a phishing feed
• Classification primarily based on heuristics
• Classification awaiting human review

Customers could then make informed decisions instead of treating a single number as unquestionable.

There is an enormous difference between a domain that displayed a confirmed credential-harvesting page yesterday and a domain that is merely new, unranked, and protected by Cloudflare.

An IPQS result should preserve that distinction.

My result did not.

“Our algorithm said so” is not evidence

Machine learning can discover patterns humans overlook. Threat feeds can recognize campaigns faster than manual investigations. Automated risk scoring has a valid role in combating online fraud.

Automation, however, does not transform assumptions into facts.

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

My domain is new, has little public history, lacks a traffic rank, uses a TLD that IPQS considers risky, redirects, and operates through shared Cloudflare infrastructure.

Those characteristics may produce uncertainty.

They do not produce phishing content.

They do not create a counterfeit login screen.

They do not create stolen credentials.

They do not create malicious email.

They do not create victims.

Combining multiple weak indicators into a two-digit score does not turn them into direct evidence.

If IPQS possesses stronger evidence, it should disclose the category of that evidence.

If it does not, then phishing: true is an irresponsible classification.

What IPQualityScore should change

IPQS does not have to publish every model weight or detection rule. Doing so could help criminals evade its systems.

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

At minimum, IPQualityScore should:

1. Stop returning phishing: true when the evidence only establishes that a domain is unfamiliar or new.
2. Create a dedicated false-positive form for URLs and domains.
3. Confirm every appeal and assign it a case number.
4. Publish a realistic review period and adhere to it.
5. Provide understandable, high-level reason codes.
6. State whether a classification came from a live scan, cached information, customer reports, external feeds, heuristics, or machine-learning inference.
7. Display the date and age of evidence supporting a negative classification.
8. Explain how risky_tld is determined and how strongly it affects the score.
9. Evaluate shared CDN and cloud infrastructure with appropriate care.
10. Publish independently verifiable false-positive measurements for each product.
11. Inform customers when previously distributed classifications are corrected.
12. Give domain owners a meaningful escalation route.
13. Recommend additional verification rather than automatic blocking for new domains.
14. Reserve the most serious labels for cases backed by direct evidence.
15. Clearly separate verified abuse from statistical suspicion.
16. Permit domain owners to demonstrate control through DNS or email verification.
17. Show a history of when the classification was created and when it was reviewed.
18. Support “unknown” and “insufficient data” as genuine outcomes.

None of these measures would weaken fraud detection.

They would make IPQS more credible.

What I want from IPQS

My request is simple.

I want IPQualityScore to conduct a manual review of the domain.

I want the incorrect phishing label removed.

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

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

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

I want to know whether an actual abuse report, blacklist match, scan result, or customer complaint exists, or whether the classification came from a collection of weak assumptions.

Above all, I want IPQS to recognize that incorrectly describing a domain as phishing can produce real harm.

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

It does not need to expose its complete detection model.

A date, evidence category, source type, and concise explanation would be sufficient.

If it cannot provide even that information, it should remove the classification.

That is basic accountability.

Suspicion is easy. Accuracy is hard.

I understand why fraud-detection providers behave aggressively.

Their customers face real threats. Criminals rotate infrastructure, register disposable domains, exploit free services, conceal themselves behind proxies, and take advantage of delays in detection.

The difficulty of that task does not excuse reckless results.

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

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

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

The difficult task is separating “unknown” from “malicious.”

The difficult task is acknowledging uncertainty.

The difficult task is responding when the system makes a mistake.

The difficult task is correcting inaccurate data before it spreads.

In my case, IPQualityScore failed at those difficult tasks.

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, and classified it as phishing with a risk score of 95.

When I requested a review, the company ignored me.

A fraud-prevention company is entitled to exercise caution.

It is not entitled to be careless.

When a company sells reputation scores to the wider internet, “our algorithm said so” is not an adequate explanation.²⁰