A complete, DNS-verified export of 390,000+ active phishing domains as CSV or JSON, rebuilt and published at 04:30 UTC with a per-day changelog. Built for the enforcement points that cannot make an API call per request.
A recursive DNS resolver answering thousands of queries a second has no budget for an outbound HTTPS call per name. Nor does a firewall evaluating a rule at line rate, nor an isolated analysis host with no route to the internet at all. These are exactly the places where a phishing block is most valuable, because they cover every device on the network regardless of what application generated the traffic.
# fetched 04:41 UTC domain,category,dns_status 0-105.com,phishing/malware,resolves 0-amazon.weebly.com,phishing/malware,resolves 0-amfc.firebaseapp.com,phishing/malware,resolves 00-ede.pages.dev,phishing/malware,resolves 000-access-secure.web.app,phishing/malware,resolves 001-ede.pages.dev,phishing/malware,resolves 002-s.pages.dev,phishing/malware,resolves ... 390,000+ more rows # changelog_2026-07-27.csv action,domain added,secure-verify-login.pages.dev added,account-hold-review.web.app removed,expired-notice-portal.example
Everything below is included from the first month. There is no add-on tier for the changelog or for the API pull.
A complete CSV containing every actively-resolving phishing domain in the database, categorised and DNS-verified. Currently 390,000+ domains and growing with each daily build.
A separate file showing exactly which domains were added and removed each day. Ideal for incremental updates to a blocklist you do not want to reload in full every morning.
Every domain is verified via DNS resolution through rotating proxy infrastructure. Only hosts with an active A record are included, so there is no stale data to filter out yourself.
The database is refreshed daily at 04:30 UTC. New phishing domains are ingested from threat-intelligence feeds and verified before they are allowed into the export.
Pull the file programmatically from /api/v1/feed or download it by hand from the dashboard. Both are included, and feed downloads are unlimited.
Access to previous daily snapshots for trend analysis, research and compliance auditing — the way you reconstruct what was known on the day an incident happened.
Three columns, one row per host, no nesting and no quoting surprises. Here are the first seven rows of a real export.
| Domain | Category | DNS status |
|---|---|---|
| 0-105.com | phishing/malware | resolves |
| 0-amazon.weebly.com | phishing/malware | resolves |
| 0-amfc.firebaseapp.com | phishing/malware | resolves |
| 00-ede.pages.dev | phishing/malware | resolves |
| 000-access-secure.web.app | phishing/malware | resolves |
| 001-ede.pages.dev | phishing/malware | resolves |
| 002-s.pages.dev | phishing/malware | resolves |
Read those hostnames again. Four of the seven are subdomains of platforms with impeccable reputations — weebly.com, firebaseapp.com, pages.dev, web.app. Any control that reasons about the registrable parent domain, or about how popular a site is, will wave all four straight through. Host-level enforcement is not a refinement here; it is the entire point.
Three ways to buy the same daily export. The differences are commitment length, archive depth and delivery flexibility.
Rolling monthly subscription.
Tailored to your organisation.
# Download the latest feed via cURL
curl -o phishing_domains.csv \
"https://phishingdetectionapi.com/api/v1/feed?apikey=YOUR_KEY"
# Python: download and load into a set
import requests, csv, io
resp = requests.get(
"https://phishingdetectionapi.com/api/v1/feed",
params={"apikey": "YOUR_KEY"}
)
reader = csv.DictReader(io.StringIO(resp.text))
phishing_domains = {
row["domain"] for row in reader
}
print(f"Loaded {len(phishing_domains)} domains")
# Cron: daily update at 05:00 local
# 0 5 * * * /usr/bin/curl -o /etc/blocklists/phishing.csv \
# "https://phishingdetectionapi.com/api/v1/feed?apikey=KEY"
The feed endpoint is an ordinary authenticated GET that returns a file. There is no handshake, no pagination and no state to track between runs, so the entire client is a cron line and a loader. Schedule the pull for shortly after 04:30 UTC and the enforcement layer is never more than a day behind the pipeline.
Every build follows the same five stages, and the file you download is the output of the fifth.
Newly reported phishing hosts are pulled from curated threat-intelligence feeds including phish.co.za and other OSINT sources. At this point the set is a raw list of names with no guarantee that any of them are still serving anything.
Each name is resolved through rotating proxy infrastructure using 50 concurrent threads with a ten-second timeout. Only hosts returning an active A record survive. This is the stage that decides whether the export is enforceable or merely interesting.
Survivors are deduplicated and labelled phishing/malware, then diffed against the previous day's build. That diff is the changelog: every domain that entered the list and every domain that left it, with no reconciliation work required at your end.
The verified set is written out as CSV and JSON and the API index is swapped over in the same pass, so a lookup and a feed row can never disagree about the state of a domain. The previous export is retained in the archive.
A scheduled job downloads the file, transforms it into whatever format your enforcement point expects, and reloads. From that moment every device behind that resolver or firewall fails to reach every domain on the list, with no application changes and no per-query cost.
Five practical answers about sizing, format and how the feed sits next to per-lookup credits.
Only if you also want interactive lookups. The feed subscription covers unlimited downloads of the full export and the changelog; it does not consume credits, and credits are not required to use it. The Annual plan includes 100,000 API credits so you can run both models without a second purchase.
It is a three-column CSV with one row per domain and no quoting overhead, so the size is dominated by the domain strings themselves across 390,000+ rows. It is a single ordinary HTTP download, not a paginated API walk, which is why the whole pull is one cron line.
CSV by default and JSON on request, both from the same /api/v1/feed endpoint using the format parameter. The CSV columns are domain, category and dns_status, which map cleanly onto an RPZ zone file, a firewall URL category or a SIEM lookup table with a short transform script.
The build publishes at 04:30 UTC, so a pull scheduled just after that is working with a set that was resolved and verified hours earlier at most. Schedule the job for 05:00 UTC and you will never be more than one build behind.
It stops resolving, fails the verification stage on the next build, and is removed from the export. It appears in that day's changelog under removals, so your incremental loader drops it without you writing any expiry logic.
Subscribe today, schedule the pull for 05:00 UTC, and your resolver will be refusing 390,000+ verified phishing hosts before the first user logs in.
