Anti-Phishing Domain Removal: A Practitioner’s Playbook

Learn to take down phishing domains fast. Cyble's step-by-step playbook covers takedowns, delisting, and blocklist removal. Protect your brand now.

Cyble Research & Intelligence Labs14 min read

Key Takeaways

  • Anti-phishing domain removal uses two workflows: takedown of attacker infrastructure and delisting of legitimate domains flagged as phishing.

  • Effective takedowns depend on timestamped evidence, full infrastructure mapping, and routing reports to the right abuse desk first.

  • Parallel submissions to browser blocklists and hosting providers cut victim exposure while infrastructure-level action moves forward.

  • Re-registration and re-hosting are common, so ongoing monitoring and clear escalation paths matter when initial reports stall.

  • Cyble delivers managed detection and takedown services with SLAs and a reported 98% success rate to close the gap between detection and action.

Request a Cyble demo

Takedown Uses Two Distinct Workflows

Every case starts with a choice between two problems.

Workflow A applies when an attacker’s phishing domain or lookalike domain (a near-identical domain registered to impersonate a brand) is impersonating your organization and you want it offline. The goal is suspension or content removal of infrastructure you do not own.

Workflow B applies when your own legitimate domain has been flagged as phishing by a browser vendor, security vendor, or email gateway, and you need it delisted. The goal is a false-positive review that restores your domain’s reputation. The evidence, contacts, and timeline all differ.

Many practitioners get stuck because they apply Workflow A to a Workflow B problem, or the reverse. The rest of this article walks through both workflows in sequence.

How To Remove A Phishing Website: Six Steps To Remove A Phishing Domain

The following sequence applies to Workflow A, where you remove an attacker’s domain.

  1. Capture timestamped evidence that abuse desks will accept.

  2. Identify the full infrastructure: registrar, hosting provider, content delivery network (CDN), and domain name system (DNS) provider.

  3. Route the report to the correct abuse desk first, based on infrastructure type.

  4. Submit to browser and blocklist vendors in parallel to reduce victim exposure.

  5. Monitor for re-hosting and re-registration after the initial takedown.

  6. Escalate through a documented cadence when no party responds.

Step 1 — Capture Evidence Abuse Desks Actually Accept

Strong evidence keeps your takedown request moving instead of stalling in a queue. According to Hunto’s domain takedown guide, most failed takedowns fail on evidence rather than merit, and a screenshot that is three days old when the page returns a 404 gives the reviewer nothing to verify.

A complete evidence package must let a reviewer verify three things without leaving their desk: that the page was live, that it was impersonating you, and that you have the right to complain. That means capturing:

  • The exact malicious URL including path and query string, because many phishing kits only serve the phishing page on a specific path and return a harmless page at the root.

  • A full-page screenshot, not a crop, showing the impersonated brand, the credential-harvesting form, and the browser URL bar in one frame, with a timestamp and timezone.

  • The complete redirect chain from the lure URL to the final landing page.

  • The page source, especially where the credential form posts its data.

  • The WHOIS or Registration Data Access Protocol (RDAP) registration record.

  • HTTP response headers or curl -I output proving the page was live at observation time.

  • Proof of rights, such as a trademark registration number or the legitimate domain being impersonated.

Since April 5, 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 (RAA). That contractual obligation only applies when your evidence meets the required standard.

Step 2 — Identify The Infrastructure

Effective takedown depends on sending each request to the party that controls the specific resource. The hosting provider removes malicious content, the registrar (the company that sells and administers domain names) suspends the domain, and the registry is the last resort for placing a domain on serverHold. A CDN can null-route the content independently of both.

Run a WHOIS or RDAP lookup against the domain. These fields determine which abuse desk you will contact in Step 3, so capture them exactly:

  • Registrar name and Internet Assigned Numbers Authority (IANA) ID

  • Domain creation date

  • Registrant contact where published

  • Name servers

  • Abuse contact email

Then resolve the domain to its IP address and run WHOIS against that IP to extract the network owner, abuse-mailbox field, and autonomous system number (ASN). WHOIS registrant data is frequently privacy-masked, so RDAP lookups are often needed to reliably resolve the registrar of record, including on newer top-level domains (TLDs). When the IP resolves to a CDN, the CDN is acting as a reverse proxy, so its WHOIS records point to the CDN rather than the origin server. Finding the real server requires historical DNS or certificate transparency data.

Step 3 — Route The Report To The Right Abuse Desk First

The routing decision follows the infrastructure type.

  • If the site sits behind a CDN: contact the CDN abuse channel first. CDNs can null-route content and typically act within one to three days. Provider-declared resolution times vary widely, from 24 hours to 5 days for CDN and host providers, and 2 to 4 days for registrars.

  • If the site is on a hosting provider’s IP range: use the hosting provider abuse form. Hosting suspensions remove content faster than domain suspension in many cases.

  • If the domain itself is the primary problem, such as a lookalike registered purely to impersonate, contact the registrar abuse desk. The registrar controls whether the domain resolves at all.

Filing registrar abuse reports and hosting or CDN complaints in parallel rather than sequentially doubles the chance of fast neutralization, because content can return on new hosting while the registrar queue is still open. Third-party reporting platforms can also file on your behalf across multiple channels at once.

Step 4 — Submit To Browser And Blocklist Vendors While You Wait

While the abuse desks above are processing your report, you can cut victim exposure quickly through browser blocklists. Google Safe Browsing and Microsoft Defender SmartScreen block traffic; they do not remove the site. They reduce victim exposure within hours while the takedown runs, but the phishing site stays live for anyone not using that browser or that email gateway. Treat them as parallel protection that runs alongside infrastructure-level action.

Submit to Google Safe Browsing via its manual report form for single URLs or the Web Risk Submission API for volume submissions. Microsoft SmartScreen accepts reports via the Edge feedback flow.

Step 5 — Monitor And Re-File

Attackers often re-use the same kit on fresh infrastructure, so monitoring is part of the takedown job. Kit operators buy domains in bulk on cheap TLDs, and when one goes down the same kit reappears on a sibling domain, sometimes the same day and often with one character changed. Because the same kit reappears on sibling domains, monitoring has to cover the URL, the domain, and the brand keyword set, not just the original report.

The most reliable signal is the kit’s fingerprint. JavaScript identifiers, backend API structures, and HTML template patterns persist across re-registration and re-hosting, so they help you catch the next domain before it scales.

Step 6 — Escalate When Nobody Responds

A clear follow-up cadence keeps pressure on abuse desks without overwhelming them. Start with a first follow-up at 24 to 48 hours that includes the original case number and any new evidence. Send a second follow-up at 72 hours, then move to formal escalation.

Use these escalation paths in sequence:

  • The registry operator above the registrar, for TLD-level action.

  • The CDN if the hosting provider is unresponsive. Most offshore hosts still use major CDNs that act on abuse within 24 to 48 hours.

  • Internet Corporation for Assigned Names and Numbers (ICANN) Contractual Compliance, for registrars that ignore well-evidenced phishing reports. ICANN’s Contractual Compliance FAQ states that most complaint types can pass through three successive five-business-day response periods, up to 15 business days, before formal escalation. Reference the registrar’s record on ICANN’s rolling DNS abuse compliance dashboard to strengthen the filing.

  • National computer emergency response teams (CERTs) and government reporting bodies. In the United States, report to CISA’s 24/7 Operations Center at contact@cisa.dhs.gov or report@cisa.gov, or by phone at 1-844-Say-CISA (1-844-729-2472). Also file a complaint with the FBI’s Internet Crime Complaint Center (IC3). In the United Kingdom, forward phishing emails to report@phishing.gov.uk. The National Cyber Security Centre (NCSC) works with hosting providers and registrars to take down identified malicious sites.

  • Law enforcement, where fraud loss has occurred and criminal referral is warranted.

Expect hours for well-staffed CDN abuse desks, one to five business days for registrars on clear-cut phishing domains, days to weeks for registry escalation, and longer for smaller regional hosts. No abuse desk publishes a service level agreement (SLA).

See how managed takedown works

How To Get Your Own Domain Removed From A Phishing Blocklist

Workflow B covers the false-positive case, where your legitimate domain appears on a phishing blocklist.

A legitimate domain flagged as phishing by a browser vendor, a security vendor, or an email gateway causes immediate damage. You see lost organic traffic, degraded email deliverability, and erosion of customer trust. The delisting path differs from the takedown path, and reviewers expect different evidence.

The process has four stages:

  1. Identify which blocklist is flagging the domain. A domain can appear on more than one list at the same time. Google Safe Browsing, Microsoft SmartScreen, email gateway reputation feeds, and third-party security vendor blocklists are independent systems. Each must be cleared separately. Check the Google Safe Browsing Transparency Report and the Microsoft SmartScreen block page message to identify the flagging system.

  2. Submit a review request through that vendor’s published false-positive dispute process. For Google Safe Browsing, use the Search Console Security Issues report to request a review after you address the flagged content. For Microsoft SmartScreen, use the built-in “report” link on the block page, or in enterprise environments use the Web Content Filtering dispute path in the Microsoft Defender portal. Microsoft states that Web Content Filtering domain category disputes are typically reviewed within one business day. As an immediate workaround while a dispute is processed, admins can create a custom allow indicator for the domain in Defender for Endpoint.

  3. Supply the evidence a reviewer needs. Provide proof of domain ownership, a description of the legitimate business function of the URL, an explanation of why the automated classifier fired, such as a recently expired certificate, a shared hosting IP with a bad neighbor, or a URL pattern that resembles phishing paths, and documentation that any previously problematic content has been removed.

  4. Track each list independently. Review timelines vary by vendor, so treat each list as a separate case. Do not assume that clearance from one system propagates to others.

Spoofed-Domain Email Abuse And Authentication Controls

Delisting handles the case where your domain is wrongly flagged. A related problem appears when your domain is correctly configured but attackers forge it anyway. When spam or phishing email appears to arrive from your own domain, the problem usually involves domain spoofing rather than a compromised mail server. This is a third, adjacent problem: the domain is not being impersonated by a lookalike, but your own domain is being forged in the From line, and it needs its own controls before takedown becomes relevant.

Three email authentication standards address this directly. Sender Policy Framework (SPF) publishes a DNS record listing the mail servers authorized to send on behalf of your domain, and receiving servers check the sending IP against this list. DomainKeys Identified Mail (DKIM) attaches a cryptographic signature to outbound messages, allowing receiving servers to verify the message was not tampered with in transit. Domain-based Message Authentication, Reporting and Conformance (DMARC) ties SPF and DKIM results to the visible From address and instructs receiving servers what to do when authentication fails, such as quarantine or reject, and sends aggregate reports back to the domain owner when someone is forging the domain.

DMARC at enforcement (p=reject) stops most exact-domain spoofing. Note that RFC 9989 Section 2.2 states that DMARC “can only be used to combat specific forms of exact-domain spoofing directly” and does not address visually similar domain names or abuse of the human-readable display name.

To report domain spoofing to the receiving mail provider, forward the original message as an attachment with full headers to that provider’s abuse channel. Report sustained spoofing campaigns to the APWG at reportphishing@apwg.org and, where fraud loss is involved, to IC3 and CISA.

When To Stop Doing This Manually

The steps above work, but they all depend on the abuse desk of a company that has no obligation to you, no SLA, and no visibility into your case. Detection and removal are two motions handled by two different teams, and the gap between them is where the fraud loss happens. A fake login page may capture credentials before the first internal alert is triggered.

Cyble monitors the surface, deep, and dark web for phishing infrastructure, lookalike domains, fake mobile applications, and brand abuse. It also delivers native managed takedown for phishing sites, spoofed and lookalike domains, fake mobile applications, impersonation accounts, and leaked data as part of the same platform rather than as a referral to a third party. Takedowns run against SLAs, and Cyble reports a 98% takedown success rate based on internal telemetry. Results depend on the customer’s environment, asset scope, and configuration.

Detection and takedown from one vendor narrow the gap between knowing and acting. Findings flow into the tools the team already uses through 70+ native integrations including Splunk, Microsoft Sentinel, IBM QRadar, Cortex XSOAR, and ServiceNow. Cyble also supports its own REST application programming interface (API) and Trusted Automated eXchange of Intelligence Information (TAXII) feeds for custom pipelines, so intelligence reaches the workflow the team already lives in rather than requiring a new console.

Capabilities, coverage, and service levels vary by subscription tier and region.

Explore managed takedown with Cyble

Frequently Asked Questions

How long does a phishing domain takedown usually take?

Timelines vary significantly by channel and provider. Major hosting providers with automated abuse pipelines can act within hours. Registrars typically take one to five business days for a clear-cut phishing domain. Registry escalation and unresponsive regional hosts can stretch to weeks. Because no abuse desk commits to a fixed SLA, the practical approach is to file in parallel across hosting, registrar, and CDN while you also submit to blocklists.

Should you contact the registrar or the host first?

The right contact depends on what you need to stop. If the domain itself is the problem, such as a lookalike registered purely to impersonate your brand, the registrar can suspend it entirely. If the immediate harm is a credential-harvesting page on a compromised or shared host, the hosting provider can remove the content faster than a registrar can process a suspension. The short answer is both, in parallel, because host removal kills the content and registrar suspension kills the domain.

What evidence does a registrar abuse desk require?

A complete submission includes:

  • The exact URL with path and query string

  • A full-page timestamped screenshot showing the URL bar and credential form in one frame

  • The WHOIS or RDAP record identifying the registrar

  • HTTP response headers proving the page was live at observation time

  • Proof of rights, such as a trademark registration number

  • The specific harm named in the registrar’s own acceptable use policy (AUP) terms

  • A working reply address

Incomplete packages, especially those missing a timestamp or a URL, are routinely rejected without review.

Does Google Safe Browsing remove a phishing site or only block it?

Google Safe Browsing blocks access for users of Chrome, Firefox, and Safari by displaying an interstitial warning, but it does not take the site offline. The phishing infrastructure remains live and reachable for anyone not using a protected browser or email gateway. Safe Browsing submission should run in parallel with registrar and hosting provider reports, not instead of them. Google also re-evaluates flagged pages, so if an operator swaps out the malicious content the warning can be lifted without a new report.

How do you get a legitimate domain off a phishing blocklist?

The four-stage process above applies. Identify the flagging list, submit through that vendor’s dispute process, supply ownership and business-function evidence, and track each list separately. The most common failure is assuming clearance from one vendor propagates to the others.

Do you need DMARC to stop domain spoofing?

DMARC at enforcement (p=reject) is the most effective control against exact-domain spoofing, and it stops spoofed messages from being delivered by receiving mail servers. SPF and DKIM are prerequisites, and DMARC ties their results to the visible From address. DMARC does not protect against lookalike domains or display-name abuse, which require separate monitoring and takedown workflows.

When should you involve law enforcement?

Law enforcement involvement makes sense when fraud loss has occurred, when the campaign is large-scale or organized, or when registrar and hosting escalation paths have been exhausted. In the United States, file with the FBI’s IC3 at ic3.gov and report to CISA at contact@cisa.dhs.gov or report@cisa.gov, or by phone at 1-844-Say-CISA. In the United Kingdom, report to Action Fraud at actionfraud.police.uk. Law enforcement referral requires documented evidence of suspected criminal activity, and coordinated infrastructure takedowns typically depend on aggregating enough reports to establish a prosecutable pattern.

When should you move from manual reporting to a managed takedown service?

Manual reporting reaches its limit when phishing campaigns move faster than abuse-desk queues, when the same kit reappears on sibling domains within hours of each takedown, or when the team spends more time filing reports than doing anything else. The core issue is that manual takedown depends on companies with no obligation to you and no visibility into your case. A managed service that combines detection and takedown in one pipeline, with SLAs and monitoring for re-emergence, narrows the gap between knowing a phishing site exists and getting it offline.

Explore managed takedown with Cyble

Read Next