Why IPQualityScore Flagged My Legitimate Domain as Phishing

A personal domain, set up correctly, labeled as dangerous

Just over two months ago I registered a new domain for private use. The goal was straightforward: a stable, professional address on my own surname, like first@lastname.me. I paid for ten years upfront because this was not a throwaway campaign, a funnel test or a temporary project. It was meant to be my long-term email identity.

The setup was done properly. DNS resolves correctly. SPF and DMARC are in place. The domain is not listed for sale, it does not send bulk mail, it does not serve malware, and it does not mimic any bank, exchange, social platform or government site.

Out of curiosity I ran it through IPQualityScore (IPQS). The output was hard to believe: phishing marked true, suspicious marked true, risk score 95, while at the same time spamming false, malware false, SPF and DMARC enabled, DNS valid, not parked, no hosted content, no category and a rank of zero. The only “negative” beyond the verdict itself was Risky TLD: true.

In short, IPQS confirmed that the technical foundations were sound and that it found no abuse — and still classified the domain as phishing with near-certainty.

About a month ago I filed a request to correct the entry. There has been no explanation, no evidence, no follow-up questions and no human reply. As of August 29, 2026 the record remains unchanged.

A 95 is not a cautious “we don’t know yet”

IPQS documentation describes its URL risk score as a confidence estimate for malicious URL detection, where 85+ is considered high risk and indicates a domain likely has a bad reputation or is malicious. The phishing flag is presented as meaning the URL is linked to phishing behavior. View source

A 95 therefore does not read as “unknown.” It reads as a firm accusation. Even if the number is not a literal 95% probability — IPQS calls it a proprietary confidence metric — any normal user, analyst or automated rule will interpret 95 as almost certain danger.

IPQS shows examples where customers block or review a URL when phishing is true, malware is true, or the score exceeds 85, and it encourages using domain reputation checks during registration, email submission and payments. API overview and domain reputation

Those numbers are built to drive decisions. A “phishing: true” plus 95 can turn into a rejected account, a blocked email, an alert in a SOC, a failed transaction or an extra verification hurdle. IPQS may say the customer makes the final call — which is technically true — but the company sells the signal precisely so customers will act on it. It cannot claim credit for prevented fraud and then claim it is just a neutral data provider when its signal harms a legitimate user.

The report undermines its own conclusion

Look at the findings side by side: no malware, no spam, not parked, no hosted content, DNS valid, SPF and DMARC confirmed, no category, no traffic rank — and then “phishing: true” with 95.

What exactly was the phishing indicator? A duplicated login page, a credential harvest form, a spoofed brand, a malicious script, a phishing email tied to the domain, a harmful redirect chain, a complaint from a client, a blacklist hit, a model pattern matched on the name, or reputation inherited from shared infrastructure? The public report does not say.

That gap is the core issue. A highly damaging and specific label is shown while the supporting evidence stays hidden. “Limited reputation” would be an honest description for a new domain. “Phishing” is an allegation of criminal behavior. They are not interchangeable, and a scoring system should not conflate them because uncertainty is harder to productize.

Why marking .me as “risky” is misleading

The scan also flagged .me itself as risky. IPQS defines risky_tld as indicating a TLD often linked to malware, scams or phishing, without publishing which TLDs are on the list, which time window is analyzed, which abuse thresholds trigger inclusion, or how much weight this factor carries. URL scanner documentation and email validation documentation

Abuse rates can differ by TLD, a point even Spamhaus makes while noting that such measurements involve judgment and do not cover every domain. TLD report and statistics FAQ

That is why TLD reputation should be a weak contextual hint, not a proxy for guilt. .me is a natural, widely used choice for personal sites and personal email. Using the extension alone to inflate a score to 95 is guilt by association — like judging every resident by a ZIP code’s crime rate or every customer by a carrier’s spam rate. If .me heavily influenced the rating, IPQS should disclose how. If it did not, showing “Risky TLD: true” without context only makes the report look more alarming.

Being new is not the same as being malicious

It is true that attackers often use fresh domains. That fact only matters when combined with concrete signs such as a fake login, brand impersonation, a credential harvester, malicious mail activity or confirmed abuse reports. Newness alone is not phishing. Every legitimate family domain, portfolio, small business, nonprofit, open-source project and startup was once new, unranked and without history.

Absence of history is not a negative history. IPQS itself notes that a newly created or unusual site is not automatically malicious and that single signals rarely prove abuse on their own. View source

The response I received did not say “this domain is new and we lack enough data.” It declared phishing with a score of 95. An honest low-confidence outcome — unknown, unrated, insufficient data — would have been reasonable. A warning about lack of history would have been understandable. A near-maximum phishing verdict without proof was not.

If IPQS has direct proof of phishing, it should state the type and date of that proof. If all it knows is that the domain is a couple of months old, has no rank, uses .me and redirects, then it does not know it is phishing — it is guessing, and presenting that guess as near-certain fact.

A standard redirect does not equal phishing

The report also noted that the domain redirects. To a non-technical reader that may sound suspicious, but redirects are ordinary web behavior: HTTP to HTTPS, root to www, old URL to new URL, or a personal domain to a hosted profile.

Redirect chains can be abused, but by themselves they prove nothing. IPQS defines the field as indicating whether a URL forwards to another domain, without stating that every redirect is malicious. View source Without context — such as a destination on a verified threat feed, a deceptive login page on the target, or an obfuscated conditional chain — “Redirected: true” is just a technical fact, not evidence.

A shared Cloudflare IP says little about the owner

The report displayed a Cloudflare IP. Cloudflare documents that proxied hostnames use shared anycast ranges and that visitors see a Cloudflare address rather than the origin server. Many unrelated sites can share the same range; some may be legitimate, some abandoned, some compromised. View source

The public IPQS result does not clarify whether that shared address affected the score. That ambiguity is itself a problem. If shared infrastructure influenced the verdict, IPQS should explain how it isolated the reputation of one hostname from unrelated neighbors. If it did not, it should explain what actually did drive the 95. Any reputation engine that cannot reason correctly about CDNs, reverse proxies and large cloud platforms is not ready for the modern web.

What IPQualityScore offers

IPQS is not a small side project. The company says it has operated since 2011 and serves thousands of businesses, selling IP reputation, proxy and VPN detection, email validation, phone intelligence, device fingerprinting, bot detection, transaction scoring and domain/URL reputation. About IPQS and IPQS homepage Its data is described as coming from honeypots, blocklists, forensic work, machine learning, customer feedback and its fraud-prevention network. About IPQS and proxy and VPN detection

Its policies also note that clients can submit IPs, emails, phones, device IDs, URLs and domains for analysis, and that related metadata may be used to improve detection systems. Privacy policy and terms of service

That feedback loop can be powerful when accurate, but risky when inaccurate. A flawed signal can influence a client decision, generate another report, and look more credible as it circulates. I cannot prove that happened here and I do not claim it did — I am noting that IPQS’s own description makes fast, evidence-based corrections essential.

Who might be acting on this data?

IPQS showcases well-known logos and publishes case studies and testimonials from several businesses. Reviews and testimonials, Bolt case study, Phone.com case study, Toluna case study, and ZinQ Media case study

A fair caveat is needed: public marketing does not prove that every listed company uses the exact domain-reputation endpoint that flagged my domain; some may use IP intelligence, proxy detection or email validation instead. Still, the reach matters. IPQS advertises integrations with security and fraud platforms that embed reputation signals into dashboards and automated workflows. IPQS integrations and CrowdStrike Marketplace listing

That means a single score can travel well beyond a free lookup page into registration flows, payment reviews and analyst queues. The person affected may only see a generic “registration denied” or “extra verification required” message and never learn that an IPQS score was involved. Saying “it’s only a score” ignores how the product is actually used.

Mine appears not to be an isolated complaint

Reviews and community threads include reports from others who say IPQS classified legitimate sites or residential addresses as scams, proxies or abusive, with little success when asking for a correction. Trustpilot reviews, HomeNetworking discussion, Cybersecurity Help discussion, and Tech Support discussion

Such anecdotes are not controlled studies and should be treated as allegations, not technical proof. Even so, a recurring pattern — wrong label followed by silence — points to a quality-control and support issue rather than a one-off glitch.

There are also many positive reviews from paying buyers who say the service helps catch bots, fake accounts and abusive payments. Capterra reviews and G2 reviews Both perspectives can be true: a tool can be useful for buyers while imposing real costs on non-customers who are scored incorrectly. Those two groups experience the same system very differently.

Bold marketing, careful fine print

IPQS markets itself with strong claims about low false-positive rates and very high data accuracy. Reviews and testimonials, About IPQS, and account fraud detection I could not locate public benchmarks that would allow independent verification — no representative dataset description, confusion matrix, ground-truth methodology or false-positive breakdown by product, domain age, TLD or hosting type. If internal research exists to support the claims, it should be published; a percentage without method is promotion, not proof.

The documentation itself acknowledges that stricter settings can raise false positives. URL scanner options and proxy detection options The real questions are how often errors occur, how serious they are, how quickly they are fixed, and whether customers are notified after a bad classification has already spread.

The legal terms are noticeably more cautious, stating the service is provided “as is” and disclaiming warranties that results will always be accurate, reliable or error-free, with limitations of liability. View source Those clauses are common, but the tension is striking: marketing invites trust in the verdicts, while the terms warn those verdicts may be wrong. The people labeled by the system have no contract and no effective way to contest the label.

Support promises versus experience

IPQS offers contact options and a false-positive reporting form that seems primarily geared toward IP classifications. Contact page and false-positive form For a company that sells domain and URL reputation, the absence of a clearly labeled domain/URL appeal flow — with a case number, confirmation, timeline and final explanation — is a gap.

I used the available channel to report the misclassification. A month has passed with no response. Perhaps the message was lost, perhaps domain reviews sit in a different queue, perhaps non-customers are deprioritized, perhaps the record was reviewed and left unchanged — I cannot know because nothing was communicated. When you accuse someone’s property of phishing, “submit a form and hope” is not an appeal process; even a rejection with reasons would be more useful than silence.

Why this should concern IPQS customers too

False positives do not only hurt domain owners. They hurt the businesses that pay for the data: a legitimate user cannot register, a valid transaction is delayed, a personal email domain is blocked, analyst time is wasted, support costs rise, and a sale is lost without a clear reason. Repeated bad alerts also erode trust in controls — teams ignore warnings, create broad allow-lists, or build manual workarounds that weaken security.

Measurement is tricky. If a system blocks a thousand events because they were scored as risky, how do you know how many were real attacks? Without sampling appeals, manual verification outcomes, complaints and reversals, the score becomes its own justification: the block is counted as fraud prevented because the vendor said it was fraud. That is circular reasoning.

Risk signals should inform judgment, not replace it

IPQS states that customers remain responsible for their decisions and for proper review where outcomes significantly affect users. Privacy policy and data processing agreement That principle is correct, but the product should make it easier to follow.

A mature reputation system should separate verified malicious activity, strong likely abuse, conflicting or thin evidence, and insufficient data. A new personal domain with little public history belongs in the last bucket absent real proof of abuse. Calling it phishing is not cautious — it is careless.

Useful transparency would include high-level reason codes such as: newly registered, limited traffic history, TLD statistical risk, redirect observed, shared CDN hosting, third-party report received, brand impersonation detected, credential form found, malicious script detected, verified feed match, heuristic-only classification, or awaiting human review. Customers could then treat the output as a clue to be interpreted, not a final verdict to be blindly enforced.

“The model said so” is not evidence

Machine learning and threat feeds can be valuable, but automation does not create facts. My domain is recent, has little public history, has no traffic rank, uses a TLD IPQS treats as risky, redirects, and sits behind shared Cloudflare infrastructure. Those facts may justify uncertainty — they do not conjure a phishing page, a stolen-password form, a victim, or a malicious email. Combining several weak correlations into a single number does not produce direct evidence.

If stronger proof exists, IPQS should name its category. If it does not, “phishing: true” is an irresponsible label.

What IPQualityScore should improve

The company does not need to expose every rule or weight — that would help criminals evade detection. It can protect methods while offering a fair process:

1. Reserve “phishing: true” for cases with direct evidence, not mere newness or unfamiliarity.
2. Provide a dedicated domain and URL false-positive channel.
3. Acknowledge every appeal with a case number and confirmation.
4. Publish and meet a realistic review timeline.
5. Return high-level reason codes with every verdict.
6. Disclose the source type: live scan, cached data, customer report, third-party feed, heuristic or ML inference.
7. Show the date and freshness of the evidence behind a negative label.
8. Explain how risky_tld is calculated and weighted.
9. Handle shared CDN and cloud infrastructure with care.
10. Publish verifiable, product-level false-positive metrics.
11. Notify customers when a past classification is corrected.
12. Offer a meaningful escalation path for domain owners.
13. Encourage extra verification for new domains instead of auto-blocking.
14. Save the strongest labels for directly supported cases.
15. Keep verified abuse clearly separate from statistical suspicion.
16. Allow owners to prove control via DNS or email verification.
17. Provide a history showing when a classification was created and reviewed.
18. Include “unknown / insufficient data” as legitimate outcomes.

These steps would not weaken fraud prevention; they would make it more credible.

What I am asking for

My request is simple. Please manually review the domain, remove the false phishing designation, and explain what drove the 95. Did the .me TLD materially raise the score? Did the shared Cloudflare IP play any part? Was there an actual abuse report, blacklist hit, scan result or complaint — or just a collection of weak assumptions?

Above all, please recognize that a false phishing label can cause real harm. If verified proof exists that this domain hosted phishing content, harvested credentials or distributed malicious links, identify the category and date of that proof. Exposing the entire detection model is not necessary; a concise, evidence-based explanation is enough. If that cannot be provided, the label should be withdrawn. That is the minimum that accountability requires.

Suspicion is cheap; accuracy is difficult

I understand why fraud vendors lean aggressive — their clients face real, fast-moving attacks. The difficulty of the problem, however, does not justify reckless output. It is easy to call anything new, private, redirected or low-traffic suspicious, and to make weak correlations look scientific.

The hard work is distinguishing “unknown” from “malicious,” admitting uncertainty, responding when the system is wrong, and correcting bad data before it spreads. In my case IPQS failed those hard tasks: it took a legitimate personal domain with valid DNS, SPF and DMARC, with no spam, no malware and no demonstrated abuse, and branded it as phishing with a 95. When I asked for a fix, the response was silence.

A fraud-prevention provider may be cautious. It should not be careless. When a business sells reputation judgments to the rest of the internet, “our algorithm said so” is not sufficient.

Sources and notes

1. IPQualityScore, “Malicious URL Scanner API Response Parameters,” accessed August 29, 2026. View source
2. IPQualityScore, “Malicious URL Scanner API Overview” and “Domain Reputation Test,” accessed August 29, 2026. API overview and domain reputation
3. IPQualityScore, “Malicious URL Scanner API Response Parameters” and “Email Validation API Response Parameters,” accessed August 29, 2026. URL scanner documentation and email validation documentation
4. Spamhaus, “The World’s Worst Top Level Domains” and “Reputation Statistics FAQ.” TLD report and statistics FAQ
5. IPQualityScore, “Domain Reputation Test,” accessed August 29, 2026. View source
6. IPQualityScore, “Malicious URL Scanner API Response Parameters,” accessed August 29, 2026. View source
7. Cloudflare, “Cloudflare IP Addresses.” View source
8. IPQualityScore, “About IPQS” and IPQS homepage, accessed August 29, 2026. About IPQS and IPQS homepage
9. IPQualityScore, “About IPQS” and “Proxy and VPN Detection.” About IPQS and proxy and VPN detection
10. IPQualityScore, “Privacy Policy” and “Terms of Service.” Privacy policy and terms of service
11. 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
12. IPQualityScore, “Fraud Prevention Integrations,” and CrowdStrike Marketplace, “IPQS Fraud, Threat and Risk Scoring.” IPQS integrations and CrowdStrike Marketplace listing
13. 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
14. Capterra and G2 reviews of IPQualityScore. Capterra reviews and G2 reviews
15. IPQualityScore, “Reviews and Testimonials,” “About IPQS,” and “Account Creation Fraud Detection.” Reviews and testimonials, About IPQS, and account fraud detection
16. IPQualityScore, “Malicious URL Scanner Advanced Options” and “Proxy Detection API Advanced Options.” URL scanner options and proxy detection options
17. IPQualityScore, “Terms of Service.” View source
18. IPQualityScore, “Contact Us” and “Report a False Positive.” Contact page and false-positive form
19. IPQualityScore, “Privacy Policy” and “Data Processing Agreement.” Privacy policy and data processing agreement
20. Author’s personal website