Written for the people who run security inside a health system rather than the people who approve the budget. This is about where a DNS-verified list of currently-live phishing domains actually sits in your plumbing — the resolver, the mail path, the service desk — and what changes when the endpoint is a shared workstation that eleven clinicians will tap into before lunch.
The case for taking hospital phishing seriously is already made elsewhere. What follows assumes you are convinced and are now deciding where the check goes.
There is a version of this conversation aimed at an executive committee, and it is a legitimate document: it explains why a credential is the usual entry point for an encryption event, why a diverted ambulance is a clinical outcome rather than an IT metric, and why the recovery bill is dominated by lost clinical revenue rather than forensics. That version lives on our healthcare industry brief, and if you need something to hand a board, start there. This page is the other half. It assumes the argument is settled and picks up at the point where somebody has to decide which box the list lands on, who owns the exception process, and what happens at three in the morning when a block fires on a domain a consultant swears is legitimate.
A board wants a risk narrative; a security engineer wants the shape of the data. So the facts first, without decoration: the database holds more than 390,000 phishing domains, and the condition for staying in it is that the hostname currently resolves in DNS. Entries that stop answering are dropped rather than retained, which is why the active count is far smaller than the all-time observed count, and why the file you load each morning is a description of live infrastructure rather than a museum of things that used to be dangerous.
The rebuild runs every 24 hours and ships with a record of what was added and what was removed. A blocklist without a diff forces you into a full replace every day, which quietly destroys any local exception you added and gives you no way to answer the question your change-advisory board will inevitably ask, namely what specifically changed since yesterday. With the changelog you can reload incrementally, keep your allow-list applied after the import, and produce a one-line record of the delta for the change ticket. In a hospital, where every resolver change touches systems clinicians depend on continuously, that record is worth more than the raw block count.
The check itself is deliberately narrow. It answers one question — is this hostname on a verified list of active phishing infrastructure — and it answers in well under 50 milliseconds, which is the property that lets it sit inline in a mail path without anyone noticing. It does not read the page. It does not score the sender. It does not decide whether an unfamiliar domain is suspicious. Every one of those jobs belongs to a different control, and pretending otherwise is how security teams end up with a tool nobody trusts. What this does is subtract a large, already-catalogued population of known-bad destinations from everything downstream, so your mail rules, your analysts and your clinicians spend attention on the genuinely unknown.
This is a health system's environment rather than a generic enterprise's, and four differences drive every recommendation on the page:
If your environment looks more like a payer than a provider, the health insurance page covers the claims-side version of the same problem, and pharmaceutical covers manufacturing and research supply chains.
Most health systems already run a competent mail security stack. The residual risk sits in the paths that never touched it.
If you are reading this you almost certainly already rewrite URLs, detonate attachments and score senders. Those controls work, and this is not an argument that they do not. The argument is about what is left over: the message that reached a personal phone as a text rather than a mailbox, the QR code on a printed poster in a staff room, the link a colleague pasted into a chat channel, the search result a coder clicked while looking for a payer's provider portal. None of those crossed the gateway. All of them end at a hostname that has to resolve before anything bad can happen, which is the single point where one control can cover every one of those paths at once. Our email security page covers the message-layer half in its own right.
It sees mail. It does not see the browser on a workstation in a treatment room, a phone on the guest network, or a clinical application that opens an external link in an embedded browser with no policy attached to it.
Every device that uses your DNS is covered, regardless of how the link arrived or which application opened it. One configuration change on the recursive resolvers reaches the clinical VLANs, the corporate estate and the staff Wi-Fi in a single move.
/api/v1/check endpoint for on-demand verification in a ticket workflow. Most health systems end up running both, and they draw on exactly the same verified database.Almost every assumption in commercial endpoint security breaks on a computer on wheels parked outside a treatment bay.
Enterprise security is built on the premise that a person owns a device. Conditional access, device trust, per-user browser policy, an agent that knows whose laptop it is — all of it assumes a stable relationship between a human and a machine. On a ward that relationship does not exist. The workstation in the corridor has no identity beyond an asset tag and a location, and the only durable statement you can make about its user is that they will be gone in a couple of minutes.
Proximity sign-on exists so that authenticating stops being a thought. Tap, the desktop is yours; tap out, it locks. By the tenth time in an hour the interaction is as automatic as opening a door, which is precisely the reflex a cloned login page is built to borrow.
Rotational staff never build familiarity with which internal systems exist, which is exactly the knowledge that makes an unfamiliar sign-on page feel wrong. They also leave before any awareness campaign aimed at them completes its cycle.
Dispensing, benefits checks and controlled-substance workflows all authenticate independently of the EHR. When four different credential prompts are routine, a fifth one is not information — it is Tuesday.
When an alert fires you frequently cannot say who was at the keyboard without correlating badge-tap logs held by another team on another retention schedule. A fifteen-minute investigation on an assigned laptop becomes half a day of joining data.
Some sessions exist only to record a specimen and move on. There is no browsing, no reading, no scrutiny — just the fastest possible path through whatever is on screen, including anything that looks like a login the workflow expects.
Out of hours the informal verification channel — leaning over and asking a colleague whether they got this too — is not available. This is the shift where a documented, thirty-second lookup beats a phone call and a hope.
User judgement is a weak control here, and any design that leans on it is leaning on the wrong thing. It is also why a phished session on a shared workstation behaves less like a compromised account and more like contamination. Session artefacts, cached tokens and a browser profile the reimaging script may or may not clear before the next badge tap all sit on a device a dozen people will authenticate to next. Most health systems run some form of session reset and most of the time it works, but the reset happens after the credential has already left the building in somebody else's hands.
Shared clinical desktops accumulate bookmarks, pinned tabs and desktop shortcuts added helpfully by staff over years, pointing at payer portals, reference tools, transcription services and vendor login pages. Nobody reviews them. Export that list from your imaging platform and run the hostnames through POST /api/v1/batch, a hundred at a time, one lookup each. For a whole estate that is an afternoon and a few thousand credits, and it occasionally turns up a domain that changed hands since somebody pinned it. The same pattern is covered in more depth on our DNS filtering page.
Each has a different pretext and a different victim, and each needs a hostname that answers DNS at the moment of the click.
The pretexts below are not exotic. They recur across provider organisations of every size because they are built on things a health system genuinely does every week: a password reset before a mandatory training module, a payer requesting supporting documentation, a device vendor asking to join a remote session, a patient being told their results are ready. The lure works precisely because the legitimate version of it lands in the same inbox on the same day. What all six share is a structural weakness the attacker cannot design around — the fake page has to live at a registered hostname with a working A record, and that hostname is either on a verified list of active phishing infrastructure or it is not.
A reproduction of the federated login that fronts Epic, Cerner or Meditech, reached from a message about an expiring password or a competency module. One captured session opens the record, secure messaging and every departmental system behind the same identity provider.
The victim is not on your payroll. Patients get a message about a result, a balance or an appointment, pointing at a copy of your portal login. You carry the brand damage and the notification duty with no control over the device involved.
Revenue-cycle and coding staff live inside payer web portals and switch between several a day. A lookalike claims or remittance login is unremarkable to somebody who legitimately signs into six different insurer sites before lunch.
Prescriber portals, controlled-substance workflows and pharmacy benefit systems all authenticate separately from the EHR. That separation is exactly what makes an unfamiliar login screen feel normal rather than alarming.
Imaging modalities, infusion systems and lab analysers are serviced remotely by manufacturers who genuinely send join-this-session links. A fake one arrives in the same format, aimed at biomedical engineering rather than at clinicians.
Video visit invitations are short, urgent, mobile-first and frequently opened by patients who have never used the platform before. A lookalike join page harvests the portal credential and, on the way through, whatever payment detail it asks for.
Two of the six deserve a note about who owns the response, because they sit at opposite ends of the range and neither is well served by a general awareness campaign.
The value of this list is not its size. It is the rule that decides what is allowed to stay in it.
Most blocklists only grow. Something gets reported, it gets added, and it stays added because removing entries is unglamorous work with no obvious payoff. Over a few years that produces a file that is enormous, mostly historical, and increasingly expensive for a resolver to hold in memory — while quietly training the operators who maintain it to distrust it, because most of what it flags has been dead for months. The discipline here runs the other way. A domain qualifies by resolving now, verification runs on the rebuild cycle, and anything that stops answering falls out of the next build. The active figure sits above 390,000 because that is how many are currently live, not how many have ever been observed.
Seven fields come back, and every one of them is a fact rather than an opinion:
That bluntness is deliberate — a control that returns a probability invites a debate, and a control that returns a fact gets acted on. It also makes the data trivially easy to correlate with everything else in your threat-intelligence pipeline.
Every entry is confirmed to answer DNS. Dead infrastructure is dropped rather than archived, so the file your resolver parses each morning describes today.
A full rebuild every 24 hours plus a changelog of additions and removals, so an incremental reload is possible and your local exceptions survive it.
Typical lookup latency under 50 milliseconds. Fast enough to sit in a mail path or a portal link-check without anyone noticing it is there.
Up to 100 domains per request against /api/v1/batch, one lookup each — which is how bookmark audits and portal permutation sweeps get done cheaply.
In an environment where uptime is a clinical requirement, the interface a control presents to the user is a safety decision.
Security controls that ask the user a question are popular because they feel proportionate. Show an interstitial, explain the risk, let the person decide. In an office that is a reasonable trade. On a ward it is a bad one, and the reasons are worth setting out because they are not obvious to anyone who has not watched a clinician work — a prompt is an interruption in a workflow where interruption has a documented cost. Line the two designs up against each other and the gap is not subtle.
| On a ward | Interstitial that asks the clinician | Silent block at the resolver |
|---|---|---|
| What appears on screen | A dialogue mid-task, one-handed, on a screen somebody else is waiting to use. | A browser error or a plain block page where the login form would have been. |
| Decision demanded | One, at the worst possible moment — and the fastest way past it is always the button that continues. | None, so there is no decision available to get wrong. |
| Effect of repetition | A clinician who has cleared fourteen benign warnings this month has learned that warnings are noise; the fifteenth gets the same reflex. | Nothing accumulates. There is no queue of prompts eroding the credibility of the next one. |
| Cost to other systems | Devalues every dialogue already there, including the ones from clinical systems that genuinely need a considered answer. | Spends none of the scarce attention that clinical decisions are competing for. |
| Service-desk load | A potential call for every warning, on a system that generates thousands. | No ticket in the ordinary case — the user does not arrive, shrugs, and goes back to work. |
| Who carries the risk | The person with the least time and the least context to assess it. | The control, which was given the verified answer before the click happened. |
A control in the path of clinical work is a control that can break clinical work, and any hospital security team that has been through a bad change knows exactly how that conversation goes. The mitigation is architectural: use the feed rather than a live per-query dependency. You download the full database once a day and match locally, so there is no outbound verdict service in the request path, no third party whose outage becomes your outage, and no latency added to name resolution beyond a local lookup. If connectivity to the vendor fails, your protection keeps working with yesterday's list, which is a very different failure mode from a page failing open or hanging.
Load the list, log matches, block nothing, and let it sit for two or three weeks across a full on-call rotation. You will learn the real hit rate on your own network, discover any overlap with a resource your staff genuinely use before it becomes an incident, and arrive with a number that came from your environment rather than a vendor's brochure. Two weeks of observation is also long enough to write an exception process a night-shift engineer can execute without waking anyone up, and to find out whether the person who owns that process is actually reachable at four in the morning.
Nothing here needs a project, a new appliance or a change to how clinical staff work. Each step stands alone and each one backs out in minutes.
Take the hostnames from six months of reported-phish tickets and run them through the check endpoint. You learn the hit rate on your traffic before committing to anything.
Import the daily CSV into the recursive resolvers, log matches, block nothing. Two to three weeks gives you a defensible number for the change board.
Turn blocking on for the corporate estate and staff Wi-Fi first, then the clinical VLANs once the exception path has been exercised at least once out of hours.
A scheduled download, a sanity check on file size before it replaces the live copy, your allow-list re-applied after import, and one alert if the file goes stale.
The whole integration surface is small enough to describe in one section, which is deliberate.
A single lookup is a GET against /api/v1/check with a domain and a key. That is the call your service desk wraps in an internal tool so an agent can paste a hostname from a reported message and get an answer while the caller is still on the line. It is also the call a portal team puts behind a link-preview feature. The key travels as a query parameter or in a POST body and must stay server-side — never in client-side code where a browser, a patient's device or a page source can read it.
curl "https://phishingdetectionapi.com/api/v1/check?domain=portal-login-verify.example.com&apikey=YOUR_KEY"
{
"domain": "portal-login-verify.example.com",
"is_phishing": true,
"category": "phishing",
"dns_status": "resolves",
"last_checked": "2026-07-27",
"confidence": 0.98,
"database_size": 391284
}The batch endpoint is where the periodic work happens. POST /api/v1/batch takes a JSON body containing your key and an array of up to 100 domains, and bills one credit per domain. Three jobs fit this shape naturally: the shared-workstation bookmark audit described earlier, a monthly sweep of hostname permutations around your patient portal and telehealth platform, and a check of every external domain referenced in your own patient communications before a campaign goes out. None of them are urgent, all of them are cheap, and each one produces a short list a human can act on.
curl -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{
"apikey": "YOUR_KEY",
"domains": [
"myhealth-portal-login.example.com",
"patient-results-secure.example.net",
"telehealth-join-visit.example.org"
]
}'For enforcement, neither endpoint is the right tool. The daily feed is a separate subscription that delivers the complete database as CSV plus the added and removed changelog, and it is what you point at a DNS resolver, a firewall blocklist or a SIEM ingest pipeline. Matching happens locally, which means no per-query traffic leaves your network, no lookup is billed, and protection is unaffected by the state of your connection to us. There is also a database-stats endpoint returning the current size and last-update timestamp without consuming credits, which is exactly what your monitoring should poll to confirm the list is still moving. Full parameters are on the API documentation and delivery options on the daily feed page.
Credits are one per lookup, billed monthly, bought through PayPal, with no subscription and no per-seat licence on the API itself:
The full table is on the pricing page. Network-wide enforcement runs on the feed instead, where the cost does not scale with the size of your estate.
Security work in a health system has to leave a paper trail that survives a compliance review. Here is what this one produces.
The HIPAA Security Rule expects technical safeguards over electronic protected health information and a risk analysis explaining why the ones you chose are reasonable and appropriate. A control that blocks verified credential-harvesting destinations, that is refreshed daily, and that logs every match is straightforward to describe in that language.
That is a control with an operating history rather than a policy statement, which is the difference a reviewer is actually testing for.
Resist the urge to log more than you need. A match record wants four fields and no fifth one:
It does not want a clinician's name attached, and on a shared workstation you frequently could not attach one accurately anyway. The local-feed model helps here too: because matching happens on your own infrastructure, no record of what anyone on your network looked up is transmitted anywhere, and the only outbound call is your authenticated download of the list.
When a lookalike of your patient portal goes live, the first question leadership asks is how long it has been up and who saw it. A scheduled batch sweep gives you a dated answer, and a dated answer is what a takedown request, a registrar complaint and a patient notification all need.
It lets communications get ahead of the call volume with a banner on the real portal and a script for the contact centre, rather than reacting to the first patient who reports a fraudulent charge. Our brand protection page goes further into monitoring patterns.
A resolver match is a high-quality, low-volume signal: somebody on your network tried to reach infrastructure that was verified as hostile. Feeding it into existing correlation rules costs almost nothing and tends to surface the early stage of a campaign rather than the late one.
Cluster matches by source and time and you can usually watch a mailing land as a burst of attempts from different subnets within a few minutes. Our incident response page covers what to do with that burst.
A known-bad lookup is a floor, not a ceiling, and any deployment note you write should say so in the first paragraph. Four gaps are worth writing down explicitly:
None of that is an argument against the control; it is an argument for knowing its shape. Phishing-resistant authentication remains the single highest-value investment a health system can make, because it removes the value of the credential rather than the reachability of the page. Segmentation, tested backups, mail authentication and a service desk that knows how to verify a caller all sit alongside this and do jobs it cannot. What this layer contributes is the removal of a large, already-known population of destinations from every path at once, at a cost measured in fractions of a cent, at the one stage of the chain where intervention is still cheap.
These are the objections that come up in the first meeting, and most deserve a straight answer rather than a reassurance.
Coverage of everything that did not arrive by mail, and coverage of what happens after delivery. Rewriting protects the message path and nothing else, which leaves four common routes uncovered:
Plan for it and it stops being an incident. DNS verification keeps the false-positive rate low — a domain has to be observed as active phishing infrastructure and confirmed to be resolving before it enters a build — but no list is perfect, and in a hospital the correction path matters more than the error rate. Three things make that path work:
Not if you deploy the feed, which is the recommended pattern for exactly this reason. You download the complete database once a day and load it into your own resolver or firewall, so every subsequent comparison happens on your infrastructure and the only outbound traffic is the authenticated download of the list itself. The distinction between the two deployments is worth holding on to:
With the feed, it does not notice. Matching is local, so an upstream problem degrades your internet connection but never your enforcement — the resolver keeps blocking using the copy it already holds, there is no verdict service to be unreachable at an inconvenient moment, and nothing in the DNS path can hang waiting for a remote answer. The one real failure mode is a list that silently stops refreshing, so guard against that instead:
Directly, only your staff and anyone on your networks — a patient using their own phone at home never touches your resolver, and pretending otherwise would be dishonest. What the same dataset gives you for patients is early detection rather than enforcement: a scheduled batch sweep of plausible variations on your portal and telehealth hostnames tells you when a lookalike is live and resolving today. That dated finding is what four other people can act on:
No, and you should be wary of anything sold that way. Nothing here certifies you, and we make no claim about your compliance status. What the control does is contribute concrete evidence in an area the Security Rule genuinely cares about: technical safeguards over ePHI, and a risk analysis showing you identified a known threat vector and applied a reasonable measure against it. The useful artefacts are the ones a reviewer can date:
Wherever those segments resolve names, which in most health systems is a small number of internal recursive resolvers regardless of how many VLANs sit in front of them. That is what makes this tractable — one change on the resolvers reaches the clinical networks, the corporate estate and the guest Wi-Fi without touching a single endpoint or asking biomedical engineering to approve an agent on a regulated device. Two boundaries are worth stating honestly when you scope it:
The database is rebuilt every 24 hours and each domain is DNS-verified, so only hosts that currently answer are included. That verification rule is why the active figure sits above 390,000 rather than in the millions — anything that goes dark drops out of the next build instead of accumulating as ballast in a file your resolver has to parse every morning. You do not have to take the aggregate claim on trust either:
last_checked on every response tells you the freshness of that individual verdict.dns_status tells you the host was answering when it was tested.Test the list against the hostnames in your own reported-phish tickets, run it in monitor mode across one on-call rotation, and take your own numbers to the change board. If network-wide enforcement is the goal, the daily feed is the deployment that keeps every lookup inside your perimeter.
