Registration screening is a guessing game played against an adversary who gets to test your rules for free. Portfolio intersection is not. This page is about taking a daily list of DNS-verified, currently-resolving phishing domains, intersecting it with the names you sponsor or serve, and turning the overlap into a queue your abuse team can actually work through.
Not "does phishing exist" — everyone at a registrar knows it does. These are the operational questions that decide whether a threat list becomes useful or becomes another unread report.
How to produce a defensible exposure number by intersecting the names you sponsor with a daily verified list, and what that number does and does not prove.
Where a verified match belongs in an abuse workflow that still ends with a person signing off on a suspension.
Why current resolution state, not report age or complainant volume, is the sane way to sequence a backlog of open cases.
What a feed match establishes as a matter of observed fact, what it never establishes, and why saying so out loud protects the registrar.
Registrars rarely fail to act because nobody told them. They fail because the telling arrives faster than anyone can read it, in a dozen incompatible formats, with no way to sort the certain from the speculative.
A brand-protection vendor sends a machine-generated notice with forty hostnames and a screenshot per name. A bank's fraud team forwards a customer complaint with the URL buried three quotation levels deep in a reply chain. A volunteer researcher sends a plain-text list with no evidence attached and an implied deadline. A trademark firm sends something that reads like a cease-and-desist but is really a request for contact details. A hosting company forwards a report it received about a domain you sponsor but do not host.
Perhaps one of those notices concerns a name that you sponsor, that is currently resolving, and that is currently serving a credential-harvesting page. The other four consume exactly the same reading time as the one that matters, and nothing on the outside of any of them tells you in advance which is which.
An analyst spends most of their attention working out what a report is even about — which domain, which registrar of record, whether the complained-of content sits at the apex or in a subdirectory, whether the name still resolves at all — and comparatively little on the part that actually requires judgement.
Registrars get accused of slow action on the obvious cases and occasionally hasty action on the ambiguous ones, and both come from the same root cause: the analyst who has read two hundred notices has stopped reading carefully by the time they reach the one that mattered.
When a report arrives naming secure-login-example.tld, a single lookup tells you in well under fifty milliseconds whether that exact hostname is currently on a list of domains independently observed and confirmed to be resolving and serving phishing. That is not the whole investigation, but it is the piece that was eating the analyst's day, and it arrives before they open the message rather than after.
Reports concerning names already on the list get routed into a lane with a shorter checklist. Reports concerning names not on the list keep every bit of the human scrutiny they had before, because absence from the list is not evidence of innocence — it is only evidence that nothing has been observed yet.
Once classification is cheap the desk can afford the work it always wanted and never had hours for: sweeping its own portfolio proactively rather than waiting to be told, re-checking open cases daily to see which have gone dark on their own, and giving reseller channels a monthly figure instead of an argument. Those are the activities that reduce inbound report volume at source.
Treating all of them as one category called "abuse" is why abuse queues stall. The evidence you need, and the action available to you, differ sharply between them.
Every situation below ends with a hostname resolving to a page that is stealing somebody's credentials, which is why they all land in the same inbox. They diverge completely before that point, and they diverge again immediately afterwards in terms of what a registrar can legitimately do about them. A bulk-registered throwaway name and a fifteen-year-old business domain compromised last Tuesday both appear in the same list of confirmed phishing hosts; suspending the first is routine, and suspending the second punishes the victim. The list supplies the fact. Your workflow has to supply the context.
Hundreds of names in a single session, generated from a wordlist, paid with one instrument, all pointed at the same nameservers inside the hour.
The registrant's own control panel is phished, then used to change nameservers, unlock names, or add a mail forward that quietly intercepts the recovery loop.
An auth code lifted from a compromised panel moves a valuable name away mid-incident, so the registrar of record changes while the complaint is still being triaged.
A name previously used for phishing drops, becomes available, and is picked up again for exactly the same purpose, sometimes by the same operator.
A long-held domain with real business behind it starts serving a login clone in a subdirectory after a content-management system is breached.
Volume arrives through a reseller whose customer verification is thinner than yours, while the accreditation obligations still land on the sponsoring registrar.
You did not sell the name but you serve the zone, so you hold the record that makes the phishing host reachable and you are asked to act on it.
Registrant details in WHOIS and RDAP are fabricated and the published abuse contact points at an unread mailbox, so every escalation route dead-ends silently.
Not a vendor's claim about the industry. A count of names you sponsor that are, as of this morning's build, confirmed to be resolving and hosting phishing.
The mechanics are unglamorous and that is the point. You already have a list of every domain you sponsor, or every zone you serve, because you cannot run the business without one. The daily feed gives you the complete phishing database as CSV, delivered as a separate subscription alongside a changelog of what was added and removed since the previous build. Sort both lists, join them on the domain column, and the output is the intersection. On a Unix box that is one comm -12 against two sorted files and it finishes faster than the download did. Loaded into a database it is one indexed join. Nothing about this is difficult, which is precisely why it is odd that so few registrars have the number to hand.
What you get from running it is an exposure figure computed from your own data rather than from somebody's marketing: these specific names, sponsored by you, appear in a database of hosts independently verified as currently resolving and currently phishing. Run the same job every morning and you get a time series, and that series is what turns an argument into a management conversation — because it answers the questions executives actually ask about whether this is getting worse, whether last quarter's verification change helped, and which part of the business is generating it.
The raw intersection is a number. The same rows grouped four different ways are four separate operational findings, and each one points at a lever somebody in the business already controls.
| The daily CSV feed | The check & batch API | |
|---|---|---|
| Shape of the job | The complete database downloaded once a day; matching then happens entirely on your own infrastructure. | Individual or batched lookups made at the moment you need an answer, inside a request or a support tool. |
| What it costs | A separate subscription, with no per-lookup charge at all once the file is sitting on your own disk. | One credit per domain. The $99 Growth package works out at $0.0040 per lookup and the $249 Professional package at $0.0025 across a hundred thousand. |
| Batch size | The whole database in one file, plus the added and removed changelog for the day. | Up to a hundred domains per POST, one lookup each, one round trip. |
| Fifty thousand names | One download and one join, and the same cost again tomorrow however often you re-run it. | Five hundred requests and fifty thousand credits, with credits staying billed monthly. |
| Who it suits | Registrars sweeping an entire sponsored book every morning, where per-lookup cost would dominate. | Smaller books, resellers and DNS hosting providers, and quarterly rather than daily sweeps. |
| Where it stops | Nothing to call when you need a verdict inside a live request, so most registrars run both. | Checking the whole book daily gets expensive; that crossover point is easy to work out from your own name count. |
A list that only ever grows is a list that slowly stops being useful. The verification standard here is what keeps the file worth joining against.
Most aggregated abuse data is cumulative. Something gets reported, it goes in, and it stays in for as long as the archive exists. That is defensible for research and actively harmful for operations, because within a year a large fraction of the file describes hosts that stopped answering months ago. Join your zone against that and the intersection is dominated by history — names used for phishing once, now parked or dead or resold to somebody legitimate, generating work for an analyst whose job becomes establishing that nothing is happening.
DNS verification is the admission criterion. A name somebody complained about but which never resolved, or which has since gone dark, is not in the file consuming your analyst's time.
The whole database is regenerated every twenty-four hours and entries that stop resolving are dropped rather than retained, so the file you join against this morning reflects this morning.
The 390,000-plus figure counts hosts that answered a DNS query recently. Every row in your morning intersection therefore describes something that is reachable, not something that once was.
For a registrar that distinction is the entire value proposition: the size of the intersection tracks reality instead of tracking how many months you have been subscribed.
The day's additions intersected with your zone are names that were fine yesterday and are hosting phishing today. Of everything the feed produces, this is the signal that most deserves an alert.
Removals intersected with your open cases are incidents that ended on their own — the host went dark, the compromised site was cleaned, the operator moved on. Reconciling against them each morning stops the desk chasing work that is already over.
A backlog worked in arrival order spends its best hours on domains that stopped mattering weeks ago. Resolution state is the cheapest and most honest priority signal available to you.
Reported eleven days ago, three complainants attached to the ticket, and a domain that has not resolved since the day after the report landed. Arrival order puts this case at the top of the queue. Complainant count puts it at the top as well.
Arrived this morning from a single anonymous submitter, with no evidence pack and nobody chasing it. The domain resolved forty minutes ago and sits on today's build alongside everything else confirmed to be phishing right now.
Nobody is being phished by a host that does not answer, and somebody is being phished right now by a host that does. Sequencing by current resolution state is the correction to both arrival order and complainant count, and it is the one prioritisation rule that survives contact with a real backlog.
Intersect your open-case domains against the fresh build. Cases whose domains appear stay in the active queue, sorted so the longest-live rise to the top because those represent accumulated exposure. Cases whose domains have dropped out move to a lower-priority lane with the date they stopped appearing — not closed outright, because a name can go quiet for a fortnight and come back.
A registrant whose name has been suspended will often say the content is gone. Checking whether the domain still appears on today's build, and whether it appeared on the removals list, gives you an externally observed answer. It does not settle the appeal on its own, because content can move rather than stop, but it converts a he-said-she-said into a documented observation.
Suspension has real consequences for a real business, some of the names on any morning's intersection belong to compromised victims rather than to attackers, and telling those apart is a judgement no list can make. The correct architecture puts the list upstream of a person — it fills the queue, ranks it, attaches evidence and flags duplicates, then a trained analyst decides. Registrars who wired a feed straight into an automatic serverHold with no review have generally regretted it, usually the first time a customer's compromised site went offline in its entirety over one bad subdirectory.
These are two different kinds of statement, and a registrar that keeps them separate in writing is far better placed when a decision is challenged.
Read the right-hand column carefully, because the honesty in it is the useful part. A match is evidence that confirmed live phishing hosting was observed on a dated build. It is not a legal determination. It does not decide whether the registrant is culpable, whether a trademark was infringed, whether the content was placed by the account holder or by whoever compromised them, or whether suspension is the proportionate remedy under your registration agreement and the accreditation framework you work within. Those are questions for your policy, your counsel and your analyst, and a threat feed that claimed to answer them would be selling you something it cannot deliver.
Instead of “a complainant says this is phishing”, the case file reads: this hostname appeared on the build dated the fourteenth with a DNS status of resolving and a phishing categorisation, and appeared on eleven consecutive builds thereafter.
What the match does is remove one specific uncertainty from the middle of the process, at a cost of roughly a quarter of a cent, and remove it in a form you can put in a case file. That kind of record is checkable by anyone holding the same subscription, it does not depend on trusting the complainant, and it is exactly the sort of statement that holds up when a registrant's lawyer asks what you actually knew and when you knew it.
A lookup in the ticketing pipeline, a nightly join against the zone, and an optional check in the provisioning path. Everything else is reporting built on top of those three.
Start here, because it pays back fastest and changes no customer-facing behaviour. Whatever parses inbound abuse mail already extracts hostnames; add a single GET against the check endpoint for each extracted name before the ticket is created. The response carries domain, is_phishing, category, dns_status, last_checked, confidence and database_size — enough to set a queue, stamp a priority and attach dated evidence without an analyst touching it. Where one message names several domains, use the batch endpoint instead.
Pull the day's CSV and the changelog, join against your sponsored-names table, write the intersection to a table stamped with the build date, and alert only on the delta. Keep the archived builds. This is the piece that turns the whole exercise from a lookup service into a measurement programme, and it is typically fifty lines of whatever language your operations team already writes in.
A check at domain:create time catches the narrow case of a name used for phishing, dropped, and now being re-registered while still on the current build. It costs one credit to screen for. Be honest about the scope: this is not general-purpose registration screening, it will not recognise a brand-new name assembled from a wordlist five seconds ago, and treating it as a hard gate rather than a flag will annoy legitimate customers who happened to buy a name with a past.
# One hostname pulled from an inbound abuse report
curl "https://phishingdetectionapi.com/api/v1/check?domain=secure-login-example.tld&apikey=YOUR_KEY"
# Several hostnames from one report, or a slice of your own zone.
# Maximum 100 domains per request, one credit per domain.
curl -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{"apikey":"YOUR_KEY","domains":["example-one.tld","example-two.tld"]}'
# Nightly portfolio intersection, once the CSV feed is in place
sort -u sponsored-names.txt > /tmp/zone.sorted
cut -d, -f1 feed-today.csv | sort -u > /tmp/feed.sorted
comm -12 /tmp/zone.sorted /tmp/feed.sorted > exposure-$(date +%F).txtMost of these are objections rather than questions, and they deserve straight answers rather than reassurance.
That is a policy decision for you and your counsel, and this page will not pretend otherwise. What the match gives you is a dated, reproducible observation that a specific hostname was resolving and hosting phishing on a specific build — evidence of confirmed live phishing hosting, and nothing beyond that.
The feed, without much doubt. Checking four million names daily through the API would be four million credits a day, whereas the feed is one download of the complete database after which matching happens on your own infrastructure at no per-lookup cost — and it removes any dependency on an outbound call succeeding during your nightly batch window. The API then earns its place alongside the feed rather than instead of it, which is why most registrars of any size end up running both.
Include them in the intersection as a separate group. You hold the zone that makes the host reachable, so you will receive reports about them regardless of who sold the name, and knowing which of them are confirmed phishing hosts before the report arrives is worth the credits.
No, and any list claiming otherwise is describing a heuristic rather than a verified observation. Inclusion requires the domain to have been observed resolving and confirmed as hosting phishing, which means something has to happen before it can be recorded. A name registered ten minutes ago and not yet used will not be there.
You now get to have the conversation with numbers instead of impressions. Group your daily intersection by reseller, look at the share and the trend over a couple of months, and take that to the channel manager. The useful metric is not raw count, which merely tracks volume, but matches per thousand names sponsored through that reseller measured against your book average. What usually follows is a tightening of verification on that channel rather than termination.
Less than most people hope. Contact data on names used for phishing is routinely fabricated, and the published abuse contact frequently points at a mailbox nobody reads, so any escalation route depending on it dead-ends quietly. Treating the record as an identity signal will mislead you in both directions.
Two arguments, and the second is the stronger. The first is analyst hours: if classification currently dominates the per-ticket cost, cutting it changes the staffing arithmetic on a desk that is almost certainly behind. The second is that you cannot currently answer the question "how many of our own names are hosting phishing today", and every party who matters — registries, accreditation bodies, enterprise customers, banks — increasingly assumes that you can.
Registrars sit next to hosting, DNS and brand teams, and the same daily list is doing different work in each of those places.
The same intersection logic applied to customer sites rather than sponsored names, including compromised-account handling.
Read the use caseHow resolver operators load the same daily file to answer queries locally instead of asking anybody about them.
Read the use caseThe view from the other side of the abuse report, and why the notices arriving in your mailbox look the way they do.
Read the use caseDelivery format, the added and removed changelog, and what a nightly pull actually looks like in practice.
See the feedOne sorted join against a daily list of DNS-verified phishing domains produces a number no vendor can hand you, because it is computed from your zone. Start with the API for a sample of the book, or the daily feed if you intend to run the intersection every morning.
