National agencies, regional administrations and municipal councils are impersonated more relentlessly than almost any commercial brand, because a message that appears to come from a tax office, a benefits agency or a licensing authority carries an authority no retailer can buy. Phishing Detection API supplies the one piece most public bodies are missing: a continuously rebuilt list of phishing domains that are verified to actually resolve.
A lookalike public-service domain costs almost nothing to register and converts at rates a commercial brand cannot match.
Citizens are conditioned to comply with the state. A letter with a crest on it gets opened, a text message about a payment gets read, and an email with a deadline in it gets acted on within the hour. An attacker who registers tax-refund-claim.example.com inherits, for a few days at least, the accumulated authority of an institution that has been sending demands and payments to the same population for a century. No retailer, no bank and no airline can offer an attacker that much borrowed credibility for that little outlay.
The lure catalogue is small and remarkably stable, and tax is the biggest single category: refund lures that promise money back, and demand lures that threaten interest, enforcement or a visit — usually timed to a filing deadline the whole country already has in mind.
Benefits and grant payments are the second category: a message claiming a payment has failed, an eligibility review is due, or a cost-of-living supplement needs a bank detail confirmed. Driver licensing and vehicle taxation produce a steady clone industry of renewal and penalty pages, because renewal is genuinely periodic and citizens genuinely do not remember when theirs falls due. Court summonses and penalty notices exploit fear rather than greed, and they work on people who would never click a prize link.
These target applicants unfamiliar with the country's real procedures, often paying in a second language, often already expecting to be charged something by a system they do not fully understand. A clone that takes a plausible fee and issues a plausible reference number can run for months before anyone complains.
Within hours of an emergency declaration — flood, wildfire, earthquake or storm — lookalike relief-grant and donation domains appear and begin resolving, aimed at people who have just lost a home and at donors who want to help immediately. The agency running the relief programme is, at that exact moment, the least able to spare anyone to watch for them.
When a bank's customers are phished, the bank absorbs a large share of the loss and can therefore justify the controls. When a government is impersonated, the person harmed is a citizen with no relationship whatsoever to the agency's IT department. They do not use the agency's laptop, do not read its intranet notices, will never sit through its awareness module, and their mail is filtered by whichever consumer provider they happen to use.
The departmental CISO can harden every mailbox on the estate and the campaign will still succeed, because the campaign was never aimed at the estate. That is the argument for a shared blocklist rather than a purely internal control: if a lookalike benefits domain is identified once, verified as actually resolving, and published into a list that consumer ISPs, mobile operators, mail providers, browser vendors, filtering appliances and protective DNS services all consume, the citizen is protected by infrastructure they never had to configure.
The agency's own controls remain necessary, but they are not sufficient, and no amount of internal maturity changes that. This page is about how a public body contributes to and benefits from that shared layer without buying a platform, running a programme, or waiting for a procurement cycle to finish. Related reading: government use cases and DNS filtering integration.
Everything in the list has been resolved and confirmed to have an active A record before it reaches you.
The mechanism matters more to a public body than the headline number does. Domains are ingested from curated threat-intelligence and OSINT sources, then every candidate is resolved through rotating proxies using fifty concurrent threads with a ten second timeout. Only domains that return an active A record are retained; anything that has stopped resolving is pruned on the next pass. The result is deduplicated, classified as phishing/malware, diffed against the previous day to produce a changelog, and loaded into both the API and the exported CSV feed. That daily diff is what a fraud investigation lead actually wants, because it answers the operational question, which lookalike domains started resolving since yesterday, rather than the archival question of what was ever reported.
For an agency, the practical effect is a much lower false-positive burden on a resolver that serves citizens or staff. A blocklist stuffed with parked, sinkholed or long-dead domains creates noise in the DNS logs that a small security team has no capacity to triage, and it eventually erodes confidence in the block page itself. A list constrained to domains that resolve right now is smaller, more defensible in front of an audit committee, and far easier to justify when a service owner asks why a domain their supplier uses was blocked. The API documentation describes the response fields, including dns_status and last_checked, which are the two an analyst will reference when writing up an incident.
Protecting the workforce is the familiar job. Protecting the citizen who never touches your network is the harder one.
Every public body runs a workforce estate that looks broadly like a large enterprise: a shared services mail platform used across several departments, a document and records management system, an identity directory, endpoint management, and a set of case management applications specific to whatever the body actually does. In a benefits agency that means claim assessment and payment systems; in a licensing authority it means vehicle, trade or premises registers; in a municipality it means planning, council tax, waste and social care. The phishing that targets this estate is ordinary: credential harvesting against the mail platform, invoice redirection against finance, and increasingly convincing approaches to the people who administer citizen identity and verification services, because those accounts are worth more than the mailbox they sit behind.
The second job has no equivalent in most private-sector security programmes. A government's citizen-facing channel is a brand that is being cloned continuously, in a population that has no way of telling a real domain from a fake one and no support desk to ask. The people who own this problem are rarely in the security team at all. It is the digital service manager who owns the portal, the communications lead who has to warn the public, the contact centre that takes the calls, and the fraud investigation lead who assembles the case. The senior information risk owner sits above all of them and is the person who will be asked, after the fact, what the organisation knew and when.
The third job, which nobody puts on an org chart, is the supply chain. Public bodies pay grantees, suppliers, contractors and other public bodies, often in large amounts and on predictable schedules. A lookalike domain aimed at a supplier's finance office, or at a grantee expecting a disbursement, produces a loss that lands on public money just as surely as an internal compromise does. A small municipality that pays forty local suppliers is exactly as exposed proportionally as a ministry that pays four thousand, and has considerably less capacity to notice.
Check link domains at the mail gateway, the proxy and the protective DNS resolver before a civil servant ever sees a rendered page. The same lookup serves the SOC's triage queue when a staff member forwards a suspicious message, so the answer takes a second rather than a morning.
Screen domains reported through the contact centre, the online report-a-scam form and social media monitoring. A confirmed hit lets communications publish a warning the same day and gives the fraud investigation lead a dated, evidenced starting point for a case file.
Run supplier and grantee correspondence domains through the batch endpoint before a payment instruction is changed. Finance teams get a machine-checkable answer instead of a judgement call made under deadline pressure by someone who has never seen the real domain.
A government is the only party that can authoritatively state which domains are genuinely its own. Publishing a plain, permanent, easily-found list of verified official domains, and telling citizens that anything not on it is not you, is the cheapest control in this entire page. Pair it with an outbound flow: when your team confirms a lookalike domain, feed it to your national or sector CERT so it reaches the resolvers, filters and mobile operators your citizens actually sit behind. The API and the daily feed are the inbound half of that exchange; the CERT relationship is the outbound half, and a public body that does both is protecting people it will never meet.
curl -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{
"apikey": "your_api_key",
"domains": [
"benefits-payment-update.example.com",
"vehicle-licensing-renewal.example.net",
"courts-penalty-notice.example.org"
]
}'
{
"results": [
{ "domain": "benefits-payment-update.example.com",
"is_phishing": true, "category": "phishing/malware",
"dns_status": "resolves", "confidence": 0.98,
"last_checked": "2026-07-27T04:30:00Z" },
{ "domain": "vehicle-licensing-renewal.example.net",
"is_phishing": true, "category": "phishing/malware",
"dns_status": "resolves", "confidence": 0.98,
"last_checked": "2026-07-27T04:30:00Z" },
{ "domain": "courts-penalty-notice.example.org",
"is_phishing": false, "category": null,
"dns_status": null, "confidence": 0.0,
"last_checked": null }
],
"checked": 3, "phishing_found": 2, "credits_used": 3
}
Up to 100 domains per request, one credit per domain. The API key is the username chosen at registration and must be held server-side, never in a page a citizen loads.
Five stages, from a quiet registration to the moment the domain lands in your resolver, and what your teams do at each.
Something like benefits-payment-update.example.com is registered, often on a cheap or newly delegated top-level domain, with privacy protection and no content. Nothing resolves to a live page yet, so there is nothing for a blocklist to verify and nothing for your comms team to warn about. This is the stage where agencies wish they had visibility and mostly do not, which is why the honest answer is to plan for detection at the moment of activation rather than pretend to prevent registration.
Hosting is attached, an A record appears, and a copy of the real claim portal is served, usually scraped from the genuine site so the wording, crest and accessibility statement are all correct. The form collects a national insurance or social security number, a date of birth and bank details, then redirects to the real portal so the citizen sees nothing unusual. From this moment the domain is verifiable: it resolves, which is the precondition for entering the database at all.
Bulk messaging begins, frequently with a spoofed or lookalike sender identity and a shortened link, timed for a weekday morning. The first signal inside the agency is almost never a security alert; it is call volume. Contact centre agents start hearing the same sentence, the digital service manager notices unusual referral patterns to the real portal, and the fraud investigation lead opens a case. This is the stage where a batch lookup turns a hundred reported strings into a confirmed list in one request.
The domain arrives through curated threat-intelligence and OSINT sources and is resolved using fifty concurrent threads through rotating proxies with a ten second timeout. If it has an active A record it is retained, deduplicated, classified as phishing/malware and diffed against the previous day's set. In parallel your CERT analyst can push what your own teams confirmed, so agency-sourced observations and external feeds converge on the same domain rather than sitting in separate spreadsheets.
The database is rebuilt and the feed export runs at 04:30 UTC. Whatever consumes it, a protective DNS service, a firewall's domain object, a mail gateway's URL policy or a filtering appliance in a council's network, picks up the new entry on its next sync. Communications publishes the warning against the verified-domain list, the fraud team folds the confirmation into the case file with a timestamp, and when the domain eventually stops resolving it is pruned rather than left to inflate the list forever.
For a small authority, the deciding factor is not the feature list. It is whether the purchase needs a tender.
The uncomfortable arithmetic: a lookalike benefits domain costs an attacker less than lunch, while the control that would have blocked it often costs a small council eight months of business case, tender and legal review. Anything that collapses that gap is worth more to a municipality than any additional detection capability.
Pay-as-you-go credits change the shape of the decision. Credits are bought outright through PayPal, one credit equals one lookup, and they stay valid for twelve months, so a purchase can be made against a discretionary budget line and consumed at whatever rate the organisation actually needs. A Starter pack at $59 for 10,000 lookups is enough for a district council's contact-centre triage for a year. Growth at $99 for 25,000 or Professional at $249 for 100,000 covers a mid-sized agency doing gateway-level checking. Business at $499 for 250,000, Enterprise at $999 for 750,000, Enterprise Plus at $1,997 for 2,000,000 and Scale at $3,999 for 5,000,000 take a national department up to resolver-scale volumes. There is a 14-day refund policy on unused credits where under 10% has been consumed, which is the sort of clause a procurement officer reads before anything else. Full detail sits on the pricing page.
The daily threat feed subscription starts at $499 per month, with annual plans available, and that figure is deliberately worth stating in a public-sector context. In most jurisdictions it sits well below the threshold at which a competitive tender becomes mandatory, and comfortably inside the delegated authority of a head of IT or a departmental CISO. A ministry with a central procurement function will barely notice the difference between $499 and $4,999 a month; a town council with a shared IT manager covering three authorities notices enormously, because one figure can be signed off this week and the other cannot be signed off this financial year. The daily feed page covers the CSV and JSON formats and how the export is scheduled.
It also helps that there is very little to procure in the legal sense. No citizen data is transmitted, no message content is analysed, no software is installed on the estate and no agent runs on an endpoint, so the data protection impact assessment is short and the information asset owner's questions are answerable in a single meeting. A digital service manager can integrate the check into an existing form validation step in an afternoon; a network team can point a resolver at the CSV export without touching a procurement portal at all. Sibling sectors face the same shape of problem in different regulatory clothing, and the reasoning translates directly to healthcare, higher education and telecommunications.
None of these frameworks mandate a phishing domain feed. All of them are easier to satisfy with one.
The most consequential recent change for European public bodies is NIS2, which brings public administration entities into scope alongside energy, transport, health, digital infrastructure and postal services. Two features of it matter here. The first is incident reporting: a defined obligation to notify, on a defined timeline, which pushes agencies toward evidence they can produce quickly rather than reconstruct later. The second is management accountability, which moves cybersecurity from a technical concern to something a senior official personally answers for. Both make dated, machine-generated evidence far more valuable than a narrative account written after the fact. Member states implement the directive through national law, so the precise thresholds and timings that apply to a given body come from that transposition rather than from the directive text, and your legal team should confirm them.
Public bodies hold enormous quantities of citizen personal data, which puts GDPR squarely in scope. Article 32 requires security appropriate to the risk, and a daily-refreshed list of domains verified to be actively hosting credential-harvesting content is a straightforward, documentable technical measure against one of the most common routes to unauthorised access. Articles 33 and 34 govern breach notification, including the 72-hour clock to the supervisory authority. The practical value of a lookup service during those 72 hours is that it compresses triage: when a team is trying to establish whether a domain in a reported message was genuinely hostile, a sub-50ms answer with a last_checked timestamp removes hours of guesswork from the most time-pressured part of the process.
US federal civilian agencies operate under CISA guidance and binding operational directives, which set expectations for how agencies manage internet-facing risk and act on directed remediation. The relevant point for this product is integration rather than compliance claims: the feed is a plain CSV or JSON list of domains, so it drops into a protective DNS capability, an existing resolver or a firewall's domain policy without introducing a new platform to authorise. State, county and municipal bodies are generally outside federal directive scope but frequently choose to align, and the same integration path applies. Adjacent public-safety readers may find the law enforcement and military and defence pages useful.
Underneath the law sits the control catalogue that most public bodies actually map to in practice. NIST CSF gives the functional structure, and SP 800-53 provides the controls that an agency's system security plan is written against; both treat external threat intelligence, boundary protection and detection as named outcomes rather than optional extras. Many countries publish their own secure-by-design and public-sector security policy frameworks that serve the same purpose, with baseline expectations for government digital services and a requirement to document technical measures and their operational owners. These are frameworks and policy instruments, not statutes, and the honest framing is that a verified domain feed contributes evidence toward specific controls; it does not by itself satisfy any of them.
Finally there is an obligation unique to the public sector and easy to overlook: transparency and records. Freedom of information regimes and public records legislation mean that a decision to block a domain, or a failure to act on a reported one, may later have to be explained on the record to a journalist, an ombudsman, a public accounts committee or the citizen who lost the money. That makes an auditable, dated artefact disproportionately valuable. A retained daily CSV export, with the date it was produced and the domains it contained, answers the question of what the organisation knew and when it knew it in a way that no recollection or ticket comment can. Treat those exports as records from day one, retain them under your existing schedule, and the awkward request becomes a filing exercise.
If an internal auditor asked tomorrow, these are the things that should exist on paper.
The five that come up in almost every conversation with a government buyer.
A single check sends one thing over HTTPS: a domain name and your API key. No message content, no citizen identifier, no IP address of the person who received the message, no page contents. The service does not analyse email, does not render or sandbox pages and does not perform user-level tracking, so there is no personal data in the request to begin with. That usually makes the data protection impact assessment considerably shorter than teams expect.
If your policy nonetheless prohibits any query leaving the country, or if the sensitivity of the query itself is the concern because the domain name reveals which campaign you are investigating, take the feed instead of the API. The full database is downloadable as CSV or JSON, so all resolution happens inside your own infrastructure and nothing about a specific lookup ever leaves your network.
Yes, through the feed rather than the API. The daily feed subscription gives you the complete database as a CSV with domain,category,dns_status columns, or the same content as JSON. A single system with outbound access pulls the export after the 04:30 UTC rebuild, the file is transferred across your boundary using whatever process you already use for signature and intelligence updates, and the list is loaded into the resolver or filtering platform on the protected side.
This is the pattern that suits classified or otherwise segregated government networks, including GSI-style arrangements where internet-facing lookups from the protected segment are not permitted. The trade-off is that your protection is as current as your last transfer, so the transfer should be scheduled daily rather than left to a manual step someone remembers to do.
Only once it resolves. The database is built on DNS verification: a candidate domain is resolved through rotating proxies and retained only if it returns an active A record. A domain that was registered an hour ago and points at nothing is not yet in the database, and that is a design decision rather than a gap. Registration-age and WHOIS data are not part of this product, and it would be dishonest to imply otherwise.
In practice this aligns with the operational reality of the campaign lifecycle described above. A parked domain harms nobody; the risk starts at activation, and activation is precisely the event DNS verification detects. Domains that later stop resolving are pruned, which keeps the list defensible when a service owner challenges a block.
It solves a different half of the problem. A takedown service works the registrar and hosting relationships to have a hostile site removed, which can take days and sometimes fails entirely when the registrar is uncooperative or offshore. This is a domain-reputation lookup and threat feed: it tells you and your infrastructure that a domain is hostile so that clicks stop resolving to it now, regardless of whether the site is ever taken down.
Many agencies run both, and they complement each other. The feed protects people in the window between discovery and removal, which is the window in which most of the harm actually occurs. If you already have a takedown provider, this is the control that reduces the cost of their slowest cases.
It is one of the few controls that genuinely is. There is nothing to install, no agent, no appliance and no console anyone has to watch. The realistic minimum for a small authority is a credit pack and two integration points: the shared IT manager points the resolver or filtering appliance at the daily export, and whoever handles the contact-centre inbox gets a simple internal form that runs a batch check on reported domains.
The other half costs nothing at all. Publish a plain page listing your genuine domains, tell residents that anything else claiming to be the council is not, and route confirmed lookalikes to your national CERT. A three-person IT team can do all of this in a week. If you also cover schools, the K-12 education page covers the same approach for a school network, and the API docs have working examples for the integration itself.
Register for an API key and run your first batch of reported domains today, or take the daily feed and put a DNS-verified blocklist in front of every resolver your agency runs. No agent, no appliance, and no data about a citizen ever leaves your building.
