Reference · The provider directory

Every phishing takedown provider depends on somebody else’s decision.

Two different things get called a provider here. One is the vendor you engage to file the notice. The other is the counterparty holding the content — a host, a registrar, a platform — and only the second of the two can remove anything. So the useful question about the first is not how hard it tries. It is which counterparties it can actually reach, what each of them has the power to do, and what happens when one of them says no. This page publishes all three. It is the reference behind the takedown service, and it is deliberately written to be checked rather than believed.

Provider relationships

Provider types, all published below

Unlimited

Takedowns in the licence, subject to fair use

Fair use is the boundary: notices filed for your own marks, domains, applications and data, at volumes consistent with the estate under monitoring — not a channel for filing on behalf of third parties. There is no monthly allowance to spend down and no per-notice charge, so nobody on your side has to decide whether an impersonation is worth reporting.

The directory

Twelve types, and what each of them can actually do

Providers are not interchangeable. They remove different things, they accept different evidence, and several of them remove nothing at all — they only cut or obscure the route to it. Beneath every row is where that class of notice fails, because a directory that lists only what works is a brochure.

No individual company is named here, and that is a decision rather than an omission. A list of company names is out of date the first time one of them is acquired, and it hands the people we file against a map of the desks to work around. What a reader can act on is the class of counterparty and the limit of what it is able to do, which is what every row below states. The full reasoning is at the foot of the page.

The twelve provider types behind 86 takedown relationships. Counts are relationships held in the dispatcher configuration as of August 2026, not providers reachable in theory — see the derivation at the foot of this page.
Provider type	Relationships	What removal means at this layer	What the notice has to carry
Hosting provider	12	The file, the page, the site or the account, on the machine actually serving it. This is the only layer at which content stops existing.	The live URL, timestamped captures of the abusive page, and the authorisation letter naming the mark or the data being misused.
Where it fails: an abuse-tolerant host reads the notice and does nothing, and its own process has no appeal above itself. Bulletproof hosting is the extreme of that, and it is the reason the ladder further down this page exists at all.
Social platform	10	The impersonating profile, page, group, post or paid advert — and, on repeat abuse, the account publishing them.	Proof of identity or registered rights, filed through the platform’s own impersonation or brand channel rather than a general abuse address.
Where it fails: platform policy is the operative law here, not trademark law. An account that parodies rather than impersonates, or that copies a tone without copying a mark, is regularly held to be within policy — and the reviewer applying that policy is not a lawyer.
Registrar	9	Nothing on the page. It suspends, locks or places the domain registration on hold, which takes the name out of service and leaves the content where it is.	Proof of the mark, the current WHOIS or RDAP record, and evidence of abusive use — resemblance on its own is not a ground.
Where it fails: a parked lookalike serving nothing yet is the hardest class of case in this table, because the registrar is being asked to act on intent rather than on conduct. We say so when the request is raised, not once the case has stalled.
Cloud storage	7	The exposed object or bucket, or the public access to it.	The address of the exposed object, and evidence that the data sitting inside it belongs to you.
Where it does not apply at all: when the bucket is yours. That is a configuration change you can make immediately, and a notice would only tell you about something you already control — so the finding says so instead of opening a case against your own provider.
App store	7	The store listing. Where one publisher does it repeatedly, the developer account itself.	An attestation from the rights holder, the identifier of the offending listing, and a pointer to the real application being copied.
Where it fails: a cloned application distributed as a sideloaded package never enters a store, so no store notice reaches it. Those cases belong to whichever host is serving the file, one row up.
CDN and reverse proxy	6	Rarely the content. It can terminate the route, and in some processes it identifies the origin its network is fronting.	The proxied hostname and evidence that the abuse is being served through that network.
Where it fails as a destination: it was never one. The usual value of a notice here is the origin it discloses, which means a successful case at this layer ends by opening another at the layer that can actually delete something.
Paste and forum site	6	The paste, the thread, the post or the attachment.	The identifier of the paste or thread, and evidence that what it holds originated with you.
Where removal is not remediation: this content is routinely mirrored before it comes down. Taking it down narrows the audience, it does not un-publish anything — so the revocation or rotation is the work, and the notice is the tidying up afterwards.
Developer tooling and registries	6	Packages, container images and build artefacts uploaded under a namespace built to be mistaken for yours.	Enough to locate the artefact exactly — registry, namespace, name, version — together with the namespace claim or the mark it trades on.
Where it fails: a package that is merely a near-miss of your name and does nothing malicious. Registries generally act on demonstrated harm or on a namespace claim, and similarity alone is neither.
Marketplace	6	Listings that counterfeit or infringe, and the seller account behind them once the pattern repeats.	A registration number, the identifier of the listing complained of, and the genuine product it is passing itself off as.
Where it fails: an unregistered mark. Most marketplace rights programmes are built around a registration number and have no intake path for a brand that has never filed one, however well known it is.
Code platform	6	The repository, file, gist or fork holding source, configuration or secrets that were never meant to be public.	Ownership of the material and, where a secret is involved, an indication of what that secret unlocks.
Where removal is not the remedy: a secret that has been public is compromised whether or not the repository ever comes down, and a fork can outlive the parent it was taken from. Rotation is the remediation. The notice only limits who else stumbles across it.
Search engine	5	Nothing. It deindexes the URL, so the content stops being found through search.	The address, the search that returns it, and the reference of the abuse case opened against whoever is actually serving it.
Deindexing is routinely reported upward as a takedown. It is not one: the page is untouched at its own address and stays reachable by anyone holding the link — which is exactly how a phishing page distributed by email is reached in the first place.
Other	6	Varies. Browser and phishing blocklists sit here: nothing comes down, but an interstitial stands between the reader and the page for as long as the removal itself is unresolved.	Varies by provider.
The twelfth type collects the counterparties that will not sit in any of the eleven above. It is labelled a remainder rather than given a name of its own, because the alternative is a directory that reads tidier than the internet actually is.

The twelve provider types behind 86 takedown relationships. Counts are relationships held in the dispatcher configuration as of August 2026, not providers reachable in theory — see the derivation at the foot of this page.

Hosting provider

Relationships: 12
What removal means at this layer: The file, the page, the site or the account, on the machine actually serving it. This is the only layer at which content stops existing.
What the notice has to carry: The live URL, timestamped captures of the abusive page, and the authorisation letter naming the mark or the data being misused.

Where it fails: an abuse-tolerant host reads the notice and does nothing, and its own process has no appeal above itself. Bulletproof hosting is the extreme of that, and it is the reason the ladder further down this page exists at all.

Social platform

Relationships: 10
What removal means at this layer: The impersonating profile, page, group, post or paid advert — and, on repeat abuse, the account publishing them.
What the notice has to carry: Proof of identity or registered rights, filed through the platform’s own impersonation or brand channel rather than a general abuse address.

Where it fails: platform policy is the operative law here, not trademark law. An account that parodies rather than impersonates, or that copies a tone without copying a mark, is regularly held to be within policy — and the reviewer applying that policy is not a lawyer.

Registrar

Relationships: 9
What removal means at this layer: Nothing on the page. It suspends, locks or places the domain registration on hold, which takes the name out of service and leaves the content where it is.
What the notice has to carry: Proof of the mark, the current WHOIS or RDAP record, and evidence of abusive use — resemblance on its own is not a ground.

Where it fails: a parked lookalike serving nothing yet is the hardest class of case in this table, because the registrar is being asked to act on intent rather than on conduct. We say so when the request is raised, not once the case has stalled.

Cloud storage

Relationships: 7
What removal means at this layer: The exposed object or bucket, or the public access to it.
What the notice has to carry: The address of the exposed object, and evidence that the data sitting inside it belongs to you.

Where it does not apply at all: when the bucket is yours. That is a configuration change you can make immediately, and a notice would only tell you about something you already control — so the finding says so instead of opening a case against your own provider.

App store

Relationships: 7
What removal means at this layer: The store listing. Where one publisher does it repeatedly, the developer account itself.
What the notice has to carry: An attestation from the rights holder, the identifier of the offending listing, and a pointer to the real application being copied.

Where it fails: a cloned application distributed as a sideloaded package never enters a store, so no store notice reaches it. Those cases belong to whichever host is serving the file, one row up.

CDN and reverse proxy

Relationships: 6
What removal means at this layer: Rarely the content. It can terminate the route, and in some processes it identifies the origin its network is fronting.
What the notice has to carry: The proxied hostname and evidence that the abuse is being served through that network.

Where it fails as a destination: it was never one. The usual value of a notice here is the origin it discloses, which means a successful case at this layer ends by opening another at the layer that can actually delete something.

Paste and forum site

Relationships: 6
What removal means at this layer: The paste, the thread, the post or the attachment.
What the notice has to carry: The identifier of the paste or thread, and evidence that what it holds originated with you.

Where removal is not remediation: this content is routinely mirrored before it comes down. Taking it down narrows the audience, it does not un-publish anything — so the revocation or rotation is the work, and the notice is the tidying up afterwards.

Developer tooling and registries

Relationships: 6
What removal means at this layer: Packages, container images and build artefacts uploaded under a namespace built to be mistaken for yours.
What the notice has to carry: Enough to locate the artefact exactly — registry, namespace, name, version — together with the namespace claim or the mark it trades on.

Where it fails: a package that is merely a near-miss of your name and does nothing malicious. Registries generally act on demonstrated harm or on a namespace claim, and similarity alone is neither.

Marketplace

Relationships: 6
What removal means at this layer: Listings that counterfeit or infringe, and the seller account behind them once the pattern repeats.
What the notice has to carry: A registration number, the identifier of the listing complained of, and the genuine product it is passing itself off as.

Where it fails: an unregistered mark. Most marketplace rights programmes are built around a registration number and have no intake path for a brand that has never filed one, however well known it is.

Code platform

Relationships: 6
What removal means at this layer: The repository, file, gist or fork holding source, configuration or secrets that were never meant to be public.
What the notice has to carry: Ownership of the material and, where a secret is involved, an indication of what that secret unlocks.

Where removal is not the remedy: a secret that has been public is compromised whether or not the repository ever comes down, and a fork can outlive the parent it was taken from. Rotation is the remediation. The notice only limits who else stumbles across it.

Search engine

Relationships: 5
What removal means at this layer: Nothing. It deindexes the URL, so the content stops being found through search.
What the notice has to carry: The address, the search that returns it, and the reference of the abuse case opened against whoever is actually serving it.

Deindexing is routinely reported upward as a takedown. It is not one: the page is untouched at its own address and stays reachable by anyone holding the link — which is exactly how a phishing page distributed by email is reached in the first place.

Other

Relationships: 6
What removal means at this layer: Varies. Browser and phishing blocklists sit here: nothing comes down, but an interstitial stands between the reader and the page for as long as the removal itself is unresolved.
What the notice has to carry: Varies by provider.

The twelfth type collects the counterparties that will not sit in any of the eleven above. It is labelled a remainder rather than given a name of its own, because the alternative is a directory that reads tidier than the internet actually is.

Detection is what feeds this table. Impersonating domains and look-alike registrations arrive from domain monitoring, impersonating profiles and cloned applications from brand protection, and exposed code, secrets and objects from data exposure monitoring. A notice with no confirmed finding behind it is a letter, not a case.

The route

Where a case sits, and where it can stop

A takedown is not a sequence with a guaranteed end. It is a machine with several exits, and three of the exits leave the content exactly where it was. Drawing it as a numbered list of steps would be the more flattering choice and the less true one.

The route a case travels between us and a provider, and the points at which it closes
State	Status	What it means	What happens next
Detected	Active	An analyst has confirmed a live impersonation, leak or abusive host.	Evidence assembled
Evidence assembled	Active	Captures, WHOIS, the hosting chain and proof of mark are packaged into a filing.	Notice filed
Notice filed	Active	The notice is lodged with the registrar, host or platform abuse channel.	Provider acknowledged
Provider acknowledged	Active	The provider has confirmed receipt and opened a case reference.	Content removed · Takedown denied · Counter notice received · Escalated
Content removed	Terminal — content removed	The content is down and removal has been re-checked from outside our network.	Nothing. The case closes in this state.
Takedown denied	Terminal — closed without removal	The provider rejected the notice on its own policy grounds.	Nothing. The case closes in this state.
Counter notice received	Terminal — closed without removal	The registrant disputes the claim and the matter passes to your counsel.	Nothing. The case closes in this state.
Escalated	Active — returns to an earlier state	Re-aimed at the registry, the upstream provider or a CERT contact.	Notice filed (re-filed one level up)

The route a case travels between us and a provider, and the points at which it closes This diagram and the ledger below are two views of one pipeline, and where they differ is worth naming rather than leaving a reader to find. Here is the route, drawn with the escalation loop in it. There is the vocabulary the console displays, in which that loop is folded into whichever open status names the desk a case is sitting on. Both agree on the endings. Dismissed exists only in the ledger: nothing was dispatched, so there is no edge for it to travel along.

The status vocabulary

Eight statuses, four of them terminal, three of those four not a removal

A request is never in an implied state. It carries one of eight, and four of the eight are endings. Takedown denied and Counter notice received appear here by name, in the same table as Completed and at the same weight, because the states a vendor leaves out are the ones that describe what its pipeline actually does. Put that to any vendor in this category as a question about their own records rather than about their headline figure: which of these did our cases close in, and how many.

The published status vocabulary for a takedown request, and what each status says about which party currently holds the decision.
State	What it means	What follows
Requested	The request exists and the attestation behind it has been captured. The order in which counterparties will be approached has not been settled yet.	Nothing is dispatched until that chain is known. Filing at the wrong layer first spends a case rather than progressing it, and some providers do not take a second bite.
Ongoing	A notice is with at least one provider, and the case now moves at the speed of that provider’s own process.	Notice, reminder, escalation, internal alert. Priority tightens the cadence; it does not skip a step, and it does not move anyone up a provider’s queue.
Pending with hosting	The case has reached the layer that actually serves the content, usually because a routing or registration layer named it.	The host now holds the only decision that removes anything. Escalation continues if it goes quiet; the case does not settle because it changed hands.
Awaiting response	The notice is filed, the provider has it, and the provider has not ruled.	The delay is the provider’s, and the record attributes it to the provider rather than leaving it looking like ours.
Completed Terminal	The content is gone from the address it was served at.	Before this status is written, the address is fetched again from a network that is not ours. A provider’s reply saying the content is down is a claim, not a verification.
Takedown denied Terminal	The provider read the notice, applied its own policy, and refused it.	Terminal, with the content still serving. The record closes stating the refusal and the grounds given for it. Filing at the next layer down this page is a NEW case with its own record — never a quiet re-queue of this one, which is how a refusal would otherwise disappear.
Counter notice received Terminal	The registrant or account holder has filed a formal objection, and most provider processes restore or retain the content for as long as that dispute is open.	Terminal for us. The question has become legal rather than operational: we hand over the case file — everything filed, every reply — to your counsel and stop.
Dismissed Terminal	No notice was ever dispatched. The finding did not meet the bar for enforcement, so no provider was ever asked.	Terminal, and it never enters a removal count. Without this status an unenforceable finding would either sit open indefinitely or, worse, be reported as one that closed.

Key

Open, with us
Open, with the provider
Closed — content removed
Closed — filed and refused
Closed — never filed
TerminalNo state follows this one

The ladder

When one layer refuses, the next one has less power than the last

The order below is by power to remove, descending — which is the ordering that decides where a notice goes first, and the reason escalation is a consolation rather than a promotion. The first rung and the third are the two filings written up in full elsewhere: a website takedown, aimed at the layer that holds the files, and a domain takedown, aimed at the registration that publishes the name. Two things are worth stating plainly before you read it. Not every rung is one of the twelve types above: the ones that sit outside the directory are escalation routes we take, not standing relationships we hold. And crossing a rung after a refusal opens a new case with its own record — the denied one closes denied, so that a refusal cannot be re-queued into invisibility.

Can delete

The layer that holds the content

The origin host, or the platform’s own rights channel where the content lives inside a platform. This is the only rung at which the material ceases to exist rather than becoming harder to reach, so it is the first notice wherever the responsible party is known.
Can route

The layer that carries traffic to it

A CDN or reverse proxy in front of the origin. It removes nothing. It is filed with to establish the route and, in some processes, to obtain the origin it is fronting — at which point the case returns to the rung above holding a real address.
Can withdraw the name

The layer that publishes the name

The registrar, acting against the domain registration rather than against the page. The content survives at its address; the name stops resolving to it. For a domain-shaped abuse whose host will not act, this is often the only rung left with any leverage.
Sits above the directory

The layer above the registrar

The registry, the upstream network provider, or a national CERT contact. Grounds narrow and processes lengthen at every step up, and these are escalation routes rather than standing relationships — which is why they are not their own type in the table above.
Can only warn

The layer that cannot remove anything

Browser and phishing blocklists, and search deindexing. The content stays exactly where it is. This rung is worth reaching because it cuts reach while a removal is still being pursued, and worth being honest about because it is the one most frequently reported to a board as a takedown.

Choosing a provider

Six questions to put to any phishing takedown provider

Everything above describes counterparties, states and order. Turned around, the same material is a way to test a vendor — this one included. Not one of the six asks for a headline figure, because a figure is the easiest thing in this category to produce and the hardest to check. Each asks instead for something a vendor either holds in its records or does not, and each has a shape of answer that tells you which.

Six questions a buyer can put to any takedown vendor, what each answer establishes, and the shape of answer that means it has not been established.
The question	What the answer establishes	The shape of an answer that establishes nothing
Which classes of counterparty do you hold a route to?	A notice travels exactly as far as the desk that reads it. Reach is by class — hosting, registrars, social platforms, app stores, marketplaces, package and code registries — and strength in one class does nothing for an impersonation sitting in another.	A headline number of takedowns performed, with no statement of the classes of provider it holds a standing route into.
Where does the first notice go, and what decides that?	The order is not a preference. The layer holding the files can delete; a registrar can only withdraw the name; a proxy can do neither. A vendor that cannot say how it resolves the responsible party is guessing at which door to knock on first.	“We file with everyone at once.” Simultaneous filing spends relationships on desks that were never able to act on that case.
What are you counting when you count a takedown?	Deindexing, blocklisting and an interstitial all cut reach without removing anything. Where they sit inside the same figure as a deletion, the figure is adding up two different events and reporting them as one.	A single removal count with no split by what actually happened to the content, and no line at all for the findings on which no notice was ever filed.
When a provider refuses, what happens to the case?	A refusal is an outcome, so the answer should be able to name the state such a case closes in and produce the grounds the provider gave for it. Where a refusal is instead folded into the next filing, the removal count survives and the refusal does not.	“We escalate until it comes down.” Escalation describes the effort; the question is what the record says about the case that never came down.
What must be true before a notice goes out, and before you call a case done?	At the front: someone authorised attests to the abuse, and the evidence is captured as artefacts rather than as links that may be dead by the time the desk opens them. At the back: the address is re-checked from outside the vendor’s own network before anything is marked complete.	A provider’s reply treated as proof of removal. That reply is a claim about the content, made by the party that was asked to remove it.
Show me a case that ended without a removal.	The whole of it: what was filed, to whom, what came back, and the state it closed in. A pipeline that is only visible when it works is a pipeline nobody can audit.	An offer to walk you through a success instead. The record worth reading is the one where a desk said no.

Six questions a buyer can put to any takedown vendor, what each answer establishes, and the shape of answer that means it has not been established.

Which classes of counterparty do you hold a route to?

What the answer establishes: A notice travels exactly as far as the desk that reads it. Reach is by class — hosting, registrars, social platforms, app stores, marketplaces, package and code registries — and strength in one class does nothing for an impersonation sitting in another.
The shape of an answer that establishes nothing: A headline number of takedowns performed, with no statement of the classes of provider it holds a standing route into.

Where does the first notice go, and what decides that?

What the answer establishes: The order is not a preference. The layer holding the files can delete; a registrar can only withdraw the name; a proxy can do neither. A vendor that cannot say how it resolves the responsible party is guessing at which door to knock on first.
The shape of an answer that establishes nothing: “We file with everyone at once.” Simultaneous filing spends relationships on desks that were never able to act on that case.

What are you counting when you count a takedown?

What the answer establishes: Deindexing, blocklisting and an interstitial all cut reach without removing anything. Where they sit inside the same figure as a deletion, the figure is adding up two different events and reporting them as one.
The shape of an answer that establishes nothing: A single removal count with no split by what actually happened to the content, and no line at all for the findings on which no notice was ever filed.

When a provider refuses, what happens to the case?

What the answer establishes: A refusal is an outcome, so the answer should be able to name the state such a case closes in and produce the grounds the provider gave for it. Where a refusal is instead folded into the next filing, the removal count survives and the refusal does not.
The shape of an answer that establishes nothing: “We escalate until it comes down.” Escalation describes the effort; the question is what the record says about the case that never came down.

What must be true before a notice goes out, and before you call a case done?

What the answer establishes: At the front: someone authorised attests to the abuse, and the evidence is captured as artefacts rather than as links that may be dead by the time the desk opens them. At the back: the address is re-checked from outside the vendor’s own network before anything is marked complete.
The shape of an answer that establishes nothing: A provider’s reply treated as proof of removal. That reply is a claim about the content, made by the party that was asked to remove it.

Show me a case that ended without a removal.

What the answer establishes: The whole of it: what was filed, to whom, what came back, and the state it closed in. A pipeline that is only visible when it works is a pipeline nobody can audit.
The shape of an answer that establishes nothing: An offer to walk you through a success instead. The record worth reading is the one where a desk said no.

Five of the six are answered here for ShadowMap: the reach in the directory, the filing order and the refusal rule on the ladder, the counting in the status vocabulary, and the two sets of conditions in dispatch discipline below. The sixth is the one no public page can answer — any takedown record names the brand being impersonated, which is why none is published here — so that one belongs in a walk-through of the console rather than on a page.

Teams filing their own notices can put the same six to their own process. The notice templates, capture checklist, filing log and counter-notice runbook that go with the desks in the directory are in the takedown evidence pack.

Dispatch discipline

What has to be true before a notice leaves, and before a case is allowed to close

Holding 86 provider relationships is worth very little if the traffic sent through them is careless. Everything below exists because an abuse desk that stops reading your mail is a relationship you have spent, and it does not come back.

01 Before dispatch

Nothing is sent on a detection alone

A human decision, and an attestation: A person raises the request from the finding and attests that your organisation is authorised to act and that the content is genuinely abusive. The request cannot be created without it, and that attestation travels with the notice.
Evidence captured, not linked: Captures of the live page, the resolving records, the hosting chain and the proof of mark are packaged into the filing and retained with the case. A URL that may be gone tomorrow is not evidence; the artefact taken at the time is.
The right counterparty, rate-limited: Responsible providers are resolved into the ladder above before anything is dispatched, and dispatch is rate-limited per provider so no single customer’s queue floods an abuse desk. That limit is one of the reasons no timing figure appears anywhere on this page.

02 Before closure

A provider’s reply is not a verification

Liveness, checked independently: A target that is already dead is not re-notified, and a confirmation of removal is not taken on trust. The address is re-checked from outside our own network before Completed is written to the case.
Drift, followed: Hosting moves mid-case: the same content reappears behind a different provider while the original notice is still open. The case follows the content rather than the address it was first filed against, which is often what turns one notice into three.
Refusals, recorded as refusals: Where a provider declines, the case closes as Takedown denied with the reply attached and the content reported as still live. Every state change is on the record, which is what makes the trail usable as audit evidence rather than as a screenshot.

Derivation

How 86 and 12 are counted, and what will not be published beside them

Two numbers carry this page, so both of them get their working shown. Beside the working are the figures a takedown vendor is normally expected to lead with, and the reason neither of them appears anywhere above.

Provider directory — how the counts are derived, and what is left out As of August 2026

Eighty-six counts relationships, not companies with an abuse page. A relationship is a route that has actually carried a notice in production, and it takes one of three forms: an abuse mailbox somebody monitors, an authenticated abuse API, or a web form a named analyst fills in by hand.
Publishing an abuse address does not make a provider a relationship. A desk we have never filed through is excluded from the count, however prominently it advertises itself.
Twelve is what those relationships group into. Eleven are named categories; the twelfth is a remainder, and it is labelled as one rather than padded out to make the table look symmetrical.
The per-type distribution is re-derived from that configuration at every revision of this page rather than carried forward from the last one. Providers merge, change hands and rewrite their abuse processes, so an uncounted directory drifts without anyone noticing — which is why the as-of date sits on the figure itself and is repeated on the table.

Deliberately excluded

No completion time and no removal rate. Dispatch is deliberately rate-limited per provider, and the pace of a case depends on its type and its priority, so a single headline number would describe something other than the pipeline in front of you. What we commit to is contractual, and it belongs in an agreement that can be read in full.
No company names. Which abuse desks a takedown team uses, and by which channel, is the part worth gaming — and the people we file against are the ones who would. A type tells you what to expect from a notice; a logo only tells somebody else where to push.
No worked customer examples. Any takedown record identifies the brand being impersonated, which makes this the least publishable evidence we hold.
No claim to cover the internet. Eighty-six relationships are a directory, not a map. Where the abuse sits with a party we hold no route to, the notice goes to whatever channel that party publishes, and the record shows it went out cold rather than down a standing route.

The argument this page is the evidence for lives on the takedown service page: what a notice can reach, what no notice can reach, and why the exposure nobody can delete is still worth knowing about.

Common questions

Before you pick one

Which phishing takedown provider is best?

Best at what, and against whom — the question only becomes answerable once it is narrowed. A provider with deep reach into hosting and registrars will do very little about an impersonating profile inside a social platform, where that platform’s own rights channel is the only door there is. Start from where your impersonations actually sit, match those against the twelve classes of counterparty above, and put the six questions on this page to every vendor on the list. The one that can answer all six about its own records, including the cases that closed without a removal, is the one you can check rather than believe.

What is a takedown provider?

The phrase covers two different parties. The first is the vendor you engage: it prepares the notice, works out who is responsible, files, chases, and records what came back. The second is the counterparty that receives that notice — a host, a registrar, a social platform, an app store, a code registry — and only the second one is able to remove anything. Twelve types of that second kind are published above, with what each type can do and what its notice has to carry.

How long does a phishing takedown take?

The counterparty sets the pace, not the notice. Three things move it: which layer holds the content, since a host can delete and a registrar can only withdraw the name; the process that particular provider runs and the queue already in front of yours; and whether the first filing reached the layer that could act or has to be re-filed a rung down. While a case is waiting it carries a published status naming which side holds the decision, so the delay is attributed rather than absorbed.

Is a search engine deindex a takedown?

No, and the difference decides what you are buying. A search engine drops the address from its results; the content is still served at that address to anyone holding the link, and a phishing page is reached from an email rather than from a search. Browser and blocklist warnings behave the same way — an interstitial stands in front of the page while the page itself continues to be served. Both are worth having while a removal is pursued. Only the layer holding the files ends it.

Can we file takedowns ourselves?

Yes, and many teams do exactly that. The directory above is the part that saves the most time: it says which class of desk holds the power in a case like yours and what its notice has to carry, so the first filing is not spent finding that out. What a service adds is the chasing, the route to take when the first desk declines, and a record of both that outlives the case. Where volumes are low and the impersonations sit in one or two places, filing them yourself is a reasonable answer.

Find out which of these layers your exposure is sitting behind

One apex domain, and a written snapshot of the domains, sites and accounts trading on your name — separated into the ones a notice can reach and the ones it cannot.

Request an exposure snapshot The takedown service