Malte ZanderContents
Takedowns rarely fail for lack of rights. They almost always fail because of the report. The most common reasons are an incomplete URL, missing evidence, the wrong recipient, an unclear reason and no follow-up. If you write a report that a reviewer can decide without asking questions, and send it to every responsible party in parallel, you avoid most rejections.
- A notice to a hosting provider in the EU needs four elements: a reason, the exact URL, your name and email address, and a statement that you act in good faith (DSA, Article 16).
- Such a notice gives the host knowledge of the content if a diligent provider can identify the illegality without a detailed legal examination (DSA, Article 16).
- In the first two months of ICANN's new rules, most complaints were closed because the reporters had not contacted the registrar first (ICANN).
- In October 2025, ICANN reported that many complaints are invalid, incomplete or lack the detail needed to act (ICANN).
Why do hosts and registrars reject reports?
Because they can't verify what you claim. Abuse teams handle many reports a day, and each one has to be decidable in minutes. If the exact address is missing, the page shows nothing when opened or it stays unclear whose rights are affected, the report is parked, answered with questions or closed. The nine mistakes below explain most rejections.
The 9 most common mistakes
1. Only the domain instead of the full URL
Many fakes sit in a subfolder or need parameters to show their content. If you report only the domain, you send the reviewer to an empty home page. Report the full URL with path and parameters, exactly as victims received it.
2. No evidence, or weak evidence
A sentence like "this site is a scam" isn't enough. Attach desktop and mobile screenshots with date, time and the visible address bar, plus a comparison with your real page. ICANN names a screenshot and the full URL as useful evidence (ICANN). What belongs in the package is in Securing evidence of a fake website.
3. The wrong recipient
A CDN doesn't remove content it doesn't host. A registrar doesn't suspend a single subpage on a hacked website. Writing to the wrong party costs days of forwarding. Which party can do what is explained in Host, registrar or DNS.
4. The complaint body before the provider
You can complain to ICANN about registrars, but only after reporting to the registrar itself. Most complaints in the first two months were closed for exactly that reason. Always go to the provider first and record the date and ticket number.
5. An unclear reason
"Infringes our rights" says nothing. State what the page does: it asks for login credentials, it sells goods under your name, it confirms forged certificates. The clearer the case, the more likely the provider can decide without a detailed legal review. How framing picks the channel is in Clone sites vs phishing pages.
6. No proof of who is reporting
Providers want to know whether the report comes from the rights holder. Give your company, role and official website, and the registration number for trademarks. If a service provider reports for you, it should be able to show written authorization.
7. The page shows nothing to the reviewer
Some fakes only show their content with the right parameters, only on mobile devices or only in certain countries. The reviewer then sees an empty or harmless page. Describe how the page is reached and attach the evidence. The background is in Hidden fakes.
8. No follow-up
A report without an answer isn't rejected. It may just be stuck. Record every ticket number, follow up after one or two business days with a reference to the first report and then escalate step by step.
9. Bulk reports without review
Automatically generated reports with false hits damage your reputation with the provider. Once you have reported genuine partner sites, your reports get handled more slowly. Check every case, keep an ignore list for partners and resellers and let a person approve every report.
The checklist before you hit send
| Check | Done when |
|---|---|
| URL | Full address with path and parameters, as victims receive it |
| Evidence | Desktop and mobile screenshots with date, time and address bar, plus a comparison with the original |
| Recipient | The party can do what you ask |
| Reason | One sentence on what the page does and whom it imitates |
| Sender | Company, role, contact, and the registration number for trademarks |
| Statement | The good-faith statement for hosts in the EU |
| Parallel | Host, registrar and Google Safe Browsing on the same day |
| Follow-up | Ticket number recorded, follow-up date set |
A ready structure to copy is in Writing an abuse report that hosts actually act on.
How does AI Fraud Protect help?
AI Fraud Protect creates every case with the full URL, screenshots and registration, DNS, hosting and certificate data, and identifies the responsible parties automatically. It prepares each report with the right grounds for its channel, and a person reviews and sends every message. Partners and resellers sit on an ignore list, and open cases stay on a follow-up list until the fake is gone.
Start the free fraud scan for a short report within 48 hours, or request a demo to see detection, evidence and takedown in the app.
FAQ
What should I do when a report was rejected?
Read the reason, add what is missing and report again with a reference to the first ticket number. Use the other channels in parallel, such as the registrar and Google Safe Browsing.
Do I need a registered trademark for a report to work?
Not for phishing. A page that steals login credentials is fraud whether or not the trademark is registered. For domain disputes and trademark complaints on platforms, a registered trademark helps a lot.
How much evidence is enough?
Enough for a reviewer to decide without asking. Usually desktop and mobile screenshots, the full URL, a comparison with the real page and the domain's registration data are sufficient.
May I report the same page to several parties?
Yes. Each party has its own lever. What matters is that you ask each one for what it can do.
Sources
Digital Services Act, Article 16, with the official text on EUR-Lex
ICANN advisory: DNS abuse obligations in the registrar and registry agreements, 5 February 2024
ICANN: enforcement of DNS abuse requirements, the first two months, 7 June 2024
ICANN: progress and next steps in enforcing DNS abuse mitigation requirements, 20 October 2025