A meaningful share of well-written reports get no reply. The routes that exist are limited, and knowing which ones are real saves a week of writing to people who will not answer.
The escalation ladder
| Step | Route | Realistic? |
|---|---|---|
| 1 | Follow up once, referencing the original, after two business days | Yes. Queues lose things, and a polite follow-up frequently works. |
| 2 | Move to the next party in the chain — host to registrar, or the reverse | Yes. This is the main escalation and should have been started in parallel anyway. |
| 3 | The registrar’s own upstream, if they are a reseller | Sometimes. The RDAP record names the sponsoring registrar, which may not be who you wrote to. |
| 4 | The registry for that TLD | Sometimes, for their own policy breaches. Weeks. |
| 5 | ICANN complaint, for gTLD registrars ignoring abuse obligations | Slow, and it creates a record that matters for repeat offenders. |
| 6 | Blocklist submissions and browser safe-browsing reports | Yes, and it should happen early rather than as an escalation. |
Step 6 belongs at the start
Reporting to browser safe-browsing services and phishing blocklists does not remove the site, and it interrupts the campaign — a browser interstitial stops most victims. It requires nobody’s cooperation, takes a minute, and works while every other route is still in a queue.
On detection, in parallel: 1. capture evidence 2. report to the host 3. report to the registrar 4. submit to safe-browsing and blocklists <- do not wait Step 4 has the shortest path to protecting people and the least dependency on anyone answering.
Knowing when to stop
- When the campaign is over. A domain that stopped serving content two weeks ago is not worth further escalation.
- When the host is deliberately unresponsive. Some providers do not act, by business model. Recognise them and route around via the registrar and the blocklists.
- When the domain matters enough for UDRP, which is a different process on a different timescale.
- Record the outcome either way. A registrar that ignored three well-evidenced reports is a fact worth having next time, and worth having in an ICANN complaint.
The metric is duration, not resolution
A campaign interrupted by a browser warning on day one and taken down on day six is a better outcome than one taken down on day three with no interruption. Measure how long the site was effective, not how many takedowns were successful.