Your architecture review board has already decided where traffic may cross. This page is about the far smaller question of where a DNS-verified known-bad domain check goes inside that arrangement — which resolver, which mail hop, which one-way transfer, which outbound customer campaign — and what evidence each placement leaves behind for the next audit.
The sector argument for taking phishing seriously is made elsewhere. This is the plumbing.
If you are looking for the case that intrusions into operational technology usually begin in a corporate mailbox — the IT/OT boundary, the vendor remote-access problem and the regulatory frame laid out properly — that lives on our energy and utilities industry brief. It is the document to hand to a director or an audit committee. What follows here assumes that conversation is over and the answer was yes. You are a security engineer, a SOC lead, a network architect or the person who owns the mail gateway, and the question in front of you is narrower and considerably more annoying: where does a domain-reputation check physically sit in an estate that has been deliberately carved into zones, and how do you get a list into the parts of it that are not permitted to talk to the internet at all?
In an ordinary enterprise you bolt a lookup onto the mail gateway, point the recursive resolver at a response policy zone, and you are finished before lunch. A utility has at least three resolver populations that do not trust each other, a change-control process that treats any file entering the process network as a controlled item, a contractor population whose devices you do not manage, and a customer-facing brand being imitated on a completely separate front by people who have never been anywhere near your network. Each of those needs its own placement decision, and each leaves a different kind of evidence behind.
The Phishing Detection API answers one factual question about one hostname: is this domain, right now, on a list of phishing and malware destinations that were confirmed to resolve in DNS when the list was last rebuilt? It does not score novelty, it does not read page content, and it does not reason about intent. Every entry is resolved before publication and dropped when it stops resolving, so what you load is an inventory of live destinations rather than a growing museum of dead ones. That narrowness is why it survives a change board — it is a list of strings, it makes no outbound connections from the protected zone in feed form, and it installs no agent anywhere.
Nothing on this page will detect an attacker already inside the process network, and nothing here inspects a single industrial protocol. The value is entirely upstream: fewer credentials harvested means fewer intrusions that ever reach the stage where your OT-specific controls have to work. Treat the sections below as five separate small engineering tasks rather than as a security programme. Three of them can be done in an afternoon; the one that crosses into the demilitarised zone will take a change window and a signature, and that is exactly as it should be.
Each protects a different population, uses a different delivery mechanism, and produces a different artefact.
A generation business has comparatively few office users and a great many original-equipment-manufacturer relationships, so the mail path carries an unusual share of genuine supplier correspondence. Build placement one first, and pay particular attention to attachment URLs: turbine, inverter and balance-of-plant vendors send documents, not links.
Transmission and system-operation businesses have the most rigorous separation and the least tolerance for an outbound call from a controlled zone. Placement three — the file-fed resolver inside the demilitarised zone — is the one that will take a change window, so open that conversation early and run placements one and two while it is in the queue.
A distribution network operator's exposure is mobile: field engineers following links from vendor apps, mutual-aid crews with unfamiliar domains, and a contractor population whose devices you do not manage. The corporate response policy zone in placement two covers far more of that population than the mail gateway alone ever will.
A retail supplier carries everything the others carry plus a customer base being phished with its own billing brand. Placement four — screening outbound campaigns before dispatch — is the one nobody else needs and the one a retail business cannot afford to skip.
This is the highest-yield placement and the easiest to justify, because it is where the campaign actually lands. Extract every hostname from the message — the visible anchors, the raw URLs in the plain-text alternative, the destinations behind any link rewriting your gateway already applies, and the URLs embedded in attached PDFs and spreadsheets, which is where a growing share of credential lures now hide. Deduplicate the set, submit it to the batch endpoint in blocks of up to a hundred, and act on the verdict before the message is queued for delivery. Quarantine is usually the right action rather than a silent drop, because a utility's mail flow carries genuine operational traffic and the person who has to explain a missing outage notification would much rather have a release button.
Order matters here more than it looks. Run the domain check early, before the expensive content analysis, because a known-bad verdict is cheap and terminal. Cache verdicts for the current rebuild cycle: a campaign against a supplier typically reuses the same handful of domains across thousands of messages, so a mail flow of a hundred thousand messages a day rarely produces more than a few thousand distinct hostnames worth checking.
Invoice PDFs from maintenance contractors are the classic carrier. Parse the document, not just the message body.
A quarantined message released three days later should be re-checked against that morning's rebuild, not the verdict it got on arrival.
Store the domain, the verdict and the timestamp against the message ID. That triplet is the entire audit trail.
The mail gateway only sees mail. Staff also receive links over instant messaging, in ticketing systems, through contractor portals and on their phones while sitting on office Wi-Fi, and field crews follow links from vendor apps that never touch your mail estate at all. A response policy zone on the corporate recursive resolvers catches every one of those at name resolution, which is the last common chokepoint before any of them reaches the network. Pull the daily CSV, transform it into RPZ records, reload the zone, and point the answer at a sinkhole address you control rather than returning NXDOMAIN. A sinkhole that serves a plain explanatory page and logs the client address turns every block into an incident lead; NXDOMAIN just produces a confused user and no record.
Run the reload as an automated job on a fixed schedule and alert on failure rather than on success. The failure mode you are guarding against is not a bad entry — it is a job that quietly stopped running in March and left you enforcing a list from the spring. Compare the record count against the previous load and refuse to apply anything that has shrunk by more than a sane threshold.
An answer you control gives you the client address, the timestamp and the hostname. A negative answer gives you nothing at all.
Monitor the age of the loaded zone. A list that is six weeks old is far more dangerous than one that is obviously missing.
A local allow list that survives every reload lets a disputed entry be released in minutes without anyone editing the feed.
This is the placement that makes the utility case different, and it is the reason the CSV feed exists as a product separate from the API. Machines inside a controlled zone are not permitted to make arbitrary outbound calls to a third party, and no amount of enthusiasm about the control changes that. The pattern that survives review is a file one: a staging host in the corporate zone downloads the daily CSV, validates it, records its size and its changelog diff, and the file is then moved inward through whatever transfer mechanism your architecture already blesses — a data diode, a broker with a manual approval step, or a scheduled pull initiated from the inner side. The resolver serving the zone loads it locally and never speaks to anything outside.
Both are about reviewability rather than about the list itself. First, the diff is the reviewable object, not the list: a change record saying "1,900 domains added, 1,400 removed, full file hash recorded" is something an engineer can approve, whereas "download the internet's phishing list" is not. Second, be explicit about scope in the change request. This affects name resolution for hosts inside the zone that already use a resolver; it does not touch process traffic, it introduces no agent, and it rolls back by reloading the previous zone file. Reviewers approve changes they can reverse.
Downloads, validates and hashes the CSV on the corporate side. Nothing inside the zone ever initiates an internet connection.
The added and removed diff produced with each rebuild is what goes into the change record and what the auditor reads.
Stop at the zone's resolver. Pushing a blocklist onto engineering workstations or process hosts buys nothing and risks a great deal.
Daily transfer into a controlled zone is often unachievable, and pretending otherwise wastes everyone's time. Weekly is perfectly defensible for a segmented zone as long as the corporate side stays daily, because the population behind that boundary is small, tightly managed and rarely the one doing the clicking. Write the cadence down and hold to it rather than claiming a frequency the transfer process cannot sustain.
Every other placement protects people inside the business. This one protects the brand your customers are being phished with, and it is the placement most utilities have never considered. A retail supplier sends enormous volumes of legitimate transactional and marketing messages: bill-ready notifications, payment reminders, tariff-change notices, planned-interruption alerts, meter-appointment confirmations. Those messages carry links, and increasingly they carry shortened or campaign-tagged links that a customer has no way to verify by eye. If your campaign platform, an agency or a partner ever pushes a link to a domain that has since been flagged — an expired campaign microsite re-registered by somebody else is the classic case — your own channel becomes the delivery mechanism.
The fix is small and sits where the campaign is assembled. Collect the distinct destination domains for a campaign, post them to the batch endpoint, and refuse to send if anything comes back flagged. The arithmetic is comfortable: a campaign to two million customers usually contains a handful of distinct domains, so screening it costs a handful of credits rather than two million. Log the result per campaign and you have moved from "we believe our links are fine" to a dated record that every message dispatched was screened against a list rebuilt that morning.
Shortening services and campaign microsites change hands. Screen the domain you are actually sending, and re-screen anything reused from an older campaign.
Campaign identifier, domains checked, verdicts, timestamp. It fits on a single log line and answers the regulator's question directly.
The first four placements prevent. This one shortens the time an analyst spends deciding whether something matters. Wire the single-domain endpoint into the triage tooling behind your reporting button so a forwarded suspicious message arrives in the queue with the verdict already attached — the analyst opens a ticket reading "domain flagged, category phishing, resolving, last checked this morning" instead of one reading "user reported email". That change alone removes most of the manual lookup work from a phishing triage queue, and it removes the temptation for a tired analyst to visit the site to "just check".
On the detection side, join the daily feed against your DNS, proxy and web-gateway logs. Two questions become answerable that otherwise are not: which internal hosts resolved a domain that is on today's list, and — more valuable — which hosts resolved a domain in the last ninety days that has since been added. That second query is a retro-hunt, and it is how you find the compromise that happened before the domain was known to anyone. Our SIEM integration and DNS filtering pages cover the mechanics of both joins in more detail.
Verdict attached at intake. The analyst starts from a conclusion to confirm rather than a lookup to perform.
Today's additions against ninety days of resolver logs finds the click nobody reported at the time.
A monthly count of sinkholed resolutions is the single most useful board metric this control produces.
Attacks on your customers use your name, run on your billing calendar, and generate complaints to your contact centre.
There is a structural gap in most utilities that has nothing to do with technology. Security operations owns the corporate estate and the process network. Customer operations owns the contact centre, the billing platform and the outbound messaging. Nobody owns the space in between, which is where a customer receives a message that appears to come from you, on a domain you do not control, about a bill you genuinely issued. The fraud is not on your network, the victim is not your employee, and yet the complaint, the reputational damage and the regulator's question all land on you.
Overdue-balance and disconnection-threat messages dominate, because they borrow real urgency from a real relationship and arrive in the days after a billing run while a genuine bill is still fresh in the inbox. Prepayment and monthly subscription customers get a crueller variant: a cloned top-up page that takes a card payment and returns a fabricated code, leaving a household with no credit and no recourse. Government rebate and efficiency-grant schemes generate a fresh wave every time one is announced, because a customer cannot reasonably be expected to know whether a scheme is administered by the government, by their supplier, or by both. Smart-meter installation booking pages and tariff-switching sites round it out, harvesting the address, account number and bank details needed to take over an account outright.
All five are ordinary registered domains that resolve in DNS. That is precisely what the list is built to enumerate — and precisely why matching the daily added-domain changelog against your brand strings is worth the twenty lines of code it takes.
Pull the daily changelog of added domains and match it against your brand strings, your trading names, your common misspellings and the vocabulary that recurs in these lures — billing, arrears, refund, rebate, topup, meter, tariff. A hit gives you a dated observation of a live impersonating domain, which is the evidence a registrar or hosting abuse team wants before they will act, and it starts the clock on your own customer communications rather than waiting for the first complaint to arrive.
The second is the outbound gate described above, and the pairing is the point. Watching for domains that imitate you while your own campaigns go out unscreened is a half-finished job; screening your campaigns while ignoring the impersonation is the other half. Neither is expensive. Together they let a customer-operations director say something specific to a regulator instead of something reassuring. Adjacent patterns — invoice fraud aimed at procurement, payment-diversion attempts against accounts payable — are covered from the finance side on our payment processors and supply chain pages.
Utility phishing is not evenly distributed through the year, and neither is the population's willingness to click.
Almost every other sector has a flat threat calendar. A utility does not, because the emotional conditions that make a lure work are weather-driven and announcement-driven. The first hard cold snap of the winter produces a step change: consumption rises, the next bill genuinely will be larger, everyone knows it, and a message about an unexpectedly high balance stops sounding implausible. The same effect appears in the opposite direction during a sustained heatwave in a cooling-dominated region. Price-cap movements, tariff changes and the announcement of any government support scheme each produce their own spike, and all three are public information that attackers read at the same moment you do.
| Trigger | What changes for your customers | What changes inside the business |
|---|---|---|
| First hard cold snap | Consumption rises and the next bill genuinely will be larger, so a message about an unexpected balance stops sounding implausible. | Contact-centre volume rises at the same moment, which makes it harder to spot the reports that are about a cloned page rather than a real bill. |
| Sustained heatwave | The same effect in a cooling-dominated region: high usage, high bills, and a population primed to believe a payment demand. | Field and network teams are already stretched by demand management, so awareness messaging competes with operational traffic. |
| Price-cap or tariff change | Every customer expects a message about their tariff, and cannot easily tell yours from a copy of it. | Your own outbound volume spikes, which is exactly when an unscreened campaign domain does the most damage. |
| Government scheme announcement | Rebate and grant harvesting begins within days, because nobody knows whether a scheme is run by the government, the supplier, or both. | The abuse mailbox fills for a fortnight, and the triage queue needs staffing before the wave rather than during it. |
| Storm and major-outage response | Planned-interruption and restoration messaging is genuinely urgent, so customers act on it fast and check it less. | The whole organisation switches into a mode that rewards fast action on urgent instructions from people nobody has met. |
Mutual-aid crews arrive from other utilities with unfamiliar domains in their signatures. Contractors get onboarded in hours rather than weeks. Nobody is going to slow down and inspect a hostname during a restoration effort, and asking them to is the wrong instruction to give. This is exactly when an automated check earns its place: it runs identically at three in the morning during a storm and on a quiet Tuesday, and it does not get tired.
The practical use of all this is planning rather than prediction. None of it requires knowing anything about a specific campaign — it only requires accepting that the calendar is not flat.
The same DNS-verified inventory that stops a spoofed vendor portal reaching an engineer's mailbox also flags the cloned top-up page being sent to your prepayment customers. There is no separate product for the retail side and no separate subscription for the segmented zone — the API serves the interactive placements, the CSV feed serves the ones that cannot make outbound calls, and both are built from the same rebuild.
That matters organisationally more than it matters technically. It means the security team and the customer-operations team can be funded from one line, report against one cadence, and point at one changelog when somebody asks what changed. See the API reference for the endpoints and the daily feed for the export.
For a control entering a change-controlled environment, how the list is built matters more than how large it is.
Nothing here needs an SDK, an agent or a platform decision. It needs an HTTP client and a cron entry.
The interactive surface is two calls, plus a stats endpoint you can poll to prove the list is fresh. Both calls return the same object shape, so one response handler serves both.
The key goes in the query string or the POST body, and it must never leave your own infrastructure. A utility that puts the key into a customer-facing web page or a mobile app has published a credential anyone can spend, and the credits are yours. Proxy through your own backend, always.
curl "https://phishingdetectionapi.com/api/v1/check?domain=account-arrears-notice.example.net&apikey=YOUR_API_KEY"
{
"domain": "account-arrears-notice.example.net",
"is_phishing": true,
"category": "phishing",
"dns_status": "resolving",
"last_checked": "2026-07-27T04:31:07Z",
"confidence": 0.97,
"database_size": 390000
}curl -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{
"apikey": "YOUR_API_KEY",
"domains": [
"supplier-portal-login.example.com",
"meter-booking-confirm.example.org",
"grid-vendor-remote.example.net"
]
}'For the placements that cannot call out, the daily CSV feed is a separate subscription and the whole integration is a scheduled download, a checksum, a transform and a reload. Anything in the estate that reads a list of strings can consume it: BIND and Unbound response policy zones, firewall and proxy blocklists, SIEM indicator sets, offline analysis hosts. Because it is a plain file it crosses a one-way transfer without special handling, and it leaves the diff behind as your change evidence.
Credits are one per lookup and stay billed monthly, purchased by PayPal with no subscription and no per-seat licence on the API itself. A realistic utility profile is a few thousand distinct domains a day from mail after deduplication, a few hundred from triage and contact-centre lookups, and a trivial number from campaign screening. At the Professional package — Professional at $249/month for 100,000 lookups, $0.0025 each — that is comfortably a year of interactive use for a mid-sized supplier, with bulk enforcement handled by the feed rather than by per-query calls. If you are screening at genuinely high volume, Business at $499/month for 250,000 lookupsand Enterprise at Enterprise at $999/month for 750,000 lookupskeep the per-lookup cost falling; the full ladder is on the pricing page.
The mistake to avoid is paying per query for something a file can do — put bulk enforcement in the resolver, and spend credits where a human is waiting for an answer.
The evidence this control produces is only useful if you decide in advance what you are collecting and why.
For each placement, keep the dated version of the list that was in force, the changelog diff that produced it, and a count of enforcement events — messages quarantined, resolutions sinkholed, campaigns screened. Those three things together answer the only three questions an auditor, a regulator or an incident reviewer ever asks about a blocklist: what were you enforcing, when did it change, and did it do anything. A monthly rollup of blocked resolutions per site is also the most legible board metric available here, because it counts real events rather than estimating avoided ones.
Be equally deliberate about what you do not retain. A sinkhole log records that an internal address resolved a hostname; it does not need to record the full browsing session, and in a business with a customer-facing side that boundary matters. Set a retention period that matches your investigative need — ninety days is usually enough to support retro-hunting — and apply it. If you operate in a jurisdiction with a data-protection regime covering employee monitoring, get the retention decision agreed in writing before the first log is written rather than after somebody asks.
Incident handling gets simpler once the placements are in. A reported message whose domain is already flagged is a containment task, not an investigation: identify who else received it from the mail logs, check the resolver logs for anyone who resolved the domain before the block landed, force a credential reset for anyone who did, and close it. A reported message whose domain comes back clean is the interesting case and deserves the analyst's time — which is precisely the reallocation the enrichment placement exists to produce. Keep the two paths visibly separate in your runbook so nobody spends an hour on the first kind.
Review the allow-list overrides on a schedule. Every deployment accumulates them, each one was justified at the time, and none of them expire on their own. An override added during a storm response two winters ago is a permanent hole nobody remembers opening. A quarterly read-through of a file that should never run to more than a handful of lines takes ten minutes and is the highest-value hygiene task this control has.
Stated plainly, because a control deployed on the wrong expectations is worse than one that was never deployed.
The most important limitation is temporal. A domain registered an hour ago, used in a campaign this morning and abandoned by lunchtime may never appear on any list at all, including this one. The list is an inventory of what has been observed and verified, so by definition it trails the very newest infrastructure. What it catches is everything being reused — and reuse is the norm rather than the exception, because standing up genuinely fresh infrastructure for every wave costs the attacker money and effort. Treat the control as a floor that removes the bulk of the traffic, not as a ceiling that removes all of it.
It is blind to whole categories of attack that involve no bad domain. A business email compromise conducted from a genuinely compromised contractor mailbox — real domain, real sender, real thread, fraudulent bank details in the reply — passes every domain check ever written, because there is nothing wrong with the domain. So does an attack that abuses a legitimate file-sharing or document-signing service to host the credential page, since the hostname belongs to a service you have no intention of blocking. So does a telephone call. So does a QR code stuck on a car park payment machine, although our quishing page covers where the check does help in that case.
To repeat the point from the top of the page in its strongest form: none of this protects operational technology directly. It does not see DNP3, Modbus or IEC 61850. It does not know what an engineering workstation is doing, it cannot tell you whether a protection relay setting has changed, and it offers nothing against an attacker already inside the process network. Any vendor implying otherwise is describing a different product. The claim made here is narrow and, precisely because it is narrow, defensible: fewer harvested credentials means fewer intrusions that ever reach the point where your segmentation, your monitoring and your OT-specific controls have to hold.
The corollary is what to do with the rest of the budget. The blocklist is the cheapest layer, deployable in an afternoon, and it should be the first one built — but the first, not the only.
The objections a utility security team raises, answered without hedging.
Yes, but not in the way the question implies. Nothing here is deployed on the process network, and nothing should be. The relevance is that the corporate estate is where the campaign lands and where the credentials that eventually reach your boundary are harvested. Reducing the number of successful credential-harvesting attempts against corporate users, contractors and the people who hold jump-host access reduces the number of attackers who ever get close enough to test your segmentation.
That placement is fed by file rather than by outbound call precisely so that no host inside that zone talks to a third party. If your architecture will not permit even a file transfer inward, stop at the corporate boundary — you still get the majority of the value.
Describe what it actually is rather than what it protects against. It is a list of hostnames loaded into a resolver you already run, applied by a job you already have a pattern for, with a documented diff for every change and a rollback that consists of reloading the previous zone file. There is no agent, no kernel module, no new listening service and no new outbound path from inside the zone. Change boards reject things they cannot reverse and things whose blast radius is unclear; this has a small, well-understood blast radius and a one-command rollback.
The second thing that helps is arriving with the diff in hand. A reviewer who can see that yesterday's change added a specific number of domains and removed another specific number is being asked to approve a bounded, inspectable delta rather than a vendor's promise.
Have the answer built before you switch it on. Two things make this a non-event: a local allow-list file that survives every reload, so an override takes minutes and never involves editing the feed; and a sinkhole page that tells the user what happened and who to contact, rather than a browser error that generates a helpdesk ticket saying "internet broken". Decide in advance who may add an override, and record the reason next to each entry.
Because every published entry has been verified as actively resolving and is dropped once it stops, the list does not accumulate stale entries for long-dead domains that somebody legitimate later re-registers — which is where a large share of false positives on ageing blocklists come from.
At the mail path specifically it adds a second independent opinion cheap enough to run on every message — useful, but marginal if your gateway is good. The larger gain is everywhere your gateway does not reach. A mail gateway sees mail. It does not see the link a field engineer taps in a vendor app, the message a contractor sends over a chat platform, the campaign you dispatch to two million customers, or the domain your resolver is asked for by a device that never received an email at all. The four non-mail placements on this page are the reason to bother.
Gateway URL protection is a feature of a product you may one day replace; a domain feed loaded into your own resolver and your own SIEM is infrastructure you keep across a vendor change.
Partially, and the boundary is worth being precise about. The daily changelog of newly added domains can be matched against your brand strings, trading names, common misspellings and the vocabulary of energy lures, which gives you a dated observation of a live impersonating domain on the day it enters the list. That observation is exactly what a registrar or hosting abuse desk wants before acting.
What it is not is a full brand-monitoring service. It will not see a lookalike domain that has been registered but never used in a campaign anyone reported, and it does not watch certificate transparency logs or newly-registered-domain feeds. If protecting the brand is a formal programme with its own budget, this is a useful and nearly free input to it rather than a replacement for it; our brand protection page covers that distinction properly.
Far less than the message count suggests, because you are checking distinct hostnames rather than messages. Deduplicate within the message, then cache verdicts for the current rebuild cycle. Newsletters, internal systems, ticketing notifications and the same handful of contractor domains account for the overwhelming majority of links in a utility's mail flow, and each of those costs one credit per cycle rather than one per message.
Run a week of mail through a counter that logs distinct hostnames per day. Most teams are surprised by how small the number is, and it turns package sizing from a guess into an arithmetic problem. lookups reset each month, so buying a package that covers a year at your measured rate is straightforward.
Indirectly, and only on your side of the line. Fake login pages for remote-access portals, VPN concentrators and vendor-management systems are ordinary phishing domains, so when one appears in a message crossing your mail path or is resolved by a device on your corporate network, it is caught like anything else. What you cannot do is protect the vendor's own estate, and that is where much of this credential theft actually happens — a service engineer at an integrator is phished on their employer's laptop, and the credentials stolen are the ones that reach you.
The realistic response is contractual and architectural rather than technical: named accounts instead of shared ones, multi-factor authentication enforced on your side rather than trusted from theirs, time-bounded access rather than standing rights, and a reporting obligation when the vendor suffers a compromise. A blocklist is a useful layer inside that, not a substitute for it.
Two placements, one afternoon, and a dated changelog you can hand to the next audit. The feed handles the parts of the estate that are not allowed to call out.
