This page is written for the people who actually run an agency's mail gateway, its recursive resolvers and its web estate — not for the committee that approves the budget. It covers where a DNS-verified known-bad domain lookup belongs in a public-sector stack, how to write it into a specification, what it costs per lookup, and the specific things it will not do for you.
Before anything can be defended, somebody has to be able to say what exists. In public sector IT that sentence is much harder than it sounds.
Ask a state CIO for a list of every hostname the state publishes to the public and you will get an estimate, not an inventory. Departments procure independently, and the estate accretes one appropriation at a time.
Each of those sits on its own hostname, frequently outside the main second-level domain, frequently with its own certificate, its own visual style and its own login form. That sprawl is not incompetence — it is the direct consequence of budgets that are appropriated by programme rather than by platform.
Every additional hostname you publish is another shape a citizen has been trained to accept as legitimate. When your permit payment system lives at a name that shares no visual or structural relationship with your main site, you have taught the public that a government service can look like anything at all. An attacker registering a hostname that reads plausibly as a licensing or court portal is not fighting an established expectation; they are joining a crowd of legitimate services that already look nothing like each other. The clone does not have to be good. It only has to be no stranger than the real thing.
Usually the tier with an actual security operations function, and just as usually the tier with isolated or restricted enclaves that no live API can reach. Here the value sits in the offline file and the per-build changelog rather than in the query endpoint, because the mechanism has to survive a boundary review.
A central security office with real staff sits above constituent agencies whose technical capacity ranges from a dedicated team to one contractor. The workable shape is one balance and one feed held centrally, exposed inward, rather than thirty separate procurements each repeating the same evaluation.
A handful of IT staff carry benefits determinations, property records, court dockets, licensing registers and child welfare case files across departments that barely share a directory. The estate is fragmented, the data is unusually consequential, and nobody has time to run anything that needs weekly tuning.
A city of forty thousand people typically has one or two people who own everything with a power cable, including the phone system and the door badges. They will not stand up a detection pipeline, tune a model or run a threat hunting programme, and any proposal assuming they will is written for a different customer.
What a two-person department can realistically do is add a blocklist to a resolver they already operate, or wire a single HTTP call into a mail gateway rule. The realistic question for a small municipality is not which platform to adopt but which one mechanical control returns the most for the least ongoing attention — and that question has a different answer from the one a federal security operations centre would give.
A narrow, mechanical control: given a hostname, is it currently a verified live phishing site? It does not replace multi-factor authentication, mail authentication records, or the segmentation work that keeps a compromised account from reaching a case management database. It sits underneath all of that as a floor.
That is the frame for the rest of this page. A control of this shape is unusually well suited to teams whose scarcest resource is attention rather than money. For the policy-level and citizen-trust argument — the one you would put in front of a council or an oversight committee — the companion piece on phishing in the government and public sector covers the obligation landscape rather than the rollout.
Public sector buying runs on written requirements. These clauses are drafted to be adapted, with bracketed placeholders where your agency's own terms belong.
Almost every control an agency buys is aimed at the first group. The second group is larger, more exposed, and is where the reputational damage actually lands.
Start with the employee, because that is the population you have leverage over. Agency staff get phished into internal systems in a handful of repeatable ways:
None of these are creative. They work because they are indistinguishable from the twelve legitimate notifications the same person received that week, and because a public-sector job frequently involves opening unsolicited attachments from members of the public as a matter of routine. A caseworker who refuses to open unexpected documents cannot do the job.
Employee-facing systems — the case management application, the payroll self-service portal, the timekeeping tool, the grants management platform, the learning system that carries mandatory training — are typically a set of third-party tenants, each with its own login page on its own vendor hostname. Staff have been conditioned to authenticate on domains that are not yours, which removes the one heuristic that might otherwise protect them. "Check the address bar" is advice that only works when there is a single correct address to check against, and in most agencies there are dozens.
A compromised account in a private company usually reaches that company's own data. A compromised account in a county government may reach benefits determinations, property records, a court docket, a licensing register, a child welfare case file, or a payment approval queue — datasets belonging to people who never chose to do business with you and cannot take their custom elsewhere. That asymmetry is why a floor-level control that removes the mechanical, high-volume lures is worth more here than the identical control is worth in a commercial setting.
A member of the public interacting with a benefits application, a tax filing portal, a licence renewal, a permit payment or a court records search has no way to verify what they are looking at. They do not know your real hostname. They have no prior visit to compare against, because most people touch a given government service once every few years at most. They arrive through a search result or a link somebody forwarded, and the genuine service and the impersonation are both blue links on a page. Attackers know this, which is why grant portals and disaster relief applications are cloned within days of being announced — the announcement does the marketing for them, and the audience is by definition people under financial pressure who have never used the programme before.
Because you cannot train the second population, those three moves all operate on the attacker's infrastructure rather than the citizen's judgement. The third is the one most agencies skip and the cheapest of the three: generate the plausible variants of your public-facing names and push them through the batch endpoint a hundred at a time on a schedule.
-portal, -benefits, -payments or -gov.Most will come back clean forever. When one comes back marked as a verified live phishing host, you have a dated, machine-generated record to attach to a takedown request with the registrar and a concrete artefact your communications team can build a public notice around. The related mechanics run deeper on the brand protection and identity protection pages.
Public safety and investigative units have their own exposure profile, addressed on the law enforcement page, and any agency that operates public access terminals — a library branch, a one-stop centre, a records reading room — inherits the shared-hardware problem set out on the public libraries page, where the person at the keyboard changes every forty minutes and per-user policy simply does not exist.
Six obligations most public bodies already carry, mapped honestly against what a known-bad domain check does and does not satisfy.
The mapping is deliberately modest. A domain check is one contributing control against each of these obligations, never the whole of any one of them.
The difference between a verified list and an accumulated one decides whether the file is usable inside a resolver at all.
Most freely circulating blocklists are accumulations. A domain gets reported, it goes on the list, and it stays there because removing entries is work nobody is funded to do. Two or three years in, the majority of the file is archaeology: parked domains, expired registrations, hosts taken down long ago. That is tolerable in an analyst's spreadsheet and genuinely harmful inside a recursive resolver.
This database is rebuilt every twenty-four hours and each entry is confirmed to be currently resolving in DNS. Domains that stop resolving are dropped from the build rather than retained, which is why the total moves in both directions rather than only upward.
A mail rule can branch on the verdict while an analyst reviewing the same event weeks later can see when the determination was made.
It is what lets a resolver reload be a diff rather than a wholesale replacement, which in turn is what keeps local exceptions intact across an update and produces a defensible answer when somebody asks why a particular hostname stopped being blocked on a particular Tuesday. Agencies running isolated networks move the same file across the boundary on their normal transfer path; the feed is plain CSV precisely so it survives whatever review process sits at that boundary. Teams pushing the same data into detection tooling will find the mechanics on the SIEM integration and DNS filtering pages.
Each one is a small change to something you already operate. None requires an agent on an endpoint or a new appliance in a rack.
Extract the host from every URL in an inbound message, deduplicate within the message, and batch the remainder. A message carrying a verified live phishing host should be quarantined rather than tagged, on the reasoning that a warning banner asks a caseworker under deadline pressure to make a security judgement they are not equipped to make. Deduplication is the difference between a sensible credit bill and a silly one: a newsletter with forty tracking links resolves to a handful of distinct hosts, and you should pay only for the distinct ones. The neighbouring detail work is covered on the email security page.
Loading the daily feed into whatever recursive DNS you already run means every device on the network — the desktop, the kiosk in the lobby, the tablet in the inspector's truck, the phone on staff Wi-Fi — is covered by the same list without anybody installing anything anywhere. It also catches the links that never touch email: the ones in text messages, in QR codes printed on a poster, in a chat application, in a PDF opened from a USB stick. That breadth is the argument for the feed model over per-query lookups when the team is small.
Screen the outbound links in notification templates before a campaign goes out, and check the referrer on arrival at a login page so a session that came from a known clone can be interrupted before credentials are typed. This is the only one of the four insertion points that protects somebody who has never met your IT department and never will.
When a supplier, contractor or grantee sends a change of banking detail, the hostname in the message and any link it carries go through the check as one step in a verification procedure that must still include an out-of-band callback to a number you already held. The lookup narrows the problem. It does not close it, and any procedure treating a clean verdict as authorisation to move public money has misunderstood what the control is.
The integration itself is one HTTP call. The single-lookup form is a GET against /api/v1/check; the batch form posts up to a hundred hostnames and consumes one credit per hostname. The key is passed as a query parameter or in the POST body and must live server-side only — never in browser-delivered JavaScript, a mobile bundle, or a repository a supplier can read.
# Single hostname — one credit
curl -s "https://phishingdetectionapi.com/api/v1/check?domain=state-benefits-renewal.example&apikey=$PDA_KEY"
# Batch — up to 100 hostnames per request, one lookup each
curl -s -X POST "https://phishingdetectionapi.com/api/v1/batch" \
-H "Content-Type: application/json" \
-d '{
"apikey": "YOUR_SERVER_SIDE_KEY",
"domains": [
"county-permit-pay.example",
"municipal-court-records.example",
"disaster-grant-apply.example"
]
}'
# Response fields you can branch on:
# domain · is_phishing · category · dns_status
# last_checked · confidence · database_sizeParameter reference and further language examples live on the API documentation page.
Nothing below requires a project charter, a new vendor onboarding cycle, or a change that cannot be undone in an afternoon.
List every public hostname the agency owns, including the ones a department bought without telling you, and every mail domain that delivers into your tenant. This list is the input to everything that follows, and building it is usually the longest single task on the whole rollout.
Count the distinct URL hosts in a normal week of inbound mail after deduplication. That number, multiplied by fifty-two, is your annual mail-gateway consumption and the only figure you need in order to size a monthly plan on the pricing page.
Wire the check into the gateway but take no action on the verdict — log it alongside what the existing controls decided. Two weeks of that data tells you the marginal catch rate and gives you something concrete to show a sceptical director before anything is enforced on live mail.
Turn quarantine on for verified hits, then schedule the daily feed download into your recursive DNS. Do these a week apart, so that if a complaint arrives you know without investigation which of the two changes caused it.
Screen links in citizen notification templates before send, add the referrer check to your portal login pages, and start the scheduled batch sweep across permutations of your own agency names so a clone surfaces in your tooling rather than in a complaint.
Record the control, its owner, the evidence it produces and the date of its next review. A control nobody reviews is a control that quietly stops working the next time a mail platform is migrated, and migrations happen considerably more often than reviews do.
Both halves belong in the same section, because a control you have oversold is worse than one you never deployed.
The commercial model is deliberately simple, which is exactly what lets it survive a public sector purchasing process. Plans are monthly subscriptions via PayPal with no per-seat licence. Cancel any time, which means the engagement can be scoped to a single fiscal year without multi-year commitment — the specific characteristic that makes a tool adoptable by a department which cannot commit next year's budget.
A department of six hundred staff whose mail gateway resolves in the region of two thousand distinct hosts a day lands close to three-quarters of a million lookups a year, which is the Enterprise band. A city of forty thousand residents with ninety employees is usually comfortably inside Professional. The feed sits outside the ladder because it replaces per-query consumption rather than adding to it — for a resolver deployment covering an entire network, it is almost always the cheaper shape.
This is a known-bad lookup. It answers whether a hostname has already been observed and verified as a live phishing site, and that sentence contains everything it does not do:
A shared hosting provider that has carried phishing content can be flagged in a way that inconveniences somebody legitimate on the same infrastructure, which is why any enforcement path needs a documented route for a member of the public or a supplier to report a bad block and have a person look at it. Agencies that treat this as a floor and build the rest of the stack on top of it — mail authentication, phishing-resistant multi-factor authentication, least privilege on the systems holding citizen data, an incident response runbook that has actually been rehearsed — get real value from it. Agencies that present it to an oversight body as comprehensive protection are arranging a much harder conversation for themselves later, and that conversation is entirely avoidable by saying the limits out loud now.
Every query produces a timestamped record of a hostname and a verdict. Over a year that becomes an unusually clean audit artefact: what was checked, when, what the answer was, and what the system did next. Auditors and oversight committees rarely ask whether a control is sophisticated. They ask whether it was operating on a given date and whether anyone can prove it, and a query log answers that question without anybody reconstructing anything from memory.
These come up in roughly this order, usually in the same meeting.
A per-query lookup sends one hostname and your API key, and nothing else.
Not as a live API, no — a query endpoint needs a route to reach. The feed subscription exists for exactly this case: the complete database is published as CSV, which you move across your boundary on whatever transfer path you already have approved.
It shows up once it has been observed and DNS-verified, and appears in the next daily build after that. There is no honest way to promise a fixed interval between a domain being registered and it being known, and a supplier offering you one is describing marketing rather than mechanism.
Yes, and it is one of the higher-value uses for a public body. Generate the plausible permutations of your own hostnames and push them through the batch endpoint on a schedule — a hundred per request, one lookup each.
It will happen occasionally, most often with shared hosting infrastructure that has carried phishing content alongside legitimate sites. Build the exception path before you enforce anything, not after the first complaint arrives.
lookups reset monthly from purchase, so a package bought at the end of a fiscal year is still usable well into the next one.
Not necessarily, and the central shape is usually the better one.
Size a monthly plan against your own measured mail volume, or take the whole database as a daily file and run every comparison inside your own boundary.
