What is a phishing takedown service?

A phishing takedown service coordinates evidence-based abuse requests to the organisations responsible for a reported website. The goal is to give those organisations enough relevant information to evaluate the abuse and act within their remit. Fraudpol's process includes reporting, team review, evidence capture attempts, provider notices after confirmation and monitoring. It is not a promise that a particular provider will remove a site, nor does submission alone establish that an accusation is true. The distinction between a report, a confirmed finding and a closed case remains important throughout the process.

How fast is a phishing takedown with Fraudpol?

Timing depends on the available evidence, the responsible provider and the state of the reported site. A host and a registrar may need different information and may reach different decisions. Fraudpol does not promise a completion time on this page. The Results page provides recorded outcomes from tracked cases, with historical cases excluded from speed claims where applicable. Those observations describe past cases rather than a deadline for a new one. If a site is already offline at review, that observation must also be kept distinct from a removal caused by a provider notice.

Why are browser warnings alone not the same as removal?

Security services and browser warning lists help users avoid known dangerous addresses, but a warning does not necessarily remove the underlying page. A user might reach it through another application or ignore the warning. Hosting and registration decisions address a different part of the problem. Fraudpol therefore distinguishes warning activity from provider action and from the observed state of the site. This explanation describes the roles involved without identifying individual services used by Fraudpol. No single warning or response should be treated as proof that all exposure has ended.

Does the service cover brand impersonation and lookalike domains?

Phishing and brand impersonation can be reported with the relevant URLs and evidence. A lookalike name is a reason to investigate, not automatic proof of abuse. Explain which brand or service is being imitated and what the page asks visitors to do. A login form, payment request or misleading support claim should be described using what is actually visible. Company monitoring can help identify addresses for review, but findings still need assessment. Avoid drawing conclusions about an individual's identity from a domain name or from shared hosting alone.

What evidence is useful for a provider review?

Useful evidence connects the reported URL to the specific behaviour being reported. Record the exact path, capture time and what the page displays or requests. A screenshot can explain the user-facing content, while a preserved page and its fingerprint identify what was captured. HTTP status and available network information provide context but do not replace the behavioural evidence. Keep provider replies with the case record. Do not submit account secrets or unnecessary personal details. Whether particular material satisfies an insurer, regulator or legal process is a separate decision for that recipient, not a guarantee made here.

How can a security team keep its report actionable?

Separate observations from conclusions and give each reported address enough context to review. Explain whether the concern is credential collection, impersonation, malware distribution or another observed behaviour. Identify the relevant page rather than relying on a homepage link. If content has changed, say when the earlier evidence was captured instead of implying it remains visible. Follow the case status and retain correspondence so that later updates can be understood in sequence. A clear, factual report helps a provider assess the request without requiring unsupported claims about speed, intent or responsibility.

Where can we discuss company requirements?

The company page is the starting point for discussing reporting and monitoring needs. Describe the kinds of incidents your team handles and the evidence you can provide. The available plan and its current terms determine what is included; this explanation does not add a separate service promise or price. For an individual suspicious website, use the website report form instead. Fraudpol reviews reported abuse and coordinates notices, while the responsible provider retains control over its own infrastructure and the decisions it makes about a particular site.

Phishing Takedown Service: managed, measurable, global

Evidence-based phishing reporting, provider notices after team confirmation and monitoring of the reported site.

Request managed takedown See how it works

The managed phishing takedown workflow

Step 1

Submit the reported URLs

A phishing report starts with the domain, exact page addresses, observed behaviour and available evidence. A domain alone does not always identify the page that asks for a password or payment. Include the path where the suspicious content appeared and explain what you saw without sending passwords, payment-card details or other sensitive account information. Website reports can be submitted with or without an account. Company reports follow their own review path. A report is an allegation to assess, not a finding that a provider or website owner has committed wrongdoing.

Step 2

Review and preserve evidence

A Fraudpol team member reviews the site. Once a website report is accepted, automatic evidence capture attempts to save the reported page with a SHA-256 fingerprint. That fingerprint identifies the captured content; it does not independently prove malicious intent or establish who operated a site. A page may be inaccessible, changed or already removed when a capture is attempted. Exact URLs and relevant screenshots help explain what was observed. Evidence should distinguish the page's behaviour from assumptions about its owner, and a failed fetch should not be presented as a successful capture.

Step 3

Notify the responsible providers

After a team member confirms abuse, notices are prepared for the responsible hosting provider, domain registrar and, where relevant, platform or service involved. Security services and browser warning lists can also be notified. These recipients have different roles: a host controls hosted content, a registrar manages the registration, and a warning service helps users recognise a dangerous address. A provider decides what action it can take under its own policies. Fraudpol supplies the report and evidence rather than claiming authority to remove content from infrastructure it does not operate.

Step 4

Monitor the reported site

Fraudpol keeps checking the reported site for changes such as becoming offline, suspended or no longer resolving. A temporary error is not necessarily a permanent removal, and a browser warning is not the same as a hosting suspension. These distinctions matter when recording an outcome. Providers may need to assess the evidence or request further information before acting. Monitoring the reported address also does not establish that every copy elsewhere has disappeared. Reporters receive emails on meaningful status changes, so a status update should describe the observed case rather than promise a deadline.

Step 5

Record the outcome

The case record brings together the reported address, evidence and subsequent status changes. Confirmed closed cases can appear on the Results page and as public case pages under Fraudpol's disclosure rules. Reporter details are never published. A public result is not a substitute for the underlying evidence, and figures from tracked cases should not be interpreted as a guarantee for the next report. Teams comparing outcomes should keep the initial report, provider correspondence and final observations together, and separate confirmed outcomes from open reports that still need review.

Different recipients, different responsibilities

Provider action and user warnings address different parts of a phishing incident. Neither should be confused with a guaranteed outcome.

Hosting providers

A hosting provider can review the content hosted on its infrastructure and decide whether its policies have been breached. A useful notice connects the reported URL to the observed abuse and preserved evidence rather than assuming every site on the same network is involved. When a reported page sits on shared infrastructure, the notice should be limited to the address and behaviour supported by the evidence. Other customers on that network may be unrelated. A reported IP can explain where a page was served at capture time, but it is not proof that the whole network is malicious. If the page has moved, the original capture still needs its timestamp so the recipient can distinguish the earlier observation from the current site. Requests should describe the specific content at issue and leave the provider to assess the appropriate response.

Talk to the team

Domain registrars

A registrar manages the domain registration, not necessarily the page content. Registration-level requests should explain the abuse and relevant evidence. A registrar's decision is separate from a host's response, and contacting one does not establish that the other has acted. Domain registration and hosting can be supplied by different organisations. Their contact details may also change, so a report should be grounded in the available registration and network information rather than an assumption based on the name of a familiar provider. The exact domain matters because a similar spelling can belong to a different registrant. Supporting evidence should show why the reported registration is relevant to the abuse. A registration-level request is not a finding about every subdomain or every account associated with a registrar, and a response should be recorded for the particular case.

Security services and browser warning lists

Warning services help users recognise dangerous sites. They can reduce exposure without removing a page from its server. A warning, an inaccessible page and a suspended registration are distinct observations, so the case record should not describe one as if it proves the others. Warning lists are one layer of protection rather than a replacement for careful handling of suspicious content. Reporters should not revisit a potentially harmful page simply to check whether a warning has appeared. Preserve evidence already available and avoid entering credentials or downloading files during a personal investigation. A warning can communicate risk, while a provider review considers whether content or a registration breaches the recipient's policies. These are different questions, with different evidence requirements. Describing their roles generically keeps the focus on the case and avoids implying a partnership or an endorsement by a particular service.

Platforms and other services

Where a platform or service is involved, a report should address the content or account within that recipient's control. Serious cases may be referred to competent authorities. Each recipient assesses its own responsibilities; Fraudpol acts as the reporting and coordination service, not as an authority issuing removal orders. The same principle applies when a reported site uses several services: each notice should identify the part the recipient can review. A payment service, a hosted platform and a network intermediary may control different accounts or content. Evidence about one role should not be stretched into an accusation about another. Where a recipient cannot remove the page itself, it may still have information relevant to a review, but that does not guarantee a referral or an outcome. Keep the request factual, explain what action is being asked for, and separate a received reply from a confirmed resolution.

Phishing takedown service: FAQ

Discuss your reporting needs

Share your company's incident-reporting requirements with the Fraudpol team, or submit a suspicious website through the report form.

Request managed takedown Explore Company plan →