Destroylist: A Layered Phishing Blocklist with DNS and Content Verification

What Destroylist Actually Provides

Destroylist is a domain blocklist aimed at phishing and scam sites. It is not just one list. The repository maintains two content streams: a Primary list, which is described as curated phishing domains, and a Community list, which aggregates from 13 or more sources. Each stream has a live variant that is DNS-verified, and a content variant that is additionally HTTP-verified. This gives you six distinct feeds, plus an allowlist for false positive protection. The intended users are operators of Pi-hole, AdGuard Home, dnsmasq, Unbound, or any DNS firewall that can consume hosts files or zone formats. The README also promotes a threat intelligence API, which suggests use beyond simple blocking, such as integration into security automation.

The Verification Pipeline: Raw, DNS-Active, and Content-Checked

The core mechanism is the layering of verification. The raw Primary and Community feeds contain domains that have been flagged, but not yet confirmed active. The Live feeds, updated every 24 hours, contain only domains that have passed DNS resolution checks, meaning they still resolve to an IP. The Content feeds, updated every 12 or 24 hours, go further by performing HTTP content verification, presumably checking that the domain actually serves a phishing page. This is a sensible design because phishing domains are often taken down quickly. A raw list may contain dead domains, which are noise. The DNS and content checks filter that noise. The README's metrics.json file defines the exact counts, and it notes that the API reports normalized unique domains, which can be lower than the feed-entry counts after URL and duplicate normalization. That distinction is important if you are comparing numbers between the API and the raw files.

Getting Started: The One-Line Pi-hole Setup

The quick start is genuinely quick. For Pi-hole or AdGuard Home, you paste a single URL into your blocklist settings. The recommended URL is the jsDelivr CDN link, which the README says has no rate limits. The raw GitHub mirror is available but may return HTTP 429 on heavy traffic. The URL pattern is consistent: https://cdn.jsdelivr.net/gh/phishdestroy/destroylist@main/rootlist/formats/primary_active/hosts.txt. You can swap primary_active for other tiers like primary, community, or community_active, and change the format from hosts.txt to domains.txt, adblock.txt, dnsmasq.conf, unbound.conf, or rpz.zone. There is also a Redis format, though the README snippet is truncated before the full link. If you are using dnsmasq, you would download the dnsmasq.conf file and include it in your configuration. The process is straightforward and requires no compilation or installation, which is a plus for a blocklist.

The Threat Intelligence API and Its Limits

The README references a Threat Intelligence API, but the truncated material does not include the endpoint URL or authentication details. It says the API reports normalized unique domains, which can be lower than feed counts after URL, www, and duplicate normalization. That is a concrete constraint: if you expect the API to return exactly the same numbers as the raw list, you will be surprised. The API is presumably free, given the project's description, but there is no mention of rate limits or usage terms in the provided text. For a security team wanting to automate lookups, the lack of documented API details in the README is a gap. You would need to inspect the repository's source code or the homepage to find the actual endpoint. This is a limitation of the documentation, not necessarily of the API itself.

False Positives and the Allowlist Mechanism

Any blocklist risks blocking legitimate domains. Destroylist addresses this with a manual allowlist, updated manually, which is available as allowlist.json. The existence of an allowlist is good, but the manual update cadence means it may lag behind real-world false positives. If a domain is incorrectly flagged, you can add it to your own local allowlist in Pi-hole, but the project's global allowlist only changes when maintainers update it. The README does not specify how to submit an appeal, though the table of contents mentions an 'Appeals Process' section that is not in the truncated text. For a production environment, you should plan to maintain your own allowlist in parallel, because relying on the project's manual updates could leave you with blocked domains for hours or days.

Format Coverage and CDN Dependency

The format coverage is broad: hosts, AdBlock, dnsmasq, Unbound, RPZ, TXT, and Redis. That covers most DNS-level blocking tools. The project recommends using jsDelivr CDN links to avoid GitHub rate limits. This is a practical choice, but it introduces a dependency on a third-party CDN. If jsDelivr has an outage or the repository is taken down, your blocklist updates stop. The raw GitHub mirror is a fallback, but it can return 429 errors under heavy load. For a home user, this is acceptable. For a business relying on the blocklist for security, you might want to mirror the files yourself. The MIT license permits that, but you would need to set up your own hosting and update schedule.

Maintenance, Licensing, and the Community Aspect

The repository is actively maintained, with a last push date of July 2026 and a v1.0.0 release from November 2025. The license is MIT, which means you can use, modify, and redistribute the lists with attribution. There is no cost, and the description mentions an 888K+ community, though that number is not a quality metric. The community feed aggregates from 13+ sources, which suggests a broader scope than the primary curated list. However, the README does not specify which sources, nor how often the aggregation runs beyond the 2-hour update interval. The maintenance cost for you is low: you only need to update your blocklist URL periodically, if your tool supports auto-update. The project itself appears to be run by volunteers, so you should not expect a formal support channel. The appeals process exists, but its details are not visible in the provided material.

Alternatives and When Destroylist Is the Wrong Choice

A well-known alternative is the StevenBlack hosts list, which is also a hosts-file-based blocklist, but it focuses on ads and tracking, not exclusively on phishing. Destroylist's approach differs by offering multiple verification tiers and an API, which StevenBlack does not. Another alternative is OpenPhish, which provides a commercial phishing feed with a different pricing model. If you need a purely phishing-focused list with verified active domains, Destroylist is a strong candidate. However, if you need a list that includes ads and trackers, you would need to combine Destroylist with another list. Also, if you require a formal SLA or guaranteed uptime, a community project is the wrong tool. The verification pipeline is a real advantage, but it is not a substitute for a commercial threat intel platform.

Editorial conclusion

Adopt Destroylist if you need a free, multi-format blocklist with verified tiers and an API for automated threat intel, especially for Pi-hole or dnsmasq setups. Skip it if you require a commercial SLA or a fully self-contained solution, since this is community-maintained and relies on external CDNs. Before deploying, verify the feed freshness by checking the update timestamps in dns/metrics.json and test the allowlist to ensure your legitimate domains are not blocked.

Official sources

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