PhishDestroy Destroylist: a phishing domain blocklist with six feed variants and a free API

The problem Destroylist solves: phishing domains that never reach a threat feed

A phishing domain usually lives for days. It appears in an SMS or an email, collects credentials, and disappears before a commercial intelligence vendor has finished writing the record. The people who feel this most are not SOC analysts with a SIEM. They are the ones running a home router, a small office Pi-hole, or a self-hosted AdGuard Home instance, who need a URL they can paste into a blocklist field and forget about.

Destroylist targets exactly that audience. It publishes curated phishing domains plus a community feed aggregated from 13 or more sources, and it ships each one pre-rendered in the formats those resolvers already understand. The README states the project carries 190k+ curated threats and a community of 888K+. The repository is MIT licensed and the primary language listed is HTML, which tells you the bulk of the repo is generated feed files and a viewer page rather than application code.

Six feeds, three verification stages, and why the counts disagree

The feed layout is the interesting part. Destroylist does not publish one list. It publishes Primary (curated phishing domains, marked real-time) and Community (aggregated from 13+ sources, every 2 hours), then adds verification tiers on top: Primary Live and Community Live are DNS-verified active domains refreshed every 24 hours, and Primary Content and Community Content are additionally HTTP content verified, on 12-hour and 24-hour cycles. An Allowlist feed for false-positive protection is updated manually.

The README is explicit that badge values are feed-entry counts while the API reports normalized unique domains, so API numbers can be lower after URL, www and duplicate normalization. That is a real design decision, not a bug, and it means you should pick one source of truth and stay with it. The machine-readable definitions live in dns/metrics.json. The practical consequence: if you are reconciling a dashboard against a vendor's count, Destroylist will look smaller than its badges suggest, and the difference is normalization, not missing data.

Installing Destroylist in Pi-hole or AdGuard Home

There is no package to install. The README's Quick Start says to paste a URL into your blocklist settings. The recommended link is served through the jsDelivr CDN, which the README says has no rate limits; the raw GitHub mirror may return 429 under heavy traffic.

https://cdn.jsdelivr.net/gh/phishdestroy/destroylist@main/rootlist/formats/primary_active/hosts.txt

In Pi-hole, add that URL under Settings, then Blocklists, and run a gravity update. In AdGuard Home, add it under Filters, then DNS blocklists. After the update you should see the list appear with its entry count. If the fetch fails, the README points at the raw GitHub URL as a fallback, and notes it may return 429.

For a resolver you control directly, the same content is published as dnsmasq, Unbound and RPZ files. Point your resolver's config at one of the jsDelivr format URLs, for example the dnsmasq variant:

https://cdn.jsdelivr.net/gh/phishdestroy/destroylist@main/rootlist/formats/primary_active/dnsmasq.conf

The repository's requirements.txt pins the tooling the scripts expect: requests, dnspython, tqdm and tldextract. Those pins tell you the pipeline does DNS lookups and public-suffix parsing, which matches the Live and Content tiers described in the README.

The API is free, and that is also the constraint

Destroylist exposes a threat intelligence API, and the README treats it as a first-class access path alongside the file feeds. Free access with no key friction is a genuine advantage for a hobby project or a small consultancy that cannot justify a commercial subscription.

The trade-off is the same one that applies to any free, community-maintained feed: there is no stated SLA, no uptime commitment, and no query quota documented in the README. If your detection pipeline has an on-call rotation, a free API with undocumented limits is a dependency you have to wrap in your own caching and fallback. The file feeds are the safer integration for anything production-facing, because a cached copy keeps working when the endpoint does not. The README's own production guidance points at list.json or active_domains.json, and names blocklist.json for maximum coverage.

Where Destroylist is the wrong tool

Destroylist is a domain blocklist. It blocks resolution. It does not inspect traffic, it does not tell you which of your users visited a listed domain, and it does not produce an incident. If a phishing page is hosted on a legitimate platform subdomain, or if the attack arrives as a link to a compromised but otherwise clean site, a domain list has nothing to say about it.

Aggregation is the second limit. The Community feed is assembled from 13+ sources, and the README does not document per-source attribution or a scoring model. You cannot ask Destroylist which upstream reported a domain or how confident it is. For a home resolver that is fine. For a team that needs to justify a block to a user or a customer, that missing provenance is a real gap, and the manual allowlist is the only lever the README describes for correcting a mistake.

The third limit is freshness granularity. The Primary feed is described as real-time, but the Live and Content tiers are 24-hour and 12-hour cycles. A domain registered an hour ago and taken down six hours later may never appear in the tier you consume.

How Destroylist differs from OpenPhish and other feed aggregators

OpenPhish is the closest comparison people search for, and the difference is structural. OpenPhish is a phishing intelligence source that publishes its own feed; Destroylist is a distribution layer. It curates one set of domains, aggregates a second set from 13+ sources, then renders the result into six resolver-specific formats and hosts them on a CDN.

That means Destroylist's value is not primarily in detection. It is in packaging. If you already subscribe to a phishing feed, the work of converting it into dnsmasq, Unbound, RPZ and AdBlock syntax and keeping the mirrors alive is the part Destroylist removes. If you need the raw detection signal with per-source metadata and a support contract, you want the upstream source, not the aggregator. The two are complementary: several of the 13+ community sources are almost certainly the kind of feed you would otherwise subscribe to directly.

Maintenance, licence and what the README leaves open

The last push to the default branch was on 2026-07-20, and the most recent release entry is the historical archives set dated the same day, with PhishDestroy Viewer v1.0.0 released on 2025-11-08. The repository is not archived. The feed files themselves are generated, so a quiet commit history does not mean the lists are stale, but it does mean you should verify the content timestamps in the files rather than reading the commit log.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive position, and it matters here because redistributing a blocklist inside a product is a normal use case. It is not legal advice; if you embed the feed in a commercial offering, read LICENSE and the CODE_OF_CONDUCT and CONTRIBUTING files in the repository root.

Upgrade cost is close to zero for consumers: the CDN URL is pinned to the main branch, so you get new entries without changing anything. That is also the risk. There is no versioned feed URL documented in the README, so you cannot pin a snapshot and stage changes. If a bad entry lands in the list, your resolver picks it up on the next refresh, and your only correction path is the manual allowlist plus your own local override.

Editorial conclusion

Adopt Destroylist if you run Pi-hole, AdGuard Home, dnsmasq or Unbound and want a hosts-format phishing feed without building a pipeline. Do not adopt it if you need a contractual SLA, an incident-response feed, or a single canonical count, because the README itself warns that badge counts and API counts differ. Before rollout, pull allow/allowlist.json and confirm the entries you care about are not on it, then fetch the feed twice a day apart and diff the two files to see how much churn your resolver will absorb.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes