How a Domain Takedown Works: Timeline and Evidence

Key takeaways

• A takedown request goes to whoever controls the resource. The host removes content, the registrar suspends the domain, and the registry is the last resort.
• Since 5 April 2024, ICANN’s DNS Abuse Amendments require accredited registrars to act on well-evidenced abuse reports under Section 3.18 of the Registrar Accreditation Agreement.
• Registrars must publish an abuse contact on their homepage, and abuse web forms cannot require a login.
• APWG recorded 1,003,924 phishing attacks in Q1 2025, the highest quarterly volume since late 2023, and 853,244 in Q4 2025.
• Most failed takedowns fail on evidence, not on merit. Timestamped proof and a correct recipient decide the outcome.

A domain takedown is the process of getting a malicious domain or the content it serves removed, suspended, or delisted by the party that controls it. For a phishing site impersonating your brand, that usually means a hosting provider pulling the page within hours, or a registrar suspending the domain within days.

The mechanics are not complicated. Getting them right under time pressure is. Below is what actually happens at each step, what each recipient needs from you, and where the process stalls.

Who are you actually asking?

This is the single decision that determines whether your request takes six hours or six weeks. Four different parties can act, and they have different powers and different appetites.

Party	What they can do	Typical speed	Use when
Hosting provider	Remove the page or suspend the account	Hours to 2 days	The domain is legitimate but a page is malicious, or speed matters most
Registrar	Suspend or hold the domain, change nameservers	1 to 5 business days	The whole domain exists to attack you
Registry	Place the domain on serverHold	Days to weeks	The registrar is unresponsive or complicit
CDN or proxy	Stop shielding the origin, sometimes terminate service	1 to 3 days	The site sits behind a proxy and you need the real host

A common mistake is going straight to the registrar for a compromised legitimate site. If a small business had a page injected into their WordPress install, suspending their domain takes down their entire business over one malicious URL. Registrars know this and will refuse. The host is the right recipient.

The reverse mistake costs more time. If the domain was registered three days ago purely to impersonate your login page, asking the host to remove one file achieves nothing. The attacker re-uploads it in minutes. Suspend the domain.

What evidence do registrars and hosts require?

Abuse desks process high volumes and reject anything that needs interpretation. A request that survives triage contains all of this, in the first message, with no attachments the reviewer has to open.

1. The exact URL, including path and query string. Not the domain alone. Many kits only serve the phishing page on a specific path and return a harmless page at the root.
2. A timestamp with timezone for when you observed it live.
3. Evidence the content is malicious: a screenshot showing your brand, the credential form, and the URL bar in one frame. Full-page capture, not a crop.
4. Proof of your rights: your trademark registration number, or the legitimate domain the site is impersonating.
5. The specific harm, named in their terms: phishing, malware distribution, trademark infringement. Match their abuse policy language.
6. Your contact details and a statement of good faith.

Two additions materially raise the response rate. Include the HTTP response headers or a curl -I output proving the page was live when you saw it, and include the hash of the phishing kit if you can retrieve it. Both signal that a technically competent party is reporting, and abuse teams triage accordingly.

Evidence decays. Phishing infrastructure is often live for hours. If your screenshot is three days old and the page now returns a 404, the reviewer has nothing to verify and will close the ticket. Capture proof at the moment of detection, which is why automated takedown workflows attach evidence at detection time rather than at filing time.

What changed with ICANN’s 2024 DNS abuse rules?

On 5 April 2024, amendments to the Registrar Accreditation Agreement and the Base gTLD Registry Agreement took effect, adding explicit DNS abuse obligations. This matters because it converted registrar responsiveness from a courtesy into a contractual requirement.

Under the amended Section 3.18 of the RAA, registrars must take prompt action on reports of DNS abuse, which ICANN defines as malware, botnets, phishing, pharming, and spam where it acts as a delivery mechanism for the others. Registry operators carry parallel obligations under Specification 6 of the Base Registry Agreement.

Two procedural points are directly useful when a registrar stonewalls you:

• The abuse contact must be readily accessible on the registrar’s homepage. If you cannot find it, that is itself a compliance failure worth citing.
• Abuse web forms must not require a login. A registrar that forces account creation before accepting a report is not compliant.

ICANN publishes a rolling twelve-month DNS abuse compliance dashboard. Referencing a registrar’s own compliance record in an escalation tends to move things along.

How long does a takedown take?

Realistic expectations, assuming a complete first submission:

• Major hosting providers: often same day. Automated abuse pipelines at large providers can act within a few hours.
• Registrars: 1 to 5 business days for a clear-cut phishing domain. Longer if they attempt to contact the registrant first.
• Bulletproof or non-responsive hosts: indefinite. These providers monetise not responding, and no amount of evidence changes that.
• Registry escalation: days to weeks, and only after you can show the registrar failed to act.
• Browser and blocklist submission: minutes to hours, and this is the step most teams skip.

That last point deserves emphasis. Removing a site and neutralising it are different objectives. Submitting to Google Safe Browsing, Microsoft SmartScreen, and APWG’s clearinghouse can put an interstitial warning in front of most victims within hours, while the takedown itself is still in a queue. Run both tracks in parallel. Blocklisting protects people during the window when the site is still live.

Why do takedown requests fail?

In practice, rejections cluster into five causes, and four of them are avoidable.

1. Wrong recipient. Sent to the registrar when the host should have handled it, or sent to a reseller with no authority.
2. Stale evidence. The page was down or cloaked by the time a human looked.
3. Cloaking. The kit serves the phishing page only to visitors matching a target profile, and shows a blank page to everyone else including the abuse reviewer. Note this explicitly in your report and include the request conditions that reproduced it.
4. Unclear rights. No trademark reference, so the reviewer cannot tell impersonation from a legitimate competitor.
5. Genuinely uncooperative provider. The only real one. Escalate to the registry, then to ICANN Contractual Compliance.

Track every submission with its timestamp, recipient, and response. An escalation to a registry or to ICANN is far stronger when it shows a documented, unanswered request to the registrar rather than an assertion that you tried.

Takedown at scale

One phishing site is a ticket. Two hundred is an operations problem, and that is the normal condition for any recognisable brand. APWG counted more than a million phishing attacks in a single quarter of 2025.

At volume, three things decide whether your programme works:

• Detection before victims arrive. A takedown that starts after customers have reported losses is already late. Continuous attack surface monitoring and dark web sourcing shorten that gap.
• Evidence captured automatically at detection. Manual screenshots do not survive contact with a hundred incidents a week.
• Recipient routing. Resolving host, registrar, registry, and proxy for every URL, then filing with the right one first time.

This is what an automated takedown service is for: detection, evidence capture, correct routing, submission, and escalation tracking, with an audit trail per incident. Read more about how Hunto approaches exposure management across the full lifecycle.

Frequently asked questions