How Fast Do Phishing Sites Come Down? We Timed Our Takedowns

TL;DR — We timed the phishing takedowns PhishEye filed between June and October 2026, from the first abuse notice to the case being recorded as removed. For every 100 phishing sites we reported, 73 came down, at a median of 47 hours after our first notice. 87 in 100 cases got a reply, usually an automatic ticket receipt within a minute; only 45 in 100 ever got a reply that looked like a person. Sites behind Cloudflare came down sooner than sites that weren't (median 28 h against 48 h), though a slightly smaller share of them were removed (71 against 76 in 100). The summary table is free to download.

About this data. These are PhishEye's own takedown records, not a survey or a vendor claim. Each case is one phishing site we asked registrars, hosts or platforms to remove: just over half were filed by PhishEye analysts against live campaigns on behalf of the impersonated brands, the rest by customers through the PhishEye platform. We timed removal with hourly liveness checks that need two consecutive "down" results, so timings are accurate to about one or two hours. We report shares, rates per 100 cases, medians and 75th percentiles, and we do not publish absolute case counts. The cases are the ones we chose to pursue, not a random sample, so read the figures as what happened on our cases. The methodology section has the definitions.

Why we measured this

Every brand protection vendor says its takedowns are fast. Very few publish the clock. The numbers that do circulate tend to be single best cases, or service-level promises that start when the vendor sends a request rather than when the site stops working.

We run takedowns every day, and our platform records every step: when a notice went out, who answered, what they said, and when the site actually stopped resolving. So instead of quoting a promise, we exported the record. This report is that export, reduced to rates and medians.

Most takedowns work, but it takes about two days

For every 100 phishing sites we reported, 73 came down. The median was 47 hours from our first notice to the case being recorded as removed. The site itself usually went dark a little earlier: the first failed liveness check came a median of 34 hours after the first notice. Those are medians of two different events across all cases; on a typical removed case, the first failed check came about two hours before the removal was recorded.

The spread matters as much as the middle. One removal in four took longer than 133 hours, about five and a half days. For a phishing kit collecting card numbers or one-time codes, that tail is where most of the damage happens.

The other 27 in 100 were not recorded as removed by the end of the window. Some were still live, and some had gone quiet in ways our checker could not confirm, such as a host that cloaks against data-centre traffic. We count those as not removed rather than guess.

What to do with this: plan for a two-day removal, not a two-hour one, and protect users in the meantime. Alongside our takedowns we also reported the URLs to blocklists: Google Safe Browsing, Netcraft, the APWG and PhishTank. A browser warning can protect users before the removal lands.

A reply is not a response

Abuse desks are good at answering. 87 in 100 cases got a reply, and the first reply came a median of under a minute after the notice. That speed is the giveaway: three-quarters of first replies landed within two minutes, which is a ticketing system, not a person. Part of that is contractual: since 5 April 2024, ICANN's contracts require registrars and gTLD registries to confirm receipt of every abuse report, so an instant receipt is the floor, not a sign of action.

We classed every reply we received. About 7 in 10 were automated: receipts ("your report has been received"), auto-responders, or anything that arrived within 10 minutes of the notice. Only 45 in 100 cases ever got a reply that looked like a person, and that took a median of 3.8 hours (75th percentile: 23 hours).

The gap between the two bars is the trap. A dashboard that counts "provider responded" will show 87% and look healthy. The number that matters is whether the site stopped working, and that is 73%, arriving days later.

What to do with this: never close a case on a reply. Close it on a liveness check that shows the site is gone, and keep re-checking for a few days, because kits come back on the same infrastructure.

What abuse desks actually say

Since July 2026 our platform has sorted every incoming reply into a category, so we can look past "a reply arrived" to what the reply said.

Three things stand out:

• Most replies say nothing yet. A third are plain acknowledgements, and a quarter are auto-replies or out-of-office messages. Together that is roughly six replies in ten that confirm receipt and nothing more.
• One reply in six asks for more information before the provider will act. Every one of those round trips puts the case back in a queue while the site stays up.
• Only one reply in seven says the problem is resolved, even though 73 in 100 sites came down. Most removals happen silently: the site stops resolving and nobody writes back. A team that waits for a "resolved" email will undercount its own wins and chase cases that are already closed.

What to do with this: put the evidence in the first notice. Include the full URL, a timestamped screenshot, what the page impersonates and why it is malicious, so the "please send more information" reply never needs to happen.

Provider by provider

We sent notices to dozens of registrars, hosts and platforms. The six we contacted most often are reported separately below; everyone else is pooled.

Read this table carefully. Removal is shared credit: a typical case involved about two providers (a registrar and a host, say), and when the site came down we cannot tell which one acted. Each provider's figures cover every case it was contacted on, timed from its first notice. A provider with a slow median may simply have been the second party to act, after someone else had already pulled the site.

What stood out, provider by provider:

• NameSilo removed every case we sent it, with the shortest median (25 hours) and the tightest tail (75th percentile 40 hours). It was also the only named provider where most cases (80%) got a human reply, a median of 3.8 hours after the first notice. Most of our reports to NameSilo went through its web form rather than email.
• Google was the provider we contacted most often, through its abuse addresses. Four in five of its cases got an automatic acknowledgement, and none got a reply that our heuristic classed as human; a fast human answer would be counted as automated. 80% of those sites came down, at a median of 88 hours. Google was usually one of several parties on a case, so that time also reflects how quickly the others acted.
• Cloudflare acknowledged every case instantly, and about a quarter (24%) got a human reply, a median of 32 minutes after the first notice. Two in three of those sites were removed, at a median of 47 hours.
• Name.com saw 88% of its cases removed, at a median of 38 hours. Human replies were rare and slow: a quarter of cases, a median of more than five days after the notice.
• Tencent Cloud answered more than four in five of its cases with what our triage labelled a rejection, in practice "not hosted here" or "not our customer". Yet 91% of those sites came down, at a median of 29 hours. That is shared credit in action: most likely another party removed them.
• Freename replied by email on fewer than one case in ten, despite automatic follow-ups. Every one of those sites still came down, at a median of 136 hours (5.7 days). With so few replies we cannot tell whether Freename or another party acted, which is exactly the shared-credit limit described above.

Email is also where reports go quiet. Counting each email notice separately, here is how often one got any reply at all, automated or not:

The pooled smaller providers answered roughly one email in three. Freename's email notices got a reply fewer than one time in thirty, yet its cases still closed, which is the strongest argument in this report for reporting to every party in parallel.

What to do with this: report to the registrar and the host on day one, rather than one after the other, and use a provider's web form or API where one exists. NameSilo, which we mostly reported through its web form, was the fastest named provider in our data, and parallel reporting is the most likely reason the Tencent and Freename cases still closed.

On our cases, sites behind Cloudflare came down sooner

The usual complaint about Cloudflare is that its proxy hides where a phishing site is really hosted, which slows takedowns. On our cases, it went the other way.

Sites fronted by Cloudflare came down at a median of 28 hours, against 48 hours for sites that were not, with a much shorter tail (75th percentile 87 hours against 148). The Cloudflare-fronted cases also got more human attention: two in three got a probably-human reply, a median of 2.1 hours after the notice, against fewer than four in ten at 9.6 hours.

We would not over-read this. The Cloudflare-fronted group is the smaller of the two, and those cases were not a random slice: which campaigns we pursued, and when, shapes the result. Cloudflare documents two things that may help. Its abuse process forwards a complaint to both the website operator and the hosting provider, so one report reaches two parties who can act. And it asks its customers to respond to abuse reports within 24 hours. Once it confirms a phishing page, Cloudflare also shows visitors a warning page, but that warning does not count as removal in our data: a case is only marked removed when the site's DNS is gone or the host has suspended it. The sample cannot tell us which of these explains the gap. The finding is still worth stating plainly, because it contradicts a common assumption: on our cases, being behind Cloudflare did not slow removal down, although a slightly smaller share of those sites were removed (71 in 100 against 76).

This comparison is not the same measure as the Cloudflare row in the provider table. That row covers every case on which we contacted Cloudflare, including a few where it was the registrar rather than the proxy, and times each one from Cloudflare's own first notice. The comparison here covers sites that sat behind Cloudflare, timed from the case's first notice, whichever party acted.

For where phishing is hosted in the first place, see our companion analysis, Where Phishing Lives in 2026, the hosting section of our phishing statistics report, and our investigations into Cloudflare Drop abuse and a SharePoint kit on Cloudflare Workers.

How these numbers compare

There is no single industry clock for takedowns, because everyone starts and stops it in a different place. Set side by side, the published figures still tell a consistent story.

• Registrars and TLDs, measured independently. The NetBeacon Institute (formerly the DNS Abuse Institute) measures phishing and malware domains across registrars and TLDs, separately from the reports filed through its NetBeacon Reporter service. In its September 2026 analysis of July 2026 data, 58% of unique domains had a median mitigation time of 24 hours or less, and mitigation rates were 84% for maliciously registered domains against 52% for compromised websites. Our 47-hour median is slower, but it measures something wider: hosts and platforms as well as registrars, and every case to the point where the site stopped working.
• ICANN contract enforcement. ICANN's contracts have required registrars and gTLD registries to promptly mitigate DNS abuse, explicitly including phishing, since 5 April 2024. In its two-year review, ICANN Compliance reports nearly 530 investigations between April 2024 and April 2026; about 66% of those it resolved led registrars or registries to act, and more than 25,000 abusive domains mitigated. The older 2013 Registrar Accreditation Agreement already required registrars to "take reasonable and prompt steps to investigate and respond appropriately to any reports of abuse."
• How fast victims arrive. A large academic study, Sunrise to Sunset (Oest et al., USENIX Security 2020), found the average phishing attack spans 21 hours from the first victim visit to the last, and that 37.73% of victim traffic arrived after the attack had already been detected. Against that, a 47-hour removal mostly arrives after the attack has done its work, which is why blocklisting in parallel matters.
• How long phishing domains survive after detection. A 2025 study of 690,502 phishing domains over 39 months, Lim et al. (a preprint), reports that phishing domains remain accessible for an average of 11.5 days after detection. Detection alone does not take a site down.
• Vendor claims. Published takedown times from vendors range widely, partly because the clock is defined differently. Netcraft, for example, states a median takedown time of 33 minutes for phishing sites, without saying on that page when its clock starts or stops. We publish our method below so our figures can be compared like for like.

What this means for brand and security teams

1. Measure removal, not replies. A provider "responding" tells you almost nothing: 87 in 100 of our cases got a reply, mostly automated, and 73 in 100 were removed. Track the time until the site stops resolving.
2. Expect days, and protect users meanwhile. The median was two days, and the slowest quarter of removals took more than five. Submit every URL to Google Safe Browsing and the other blocklists at the same time as the takedown.
3. Report to everyone at once. A typical case involved two providers. Sending the registrar and the host notices in parallel is the most likely way cases closed where one party deflected or never answered.
4. Use forms and APIs where they exist. NameSilo, which we mostly reported through its web form, was the fastest named provider in our data, and a form makes you supply the evidence a desk needs up front.
5. Follow up on a schedule. More than a third of the notices we sent were automatic follow-ups. They keep a case moving with desks that never answer the first notice, and some never answer at all.

If you would rather not run this loop yourself, this is what the PhishEye phishing takedown service does, with automated takedowns handling the notices, follow-ups and liveness checks. For the manual route, our guide on how to take down a phishing website walks through each report.

Methodology and limitations

• Population. PhishEye takedown cases whose first notice went out between 22 June and 19 October 2026. We excluded cases from internal test accounts and deactivated accounts, and cases where no notice was ever sent (duplicates and drafts). We do not publish absolute case counts; every figure is a share, a rate per 100 cases, a median or a 75th percentile.
• Notice. An abuse email we sent, or a report submitted through a provider's web form or API. Automatic follow-ups count as notices but never move the "first notice" time.
• Removal. A case counts as removed when it was marked removed, in most cases by our liveness checker after two consecutive hourly checks found the site's DNS gone or the host suspended, and otherwise by an analyst. Times to removal cover removed cases only, and a removed case with no timestamp counts as removed but is left out of the timings. "Site first tested down" uses the earliest down signal instead, which ran a median of 2.1 hours ahead of the recorded removal.
• Human reply. A reply counts as automated if our triage labelled it an auto-reply, if it matched known auto-responder or receipt patterns, or if it arrived within 10 minutes of our notice. Everything else counts as probably human. This is a heuristic: a very fast human answer would be counted as automated, and a slow templated one as human.
• Providers. A provider is the company behind the recipient address or reporting form, with each company's addresses merged so it counts once. We report a provider separately only when we contacted it on at least 10 cases; the rest are pooled. Removal credit is shared between every provider contacted on a case.
• Behind Cloudflare. A case counts as behind Cloudflare when the hosting recorded at report time was Cloudflare, or when the case was routed through Cloudflare's abuse process because the site was proxied. The few IP-address cases had no hosting recorded and are left out of that comparison.
• Limitations. Per-provider figures rest on small samples and can move with a few cases. The cases are not random: they are the ones PhishEye chose to pursue, most of them filed by our analysts in July 2026 against active campaigns. Our liveness checker probes from cloud infrastructure, so a host that cloaks against data-centre traffic can look live when it is gone, which would understate removals. Medians and 75th percentiles are reported throughout, never means.

Sources

• PhishEye takedown records, cases with a first notice between 22 June and 19 October 2026 (this report).
• ICANN, 2013 Registrar Accreditation Agreement, section 3.18.
• ICANN, 2024 global contract amendments on DNS abuse (effective 5 April 2024), and the Contractual Compliance advisory on DNS abuse obligations (5 February 2024).
• ICANN, blog: two years of enforcing DNS abuse mitigation requirements (2 June 2026).
• NetBeacon Institute, monthly analysis, September 2026 (July 2026 data).
• Cloudflare, abuse approach (Trust Hub), and developer documentation on abuse report obligations and complaint types.
• Oest et al., Sunrise to Sunset: Analyzing the End-to-end Life Cycle and Effectiveness of Phishing Attacks at Scale, USENIX Security 2020.
• Lim et al., Registration, Detection, and Deregistration: Analyzing DNS Abuse for Phishing Attacks, arXiv:2502.09549 (2025 preprint).
• Netcraft, threat detection and takedown page (vendor claim).
• Google, Report a page to Safe Browsing.

Use this data

The headline, provider and Cloudflare figures are in a free summary table: takedown-speed-2026-summary.csv. The reply-content shares, email-notice reply rates and down-signal timings come from the same export but are not in the table. The text, charts and table are licensed CC BY 4.0: reuse them freely with a link to this page. To cite it:

PhishEye Threat Research, How Fast Do Phishing Sites Come Down? We Timed Our Takedowns, 30 October 2026. https://phisheye.com/blog/phishing-takedown-speed-2026

We plan to repeat this measurement as more cases accumulate, so the provider-level figures rest on larger samples.

FAQ

How long does it take to take down a phishing site? In our 2026 data, a median of 47 hours from the first abuse notice to the site being recorded as removed. The site usually stopped resolving a little earlier, at a median of 34 hours. One removal in four took longer than 133 hours, about five and a half days.

What share of phishing takedown requests succeed? For every 100 phishing sites we reported between June and October 2026, 73 were removed. The rest were still live, or could not be confirmed as removed, at the end of the window.

Do registrars and hosts reply to phishing abuse reports? Usually, but mostly with automated receipts. 87 in 100 of our cases got a reply, typically in under a minute, yet only 45 in 100 got a reply that looked like a person, after a median of 3.8 hours. About 7 in 10 replies were automated.

Does Cloudflare slow down phishing takedowns? Not on our cases. Phishing sites behind Cloudflare were removed at a median of 28 hours, against 48 hours for sites not behind Cloudflare, though a slightly smaller share were removed (71 against 76 in 100) and the Cloudflare group is the smaller of the two.

Which registrar removes phishing sites fastest? Among the providers we contacted most often, NameSilo had the shortest median time to removal (25 hours) and removed every case we sent it. Removal credit is shared between every provider contacted on a case, so per-provider figures show what we observed on our cases, not a definitive ranking.

Should I report phishing to the registrar or the host? Both, at the same time. A typical case involved two providers, and parallel reports are the most likely way cases closed where one party deflected or never replied. Also submit the URL to Google Safe Browsing so browsers warn users while the takedown is pending.

---

About the authors

PhishEye Threat Research is the anti-phishing and digital-risk-protection team behind PhishEye. We run daily threat hunting across passive DNS, Certificate Transparency and newly registered domain feeds, operate the abuse-reporting pipeline that files takedowns with hosts and registrars, and publish first-hand investigations of live phishing operations, including IronToll, a 73-domain phishing-as-a-service campaign that Microsoft Threat Intelligence cites in its own research, and the AI-built GiftWatch bank kit. The cases in this report come from our own takedown pipeline: our analysts filed just over half of them, and every notice, reply and liveness check is in our records.

Spotted an error, or want to compare notes on takedown timing? Contact the team at [email protected].