Electric, gas and water utilities, generators, grid operators and retail energy suppliers all run the same uncomfortable arrangement: a corporate IT estate full of email, sitting one carefully governed boundary away from the systems that keep the lights and the water on. The Phishing Detection API gives you a DNS-verified list of actively resolving phishing domains, rebuilt every 24 hours, so that a large share of the credential-harvesting attempts aimed at your engineers, contractors and customers never gets a click in the first place.
Intrusions into operational technology almost never start in operational technology. They start in a corporate mailbox and travel.
An invoice from a maintenance contractor, a password-expiry notice for the remote-access portal, a shared document about an outage plan, or a request to confirm a delivery window for a transformer.
An engineer, a contractor coordinator, a day-ahead scheduler or someone in procurement. They click, they type credentials into a page that looks like the one they use every week, and stage one is complete.
The harvested credential is tried against corporate webmail and the corporate VPN. From there the attacker reads file shares, finds network diagrams, and works out which team owns the jump hosts in the IT/OT demilitarised zone.
A jump host works exactly as designed: it lets a named human with a named account reach an engineering workstation. From there the reachable estate includes the SCADA supervisory layer, the energy or distribution management system, the historian, and the project files describing relay and controller configuration.
Ask an OT security manager where they expect an attack to begin and the honest answer is rarely “at a substation”. The pattern that recurs across publicly documented incidents in the sector is far more mundane, and the first stage of the intrusion completes before anyone has touched anything that could be described as industrial.
It is a boundary with a documented, business-critical set of holes in it. Historians replicate process data outward so trading, asset management and regulatory reporting can use it. Patch and antivirus servers pull updates inward. Time synchronisation crosses. Metering and billing data flows from the field into the customer information system. Every one of those flows exists because an operational requirement demanded it, each was approved, and each is a path an attacker with a corporate foothold will enumerate. The boundary does its job of forcing the attacker to work harder — it does not make the corporate mailbox irrelevant. It makes the corporate mailbox the thing that determines whether the attacker gets to start working at all.
The arrangement utilities are least able to change. Turbine and generator original-equipment manufacturers, protection-relay suppliers, advanced metering infrastructure head-end vendors, DMS integrators and control-system maintainers frequently hold standing remote-access rights under multi-year maintenance agreements. Those accounts are long-lived by design, because a fault at three in the morning is not the moment to start provisioning access. The credentials, however, live in the vendor's estate, on the vendor's laptops, in the vendor's mailboxes, protected by the vendor's security programme rather than yours. Phishing a regional service engineer at a mid-sized integrator is very often easier than phishing anyone inside the utility, and the resulting access lands closer to the process network than a generic corporate credential would.
Be precise about what a domain-reputation service can and cannot do against this. A lookup against a list of known phishing domains does not protect a substation. It does not see DNP3, Modbus or IEC 61850 traffic, it does not inspect the process network, it does not know what an engineering workstation is doing, and it cannot tell you whether a relay setting has been altered. Anyone who tells you otherwise is selling something.
What it does is operate on the corporate mail path and the corporate recursive resolver, where the campaign actually lands, and remove a substantial share of the initial-access attempts before a credential is ever typed. Lateral movement, privilege escalation and OT-specific tradecraft are all downstream of that first click. Reducing the number of first clicks reduces the number of intrusions that ever get as far as needing an OT-specific answer, and it does so with a control that costs almost nothing to operate and touches nothing inside the security perimeter.
Four features of how utilities actually work make the sector unusually reachable, and each of them has a specific answer.
Most phishing guidance assumes a nine-to-five office population with one named mailbox each and a culture that rewards scepticism. A utility satisfies almost none of those assumptions, and the mismatch shows up in four places.
The list does not change human behaviour, and it is not a training product. It changes what happens when the behaviour is exactly what you would expect it to be, at each of the four points above.
Your customers are being phished with your name, on your billing cycle, and the regulator will ask what you did about it.
The workhorse of energy-sector consumer fraud, effective because it borrows real urgency from a real relationship. Campaigns arrive in the days after a billing run, when a genuine bill is fresh in the inbox, and intensify during cold snaps and price changes when the fear of losing supply is highest. The text is short, the sum is small enough to be plausible, and the link goes to a page that reproduces your payment flow closely enough that a customer who has paid online before will not hesitate.
Prepayment customers are hit with cloned top-up sites that take a card payment and return a fabricated code, leaving the household with no credit and no recourse — often at the exact moment they can least absorb the loss. It is the version of this fraud with the sharpest human consequences and the lowest chance of the money being recovered.
Energy-rebate payments, insulation and heat-pump grants, hardship funds and price-cap adjustments are all announced publicly, described in plain language, and administered through a mixture of government portals and supplier systems that ordinary customers cannot be expected to distinguish. Attackers register domains combining a supplier-sounding string with words like rebate, refund, grant or scheme, stand up a page asking for bank details “so the payment can be made”, and buy a small amount of search or messaging distribution.
Fraudulent installation-booking pages harvest addresses and account numbers, and tariff-switching sites claim to move a customer to a cheaper rate while collecting everything needed to take over the account. Both piggyback on genuine national programmes that customers have been told to expect contact about.
For a regulated supplier the damage is not confined to the individual customer. Complaints arrive at your contact centre, not at the fraudster's. The sector regulator and the consumer bodies see a pattern of harm associated with your brand and ask what steps you took. Your own legitimate messages become less effective, because customers who have been burned once now distrust every email about their account, which drives call volumes up and digital self-service adoption down. The customer-operations director ends up owning a problem created entirely outside the business, and the only defensible position is a documented, dated mechanism for detecting the impersonating domains and for keeping your own outbound messaging clean.
That is where a domain lookup earns its keep on the retail side, and the integration is deliberately small. A single GET against /api/v1/check returns a verdict in under 50 milliseconds, which is fast enough to sit inline in a contact-centre tool, a fraud-triage queue, or the abuse-mailbox workflow where customers forward suspicious messages. Below is a check against a lookalike billing domain of the kind that shows up after a billing run.
curl "https://phishingdetectionapi.com/api/v1/check?domain=account-billing-arrears.example.com&apikey=YOUR_API_KEY"
{
"domain": "account-billing-arrears.example.com",
"is_phishing": true,
"category": "phishing/malware",
"dns_status": "resolves",
"last_checked": "2026-07-27T04:38:11Z",
"confidence": 0.98,
"database_size": 212370
}
The same mechanism runs in the other direction, before you send anything. Bulk customer SMS is where a supplier's outbound risk concentrates, because a short message with a shortened or campaign-specific link is indistinguishable in the recipient's hand from a fraudulent one. Extract the destination domains from a campaign, post them to /api/v1/batch in blocks of up to 100 with a JSON body of {"apikey": "...", "domains": [...]}, and read phishing_found before the dispatch job runs. The response also returns checked and credits_used, which is enough to file a per-campaign screening record. It is a small gate in a marketing pipeline, but it is the difference between "we believe our links were clean" and being able to show that every campaign was screened against a list rebuilt that morning. The full integration surface is documented on the API reference, and the same approach is described for adjacent sectors on our telecommunications and logistics and supply chain pages.
The mechanism matters more than any headline number, because a blocklist entering a change-controlled environment has to be defensible.
Every ingested domain is resolved through rotating proxies before it is published, and only domains with an active A record are retained. Domains that stop resolving are pruned rather than accumulated, so the list you load is a list of destinations that were live when it was built rather than a growing archive of dead entries. The pipeline runs ingest, DNS verification, deduplication and classification into phishing or malware, a diff against the previous day to produce a changelog, and then load into the API and export of the CSV feed. That changelog is what makes the daily list workable in a utility: a compliance lead can see what was added and what was removed, and can attach that diff to a change record. Details of the export and its subscription terms are on the daily feed page.
A utility answers to a reliability regime, a cyber directive, a sector regulator and a data-protection authority, and they ask different questions.
It owns wires, pipes, substations, pressure-reduction stations and treatment works, and it answers to a reliability and safety regime. Confusion in utility security programmes usually starts with treating this business and the retail business as one thing.
It owns customers, tariffs, billing and collections, and it answers to a consumer regulator and to data-protection law. The two frequently sit under the same holding company, share a brand and share an email domain — which is why one lookalike registration can serve a campaign against retail customers and a campaign against network engineers. The obligations they trigger are genuinely different, and a control that helps both needs to be described differently to each.
The CIP family addresses, among other things, the establishment of electronic security perimeters around identified cyber systems, the control and monitoring of electronic access into and out of those perimeters, and personnel and training requirements covering the people granted that access. Two points matter here, and both cut against overclaiming. CIP obligations attach to identified bulk electric system cyber systems and their associated assets, not to the entire corporate estate, so a corporate mail gateway is usually outside the perimeter CIP governs — and that is exactly where the attack begins. Improving the corporate mail path is not a CIP control in itself; it reduces the population of attackers who ever get close enough for your CIP controls to be tested, and it supports the awareness and training obligations by making the environment those trained people work in materially cleaner.
Entities in scope are expected to take appropriate and proportionate technical and organisational measures to manage the risks to their network and information systems, and to report significant incidents to their national authority within the timescales the directive sets. NIS2 also introduces accountability at management level for approving and overseeing those measures, which changes the conversation internally: a board that must sign off on risk management wants controls that produce evidence, not controls that produce reassurance. A daily blocklist with a dated changelog and a per-lookup record is unusually easy to report on for exactly that reason.
National energy regulators add a layer that varies by jurisdiction but rhymes everywhere: suppliers are generally expected to protect customers from harm arising from their commercial relationship, to communicate about billing and disconnection in ways that do not mislead, and increasingly to report on cyber resilience as part of periodic regulatory returns. Alongside that sits GDPR for any supplier holding EU customer data — Article 32 requires security appropriate to the risk, and Articles 33 and 34 govern notification, including the 72-hour window for notifying the supervisory authority. The customer information system and billing platform of a retail supplier hold names, addresses, meter identifiers, consumption profiles and payment details, and the most common route into them is a phished employee credential rather than an exotic exploit.
IEC 62443 and NIST SP 800-82 are both structured around defence in depth, the segmentation of an industrial environment into zones with controlled conduits between them, and the recognition that the boundary between enterprise and control networks is itself a zone requiring its own controls. A domain-reputation check maps onto that model at the enterprise side of the conduit and, via the offline CSV feed, onto the DMZ resolvers that sit inside it.
Now the plain statement, because a page like this is worthless without one. A domain lookup does not satisfy NERC CIP, it does not discharge a NIS2 obligation, it is not a GDPR Article 32 programme, and it certainly does not implement IEC 62443. It is a single technical control that contributes evidence to several of them and reduces the frequency of the event they are all ultimately concerned about. Use it as one line in a control register, not as a compliance claim.
Start where the mail lands, finish where the network will not let you make an outbound call.
The sequence below is ordered by how much protection each step buys per unit of effort, and by how much change control each one attracts. The first two live entirely in the corporate IT estate, need no OT involvement, and can usually be delivered inside a normal change window by the team that already runs the secure email gateway and the recursive resolvers. The third extends the same checks to the correspondence that comes from outside the organisation, which is where the contractor and vendor exposure sits. The fourth is owned by customer operations rather than security. Only the fifth touches anything the OT security manager has to sign, and by design it does not require the segregated network to reach the internet at all.
Nothing here asks you to re-architect the boundary, add an inline appliance in the process network, or change how the control room works. Every step is a list being consulted or a list being loaded. That is a deliberate constraint: a control that requires a new network path across the IT/OT boundary will spend a year in review, and a control that requires no new path can be running next month. If you already forward gateway and resolver telemetry to a SIEM, the blocked-lookup events fit into existing detection content with no new schema; the approach is described in more detail on the SIEM integration page.
Call /api/v1/check from a connector on the secure email gateway. Screen sender domains and embedded link domains at receipt, before the message reaches an engineer, a scheduler or a procurement inbox.
Build a response policy zone from the daily CSV on your recursive resolvers. It catches the click that the gateway missed, and covers laptops, VDI sessions and the admin subnets adjacent to the jump hosts.
Extend the same checks to the tenants and portals used by the contractor coordinator: outage contractors, OEM service engineers, metering installers and integrator staff who hold standing remote access.
Screen destination domains through /api/v1/batch, 100 at a time, before a bulk SMS or email run leaves the campaign platform. Log credits_used as the per-campaign screening record.
Pull the 04:30 UTC export once a day, hash it, take it through your one-way or scheduled transfer into the OT DMZ, and load it into the DMZ resolvers under normal change control.
The same data, delivered three different ways, because the three environments will not accept the same integration.
Vendors routinely sell a single product into a utility and then discover that they have in fact been asked to satisfy three separate procurement conversations. The corporate IT network behaves like any other enterprise: it has outbound internet access, it tolerates an API dependency, and its change process is measured in days. The segregated OT and DMZ networks behave nothing like that. Outbound internet access is usually prohibited by policy and often by physical arrangement, an external API dependency in a control path is close to unarguable, and a change is tested in a staging zone and approved by people whose primary concern is that nothing on the process network behaves unexpectedly during a switching operation. Customer messaging is a third case again, owned by a marketing or digital team, integrated into a campaign platform, and governed by a release process that has nothing to do with either of the first two.
Be honest about what that means for the segregated case, because pretending otherwise wastes everybody's time in the first technical review. In an OT or DMZ network there is no live API call. What you get is the daily CSV, exported at 04:30 UTC, pulled down on the corporate side, hashed, carried across on a scheduled or one-way transfer, and loaded as a static list into the DMZ resolvers or proxy denylists. That list is up to 24 hours old by the time it is loaded, and possibly older if your transfer window is weekly rather than daily. It is still worth having, because the domains it contains were confirmed to resolve when the list was built, but it is a different control with a different latency profile from the one running on the corporate side, and it should be written up that way in your control documentation.
The practical consequence is that the OT security manager, the NERC CIP compliance lead and the customer-operations director are buying three things from one subscription and should each be given their own integration note. The table below is the version we hand to a utility architecture review board. The columns are the three environments; the rows are the six questions that review board reliably asks. If it helps to see the same distinction drawn in a neighbouring sector, the manufacturing use case covers the equivalent plant-network split, and incident response covers what the resulting telemetry is worth once something has already happened.
| Decision factor | Corporate IT network | Segregated OT/DMZ network | Customer messaging |
|---|---|---|---|
| Enforcement point | Secure email gateway connector plus a response policy zone on the recursive resolvers | Static denylist loaded into DMZ resolvers or a proxy in the IT/OT demilitarised zone | Pre-send link screening inside the campaign or CPaaS pipeline |
| Network reachability | Outbound HTTPS to the API is permitted and already used by other security tooling | No outbound internet path by policy; nothing in this zone calls an external service | Outbound HTTPS from the messaging platform, server-side only, never from client code |
| Update mechanism | Live API calls against the current database, with the daily CSV as an optional bulk load | Daily CSV export at 04:30 UTC, carried in on a scheduled or one-way transfer | Batch endpoint, up to 100 domains per request, run per campaign |
| Latency tolerance | Sub-50ms per lookup, fast enough to sit inline with message delivery | Not applicable; the list is loaded, not queried, and may be up to a day old | Seconds to minutes, ahead of the dispatch job rather than during it |
| Change-control burden | Standard IT change record, delivered by the existing mail and DNS teams | Full change control: staged, tested, approved, with the file hash and diff attached | Marketing or digital release process, with the screening step in the run book |
| Evidence produced | Per-message verdicts in the gateway log and blocked queries in resolver telemetry | Dated file hash, load record, and the daily changelog diff against the previous version | Per-campaign screening report showing checked, phishing_found and credits_used |
The database is rebuilt every 24 hours, and every domain in it has been resolved through rotating proxies using 50 concurrent threads with a 10 second timeout before publication. Only domains with an active A record survive that pass, and entries that stop resolving are removed rather than left to accumulate. That matters more in a utility than almost anywhere else: when a blocklist is being loaded into a change-controlled environment, every stale entry is a future false positive waiting to be raised as an incident by someone in the middle of a switching operation, and every unexplained addition is a question at the next change advisory board. A daily diff against the previous build tells your NERC CIP compliance lead exactly what changed and why the file they are approving is different from yesterday's.
Six questions that come up in almost every architecture review we sit in with an energy or water business.
Yes, and this is the normal pattern for anything sitting behind a data diode or a manual transfer process. You subscribe to the daily feed, pull the CSV from /api/v1/feed on a corporate-side host after the 04:30 UTC export completes, hash it, and move the file across using whatever transfer mechanism your OT policy permits. The columns are domain, category and dns_status, which is a simple enough structure to parse into a resolver zone file, a proxy denylist or a local sinkhole without writing anything exotic.
The trade-off is explicit: on the far side of the transfer there is no live lookup, so your list is as current as your last transfer. Utilities that move it daily are working with data under 24 hours old. Utilities constrained to a weekly transfer window should document that latency in their control description rather than describe the OT-side list as equivalent to the corporate-side check.
The usual approach is to separate the mechanism from the content. The change record covers the mechanism: a scheduled job that retrieves a signed-off file format from a named source, validates it, and loads it into a specific resolver or proxy. That change is raised, tested and approved once. The daily content updates then run under that standing approval, in the same way a signature update or a threat-intelligence feed does, rather than each day's list going to the change advisory board.
What makes that palatable to a reviewer is the changelog. Because the pipeline diffs each build against the previous one, you can attach a record of additions and removals to your operational log, so the file loaded on any given day is auditable after the fact. Several teams also stage the file for 24 hours before promoting it into the DMZ, which trades a day of freshness for a review window.
Run an allowlist, and put your counterparty domains in it before you enable enforcement. Any utility has a knowable set of contractor, OEM and integrator domains that correspond with it regularly, and the contractor coordinator or procurement team can usually produce that list from the supplier master. Your allowlist should be consulted before the blocklist at every enforcement point, so a named counterparty is never blocked regardless of what the feed says.
It is also worth understanding what would put a legitimate domain on the list in the first place. Entries come from curated threat-intelligence and OSINT feeds and are retained only if they resolve. The realistic false-positive scenario is not a mistake about a well-known contractor; it is a small supplier whose website was compromised and used to host a phishing page. In that case the block is correct while the compromise lasts, and the domain drops off once it stops serving that content and is no longer reported.
Not on its own, and we would rather say so than have your compliance lead discover it during an audit. CIP obligations attach to identified bulk electric system cyber systems and their associated assets. A domain check running on the corporate secure email gateway and the corporate recursive resolvers is generally operating outside the electronic security perimeter those standards govern, which means it is not the thing that demonstrates compliance with an electronic access control requirement.
What it does do is reduce the volume of credential-harvesting attempts aimed at the people who hold access into that perimeter, and it gives your awareness and training programme an enforced backstop rather than relying purely on human recognition. Where it becomes directly relevant to a CIP-scoped asset is the DMZ deployment in step five, and even there it should be described as one supporting technical control within a broader access-control and monitoring programme.
Fewer than most people assume, because you are checking domains rather than customers. A bulk SMS run to two million households typically carries one, two or three distinct destination domains, so screening it costs a handful of credits, not two million. The credit-consuming workloads are inbound: gateway checks on the distinct domains appearing in staff mail, and lookups from an abuse mailbox or a fraud-triage queue where each reported message generates one check. Caching a verdict for the rest of the day removes most of the repeat volume.
For high-volume resolver-side enforcement, the daily feed subscription is the right shape rather than per-lookup credits, because you are loading the whole list locally and answering queries yourself. Feed subscriptions start at $499 per month with annual plans available; credit packs run from Starter at $59 for 10,000 lookups up to Scale at $3,999 for 5,000,000, with credits valid for 12 months. Full detail is on the pricing page.
They address opposite ends of the same intrusion and do not overlap. An OT monitoring platform passively watches the process network, learns what normal industrial protocol traffic looks like between named assets, and alerts when something anomalous happens: an unexpected engineering connection, a configuration write to a relay, a new device on a segment. It is detection, and it operates after an adversary is already inside the environment it watches.
A DNS-verified blocklist operates before that, on the corporate mail path and the corporate resolvers, and it is prevention rather than detection. It removes a share of the initial-access attempts that would otherwise become the intrusion your OT monitoring eventually detects. Practically, the two also complement each other in the SOC: blocked-domain events from the gateway and resolver give an analyst investigating an OT alert a much faster answer to the question of how the intruder got in.
Register for an API key and check a handful of the lookalike domains your abuse mailbox has collected this month. If you need the whole list for resolver-side enforcement or for a transfer into a segregated network, the daily feed exports at 04:30 UTC every morning.
