Domain Takedown vs UDRP: Timelines and Why Requests Fail
A takedown is a request to somebody else, and that shapes everything about how it is written.
A domain takedown is a request to an intermediary, usually a hosting provider or a registrar, to stop serving or stop resolving a name that is being used abusively, decided under that intermediary's own terms rather than by a court.
This guide covers what each layer of the stack can remove, how long each typically takes, how an evidence package is assembled, where to send it, what changes behind a CDN, why requests stall, how a takedown differs from a UDRP or URS dispute in cost and outcome, and what a completed takedown does not establish.
What does a takedown actually remove?
The word suggests a single act, as though a domain were a thing that could be deleted. Nothing in the system works that way. A domain is a registration in a registry database, DNS records pointing somewhere, content on a server, a certificate vouching for the name, and a reputation held by browser and mail vendors. A takedown is an intervention at one of those layers, and the layer determines what stops and what carries on: a page that returns an error, a registration suspended so the name resolves nowhere, or a warning interstitial for most visitors. None of them deletes anything.
Almost every takedown is voluntary. An intermediary acts because the conduct breaches terms its own customer agreed to, or an obligation it owes to ICANN, not because anybody compelled it. A takedown is a persuasion exercise, which is why evidence matters more than assertion, why the wrong recipient simply does nothing, and why nobody can promise you an outcome.
Which layer should be asked?
Choose the layer by what you want stopped and how quickly. Content is the fastest and the shallowest. The registration is the deepest and the slowest. Reputation is the only one that works without anybody acting against their own customer.
| Layer | Who acts | What changes | What survives |
|---|---|---|---|
| Content | The host or platform holding the account | The page is removed or the account suspended | The registration, the name, the certificate |
| The registration | The sponsoring registrar | A hold is applied and the name stops resolving | The registration, until the hold is lifted |
| Name resolution | The DNS operator or a delivery network | Records are removed or service terminated | The registration and the content |
| The certificate | The issuing authority | The certificate is revoked and browsers warn | The name, the content, other certificates |
| The ending | The registry | Action under the registry's own policy | Little, but the bar is high and this is uncommon |
| Reach | Browser and mail filter operators | Visitors see a warning, messages are filtered | Everything. Nothing has been removed |
How long does a domain takedown take?
Nobody who sends a request controls the clock, and any service that quotes a guaranteed time is quoting the provider's behaviour, not its own. What exists is a set of published ranges from teams that do this daily. CloudSEK's knowledge base puts most compliant takedowns at 24 to 72 hours overall, and lists non-compliant or bulletproof hosts as extended or may fail. Netcraft's guide describes blocking phishing sites within minutes and removing malicious content within hours, and calls the UDRP a slower process taking several weeks. WIPO's guide says a case with no procedural issues should normally complete within two months.
The blocklist step is the only one measured in minutes, and it is the step most often skipped. The slow layers are slow because of what they decide: whether to act against a customer, or who is entitled to the name. Complete evidence, the right recipient and parallel submission shorten the fast layers. Nothing shortens a dispute.
| Layer | Published range | Reported by |
|---|---|---|
| Browser and gateway blocklists | Minutes to hours | CloudSEK; Netcraft: minutes |
| Hosting provider removal | 24 to 72 hours | CloudSEK; Netcraft: hours |
| Registrar suspension | 1 to 7 days | CloudSEK |
| UDRP decision | Normally within 2 months | WIPO; Netcraft: several weeks |
| URS registry lock | Within 24 hours of notice | ICANN URS procedure |
| Non-compliant host | Extended or may fail | CloudSEK |
What does the evidence package contain?
The package is the request. An abuse analyst deciding whether to act on their own customer needs to verify your claim from what you sent, and anything they have to find themselves is a reason to move on. Since April 2024 the registrar agreement uses the word actionable: enough evidence for the registrar to make a reasonable determination that the name is being used for DNS abuse. Assemble it from public records, dated at retrieval, with any snapshot from a passive scanning service rather than a visit.
- The registrable domain, written exactly, with any non-Latin or lookalike characters identified explicitly.
- The registration record: creation date, sponsoring registrar, status codes, and the timestamp of retrieval.
- DNS answers: address records, nameservers, and mail records where present, for example an address record pointing at 198.51.100.24.
- Certificate transparency entries: the issuer, the issue date, and every name on the certificate.
- Dated evidence of what the name served, from passive observation, and the message or advertisement that led people to it.
- Your own position: the domain you operate, the mark you hold if any, and a single, specific request naming the layer and the outcome.
How does the request travel, and where does it go?
Identify the intermediary from public records rather than guessing. The sponsoring registrar and its abuse contact come from the registry's RDAP record, or from ICANN's lookup tool. The network operating the address comes from the regional internet registry's records. The nameserver records name the DNS operator, and a delivery network in front of the origin is visible in the same place. Submit through the published channel, because a report through a sales form is re-routed at best. Inside, somebody checks who the reporter is, that the registration or account is theirs to act on, and that the conduct breaches something. The routes outside the registrar and the host are below, with the two ICANN addresses for when the registrar route stalls.
| Route | Address | What it does |
|---|---|---|
| Google Safe Browsing | safebrowsing.google.com/safebrowsing/report_phish | Warns Chrome and other browsers. Removes nothing. |
| Microsoft SmartScreen | microsoft.com/en-us/wdsi/support/report-unsafe-site | Warns Edge and Windows. Sign in to report several at once. |
| APWG | reportphishing@apwg.org | Forward the lure as an attachment. Shared with member responders. |
| Netcraft | report.netcraft.com | Suspicious URLs. Netcraft investigates and pursues disruption. |
| NCSC (UK) | ncsc.gov.uk, report a scam website | UK route. May work with hosts to remove a site. |
| Cloudflare abuse form | abuse.cloudflare.com | Forwards to the host and site operator. Removes nothing. |
| ICANN Lookup | lookup.icann.org | Registrar and abuse contact when RDAP is awkward. |
| ICANN Compliance | icann.org/compliance/complaint | Complaint about a registrar that ignored a report. |
What if the site is behind a CDN?
When the nameservers and the resolved address both belong to a content delivery network, the origin is hidden and the CDN is the only party that can see it. Cloudflare's published position is that for its pass-through, reverse proxy and CDN services it does not host the content and cannot remove content it does not host; its abuse form forwards the report to the hosting provider and the website operator. So the CDN form is a routing step. Submit it, and submit the name to the blocklists at the same time. If the name is also registered through the CDN's registrar arm, Cloudflare states it acts on phishing by names using its registrar service.
Why do requests stall or fail?
Most failures are structural rather than adversarial, and most are avoidable. PhishFort's analysis of failed domain takedowns reduces to three causes: the evidence could not be verified, the request asked for a decision the recipient does not make, or there was nothing yet to act on.
- The wrong layer was asked. A registrar cannot remove a page and a host cannot suspend a registration.
- The recipient was an upstream network or a reseller rather than the party with the customer relationship, so the report lost urgency at every hop.
- The evidence describes an impression rather than an observation, and the analyst cannot verify it.
- The request asked for a trademark decision. Registrars and registries treat those as content disputes rather than security threats and refuse to adjudicate them.
- The name is parked. Without proof that it is actively hosting malicious content it is treated as a harmless asset, however close it is to your brand.
- The site is a compromised legitimate one rather than a malicious registration, so the registrar points you at the host instead of suspending the name.
- The content moved during triage, or the provider does not treat the conduct as a breach, or ignores reports; CloudSEK lists that last case as extended or may fail.
What happens when one succeeds?
The visible outcome depends on the layer. A hosting action leaves the name resolving while the content returns an error. A registrar action applies a hold status that appears in the registration record, and the name stops resolving. A DNS action removes the records without touching the registration. Each is observable from the outside, in the same public records used to build the package.
Note what has not happened. The registration still exists and still belongs to the registrant. A hold can be lifted, and the name can be renewed, transferred, sold, or repointed once the matter has cooled. Content removed from one provider can be republished at another within hours. So the end of a takedown is the start of monitoring. On this site the Pro plan re-checks a watched name daily and searches certificate transparency logs every 30 minutes, which is how a restoration or a fresh certificate gets noticed. Record the disposition either way.
Is a dispute the same as a takedown?
No, and conflating the two is the most expensive mistake in this area. A takedown is an operational request about conduct, decided by a provider under its own terms, aimed at stopping something happening now. A dispute is an administrative process about entitlement, decided by a panel on written submissions, aimed at changing who holds the name. They differ in what you must prove, what it costs, how long it takes, and what you end up with.
The Uniform Domain-Name Dispute-Resolution Policy is the route for most generic endings. A complainant must show all three elements of paragraph 4(a): the name is identical or confusingly similar to a trademark or service mark in which the complainant has rights, the registrant has no rights or legitimate interests in it, and it has been registered and is being used in bad faith. The remedies are limited to cancellation or transfer. At WIPO the fee for one to five names is 1,500 US dollars with a single panelist and 4,000 US dollars with three, and WIPO's guide says a case with no procedural issues should normally complete within two months. An expedited service at 4,000 US dollars aims for one month. Legal fees come on top.
Uniform Rapid Suspension is the narrower, cheaper cousin for the newer generic endings, described by ICANN as a lower-cost, faster path for the most clear-cut cases. It needs a word mark with a valid national or regional registration that is in current use, the burden of proof is clear and convincing evidence, and the registry must lock the name within 24 hours of receiving the complaint. The result is suspension for the balance of the registration period, not transfer. At the ADNDRC the filing fee for one to five names is 360 US dollars. Both procedures require a mark, neither stops a live phishing page meanwhile, and neither covers most country code endings.
So the sensible sequence is not a choice between them. Stop the harm through the host and the blocklists, preserve the evidence while it exists, and then decide whether the name is worth owning. For a keyword variation that will lapse anyway, usually not. For a name a registrant will renew and keep reusing, a UDRP transfer is the only route that ends it, and the dated records from the takedown are what the panel will read.
Who does this work in practice?
In smaller organisations it is whoever found the name, usually somebody in security or IT with other responsibilities, working from a template and a contact list; the risk is that evidence is collected inconsistently and the outcome never checked. At larger volumes it becomes a function, in-house or bought from a specialist, and what you are buying is not a secret channel: it is analysts who write these requests daily, relationships with abuse desks, and persistence.
What a takedown cannot establish
An intermediary that acts has made a commercial decision under its own terms. It is not a finding of fraud, a determination of trademark infringement, or a statement about who the registrant is. Similarity is never proof of intent. A name that resembles yours and serves a page is a name to review under a published rule, and a report should claim no more than the records support. A refusal establishes nothing either. What you can rely on is the dated record and the published rule, which is why every rule behind every label is set out on the methodology page.
Common questions
- How long does a domain takedown take?
- Published ranges put browser blocklisting at minutes to hours, hosting removal at 24 to 72 hours and registrar suspension at one to seven days. A UDRP normally takes about two months. The reporter controls none of them.
- Can a registrar refuse a takedown request?
- Yes. Registrars act on evidenced abuse under their agreement with ICANN, not on trademark claims, and decline requests about parked names, compromised sites, or packages they cannot verify. A refusal is not a finding that the name is legitimate.
- What is the difference between a domain takedown and a UDRP complaint?
- A takedown asks a host or registrar to stop conduct under its own terms and leaves the registration in place. A UDRP complaint asks a panel to decide entitlement and can transfer or cancel the name, but needs rights in a mark, a fee from 1,500 US dollars, and about two months.
- How much does a UDRP complaint cost?
- WIPO's schedule is 1,500 US dollars for one to five names with a single panelist and 4,000 US dollars with three, plus legal costs. A URS complaint at the ADNDRC starts at 360 US dollars but only suspends.
Sources and further reading
- ICANN: Registration Data Access Protocol (RDAP)
- ICANN: EPP status codes and what they mean
- ICANN: Contractual Compliance
- Google Safe Browsing: report a phishing page
- Google Safe Browsing
- Microsoft Security Intelligence: report an unsafe site
- APWG: report phishing
- Netcraft: report phishing, malware and suspicious URLs
- Netcraft: how to report and take down a phishing domain
- NCSC: report a scam website
- Cloudflare: our approach to abuse
- ICANN: WHOIS and Registration Data Directory Services (the lookup tool)
- ICANN: submitting a complaint to Contractual Compliance
- ICANN: registrar abuse reports
- ICANN: 2013 Registrar Accreditation Agreement, section 3.18
- ICANN: advisory on compliance with DNS abuse obligations (2024)
- ICANN: Uniform Domain-Name Dispute-Resolution Policy (the policy text)
- ICANN: UDRP overview
- ICANN: Uniform Rapid Suspension (URS)
- ICANN: URS procedure (redline, 21 February 2024)
- WIPO: guide to the UDRP
- WIPO: schedule of fees for UDRP cases
- ADNDRC: URS fees
- CloudSEK: what is domain takedown
- Netcraft: the ultimate guide to domain takedown services
- PhishFort: why domain-related takedowns fail
- UK National Cyber Security Centre: Phishing attacks: defending your organisation
- Typosquatting.ai: methodology and data sources