A school district controls every layer a phishing link has to travel through: the managed Chromebook, the enrolled organisational unit, the resolver the buildings use, and the identity provider sitting behind every gradebook. This page is about getting a daily list of DNS-verified, currently-live phishing domains into those layers when the entire technology department is two people, and one of them also maintains the projector carts.
Districts have more control over their endpoints than almost any comparable organisation. That control is why a blocklist deploys quickly here — and why a single stolen password travels so far.
Walk into a district technology office and the estate is unusually legible. There is a fleet of managed Chromebooks, enrolled to the domain and sorted into organisational units that mirror the buildings and grade bands. There is a directory — Google Workspace for Education, Microsoft 365 Education, or in a surprising number of districts both, with one federated into the other because a state assessment vendor insisted on it years ago. There is a filtering appliance or a cloud filter with policy tied to those same organisational units, because E-Rate discounts required a technology protection measure and the district has been renewing it ever since. Compared with a company of the same headcount, everything is enrolled, everything is enumerable, and nothing is anybody's personal laptop.
The gradebook trusts the directory. So do the learning management system, the library circulation module, the special-education case management tool, the bus routing dashboard, the substitute booking service and the professional-development registration site — usually through a SAML or OIDC assertion nobody has re-examined since it was configured. A stolen district password is not an email account; it is the key to a portfolio the district assembled deliberately, for good pedagogical reasons.
Every Chromebook renders the same fake sign-in page at the same resolution, with the same browser and the same extension set. Every staff mailbox sits on the same tenant with the same banner rules and allow-lists. A lure crafted against one district's environment works unchanged next door, which is why campaigns aimed at schools arrive in regional waves rather than as isolated incidents. The buildings differ; the software estate does not.
If you control the resolver, the enrolled browser policy and the mail flow, the cheapest useful move is making hostile destinations unreachable — rather than teaching nine hundred adults and four thousand children to spot a convincing copy of a page they see forty times a week. A known-bad list is no substitute for judgement, but it keeps working when judgement is exhausted, and in a school building judgement is exhausted by about ten past nine.
A district is not one user population. It is at least four, with different devices, different training, different authority and wildly different consequences when a password moves.
Holds super-admin on the tenant, the device console and the filter. Receives vendor renewal mail, console alert mail and help-desk mail all day, which is precisely the shape a credential lure imitates. A compromise here is not an incident; it is a change of ownership.
Approves purchase orders, signs off substitute pay, answers guardian mail and forwards attachments constantly. Impersonating this role gives an attacker authority over the people who move money — and impersonating the superintendent gives authority over this role.
Signs into six or seven platforms before lunch and has been conditioned by the job to accept sign-in prompts without friction. Holds gradebook write access, special-education documentation and a roster of minors, none of which is recoverable once copied.
On a personal device, outside every control the district owns, receiving mail that genuinely does come from school about fees, forms and lunch balances. You cannot filter their inbox — but you can find out when your own name is being used to reach them.
Reading those four together explains why single-channel defences underperform in schools. Mail filtering protects the first three and does nothing at all for the fourth, because guardians read district communications on personal accounts you have never had access to. Device policy protects students and, on a good day, teachers, but the technology director's compromise usually arrives on a phone during a conference. Awareness training is the only control that reaches everyone, and it is also the one with the shortest half-life — a session in August is a distant memory by the time the enrolment window opens in spring.
Three campaign shapes account for most of what a district sees, and each one exploits a workflow the district itself created for entirely sensible reasons.
Three campaign shapes recur in district after district, and none of them is technically interesting. Each one works because it borrows a workflow the district built on purpose — a daily sign-in, an annual payroll task, a routine request that families pay for something.
The SIS is the most consequential login in the building and the least glamorous: enrolment records, home addresses, custody arrangements, meal-benefit status, health notes, discipline history, immunisations, and the identifiers that follow a child through their entire education. Fake sign-in pages for the common platforms are cheap to build because the real ones are public, plain enough to imitate, and reached daily from a bookmark rather than by typing a URL. Such a page does not have to be good — it has to arrive at 7:50 on a Monday.
Grade modification is a recurring motive, and the people attempting it are technically capable teenagers who share a network, a device image and frequently a classroom with their target. They send teachers links to fake gradebook logins, they register look-alike domains for the district's own portal, and they are patient in a way external actors are not. That the resulting site is amateur does not help you: a domain registered by a sixteen-year-old resolves exactly like one registered by a criminal group.
The most expensive mail a district receives is short, polite and addressed to one person in business services, asking to update banking details ahead of payroll and appearing to come from a senior administrator. School business offices are visibly staffed by two or three people whose names and titles are published on the district website for perfectly proper accountability reasons, which makes the addressing trivial and the pretext plausible.
The second payroll variant is relentless in the first quarter because a complete set of employee tax documents is directly monetisable. The link usually points at a hosted document viewer or a sign-in page that harvests the credential first and delivers the pretext second, which is exactly where blocking the hostname breaks the chain while it is still cheap — the finance officer clicks, gets nothing, and reports it as broken rather than complying with it.
Cafeteria top-ups, athletics fees, field-trip payments, yearbook orders and band uniform deposits all involve the school directing families to a payment page, frequently run by a third-party vendor whose domain has nothing to do with the district. Families have been trained to accept precisely that. When a message says the lunch account is overdrawn and here is where to settle it, the amount is small enough to pay without thinking and the domain is unfamiliar enough to be unremarkable.
Guardian-facing fraud is where district hostnames get imitated hardest, usually as hyphenated variants or as a subdomain of something unrelated with the district's name buried inside. You will not catch all of them and should not claim otherwise, but you can check candidates deliberately instead of waiting for a family to report one — a hundred domains per POST at one lookup each, with checked, phishing_found and credits_used coming back so the job logs one line and stays quiet.
The verification standard is the whole argument. A blocklist that only grows is a file your filter parses forever without protecting anybody.
The database holds more than 390,000 phishing domains, and every entry has been confirmed to have an active A record through rotating proxy infrastructure. That verification is not a quality badge, it is the retention policy: a domain that stops resolving falls out of the list instead of accumulating in it. The practical effect for a district is that the file you import each morning describes hosts that are answering right now, so the size of your blocklist stays roughly proportional to the size of the actual problem rather than to the number of years you have been subscribed.
The build lands at 04:30 UTC — the middle of the night in North America and comfortably before the buses run. A daily changelog of domains added and removed ships alongside it, so an update can be a diff rather than a full reload if your filter is slow to restart.
One authenticated download replaces per-query lookups, and downloads are unlimited with a subscription, so a nervous first week of pulling hourly costs nothing extra. Nothing about a student's browsing leaves the district.
CSV as domain,category,dns_status, or JSON if you would rather transform it. Most district filters, firewalls and resolvers accept a custom blocklist file today, without a new appliance going into the rack.
The API answers in under 50ms at 10 requests per second per key. A /check costs one credit and returns is_phishing, a category of phishing/malware, dns_status of resolves and a last_checked date.
Confidence is 0.98 for a confirmed match and 0.0 for no match. A partial score would invite somebody to build a threshold, and a threshold is a discretionary decision this evidence does not support.
Local matching means an upstream outage costs you internet access, not protection. There is no verdict service to be unreachable in the middle of a state testing window, and /stats needs no key, credits or auth for a health check.
Nearly every district already runs a content filter for compliance reasons. Understanding precisely what it does not cover is the difference between a second product and a second layer.
If your district takes E-Rate discounts you operate a technology protection measure, and you have probably operated the same one for years. It classifies the web into categories, enforces safe search, applies different policy to elementary and secondary organisational units, and produces the reports that keep the annual certification straightforward. It does that job well. What it is not is a system designed around hostnames that exist for four days.
| Question | Category filtering | Verified phishing list |
|---|---|---|
| What is being judged | What a site is about, placed into a taxonomy | Whether one specific host is confirmed to be impersonating somebody |
| How a host qualifies | Crawled, reviewed, classified — a process built for pages that persist | An active A record verified through rotating proxy infrastructure |
| A host that lives four days | Usually gone before any crawler forms an opinion | Caught if observed and resolving; rebuilt every 24 hours |
| A pixel-perfect copy of a sign-in screen | Subject matter is "a login form" — nothing objectionable to classify | Carried as a verified fact about the hostname |
| Adult content, gambling, violence | This is precisely what it is built for | Out of scope entirely |
| Satisfies the E-Rate certification | Yes — it is the technology protection measure | No, and it must not be listed as one |
| How it deploys in your district | The appliance or cloud console you already administer | A custom blocklist file in that same tool |
A credential-harvesting host is registered in the morning, used for one campaign, and dark before any crawler has an opinion. When a category engine does catch one it is usually because the domain was reused or sat alongside something already classified — a genuine contribution, but an incidental one, and the gap it leaves is exactly the window in which the mail arrives.
A page that copies a Microsoft sign-in screen has the subject matter of a sign-in screen. It is not adult content, gambling or violence, and any honest taxonomy will describe it as a login form. The signal that matters — that this hostname is impersonating an identity provider to collect passwords — is not a category at all. It is a verified fact about a host.
Almost every district filter — on-premise appliance, cloud service pushing policy to enrolled Chromebooks, or a plain recursive resolver in a rack — accepts a custom blocklist. Loading a daily file into the tool you already own adds the layer without adding a console, a login, an agent on the device image, or a second dashboard for a team of two to check.
No project plan, no steering group, no new console. Six steps, each reversible, each finishable between a bell schedule and a help-desk queue.
The /stats endpoint needs no key, no credits and no authentication, so you can confirm database size and last update from a terminal in five seconds. Then take twenty hostnames you have personally seen in staff mail this year and run them through the documented check endpoint. Twenty answers about your own district beat any vendor demonstration.
For most districts that is the recursive resolver serving the buildings, the existing filter's custom blocklist, or the firewall that already holds one. Pick the one you can change without raising a ticket with a vendor. If your filter enforces per-device on enrolled Chromebooks, that is the better point, because it covers the fleet at home as well as on site.
Load the list, record matches, block nothing. A fortnight tells you the genuine hit rate on your own network, surfaces any collision with a curriculum resource before it becomes a teacher's complaint, and produces a number that came from your buildings rather than a brochure. That number is what a business manager funds; a vendor claim is not.
Default denial wording generates help-desk traffic you cannot absorb. Say what happened in plain language: this address was verified as a fake sign-in page, nothing you typed was sent anywhere, and here is the extension to call. Put the district's name on it. A block page that explains itself prevents a call; one that says "forbidden" guarantees one.
A cron entry after 04:30 UTC, a download of the current file, a sanity check on line count before it replaces the live copy, and a reload. Then the part everyone skips: one alert if the file is more than forty-eight hours old. A silently stale list is the only realistic way this deployment fails, and it fails invisibly.
Once the pull is scripted, add the quarterly jobs: hostnames extracted from the district site and every school site, the link list in your family communication platform, the bookmarks pushed to the Chromebook image, and typo variants of your own payment domains. Each is a batch call of up to a hundred domains, and each occasionally finds something that changed hands after somebody added it.
Districts think in per-student pricing because every other product they buy is priced that way. Neither option here is, which changes the arithmetic in your favour.
The credit route suits bounded, periodic work: quarterly audits of hostnames on district and school websites, checks on domains extracted from reported staff mail, verification of the payment vendors listed in your family portal, and sweeps of the typo variants around your own domain. Credits are monthly subscriptions via PayPal and stay billed monthly, with unused credits expiring at the end of that window, and there is a 14-day refund window if under ten percent has been used.
| Package | Price | Credits | Per lookup | Support |
|---|---|---|---|---|
| Starter | $59 | 10,000 | $0.0040 | |
| Growth | $99 | 25,000 | $0.0040 | |
| Professional | $249 | 100,000 | $0.0025 | Priority |
| Business | $499 | 250,000 | $0.0020 | Dedicated |
| Enterprise | $999 | 750,000 | $0.0013 | Account manager |
Network-wide enforcement means every lookup is answered locally and none of them is billed. The Daily Threat Feed is $499 per month — the annual option saves $1,989, a third off, and adds historical archive access, priority support, custom format options, a dedicated account manager and 100,000 API credits, which happens to cover the audit work above without a second purchase.
Downloads are unlimited, so the price does not move with your student count, your building count, or how many devices went home this year. A district of nine hundred students and a district of ninety thousand pay exactly the same, which is not how anything else in the technology budget behaves and is worth pointing out explicitly in the paperwork.
Educational service agencies, county offices, intermediate units, BOCES and state education networks already hold shared subscriptions for filtering, assessment platforms and bandwidth. One subscription at that level, served to member districts, is the same distribution problem they solve daily — and it puts identical protection into the rural district whose technology department is a teacher's free period.
Above $4,000, bank transfer is available in place of PayPal, which matters more than it should for public bodies with card restrictions. Larger requirements — SFTP or S3 delivery into a state pipeline, STIX/TAXII into a regional operations centre, custom update frequency, an SLA, on-premise deployment — are quoted rather than listed; see the pricing page and the daily feed page.
Including the objections that are genuinely awkward, answered as directly as they deserve.
Because "blocks phishing" is doing a lot of work in that sentence, and the honest test is specific. Ask your filter vendor how a hostname first seen at 06:00 becomes blocked by 09:00, and what evidence puts it there. Category engines are built to classify subject matter on sites that persist long enough to be reviewed, and a perfect copy of a sign-in page has no objectionable subject matter to classify. If your vendor's answer is convincing, you may genuinely not need this. If the answer is a reputation score with no stated verification standard, you now know where the gap is — and the other honest framing is that this is not a product you operate but a file, so if it turns out to be redundant with what you already run, you stop pulling it and nothing else in your estate changes.
Not if you deploy the feed, which is the pattern recommended for exactly this reason. You download the whole database once a day and load it into your own resolver, filter or firewall. Every comparison after that happens on district equipment, so no record of any student or staff lookup is transmitted anywhere. The only outbound traffic is your own authenticated download of the list, which says nothing about who used a device or what they searched for; if you use the /check or /batch endpoints instead, those calls do send the specific hostname you asked about, which is appropriate for auditing your own website's links or verifying a domain a teacher reported, and is precisely why student-facing traffic should go through the feed rather than through per-query lookups.
Plan for it and it is a two-minute problem instead of a crisis. Keep a local allow-list that your reload script reapplies after every daily import, so an override survives tomorrow's build. Put a real extension number on the block page rather than a generic denial, because a teacher who can reach a person in one call does not escalate to the principal. Verification by active DNS resolution keeps false positives low, but no list is perfect and the correction path matters more than the error rate — and if you run step three of the rollout above, you will usually discover any collision during the log-only fortnight, before it can interrupt anyone at all.
No, not on its own, and any vendor telling you otherwise is overselling. A guardian reading mail on a personal phone over a mobile network never touches district infrastructure, so nothing you deploy at your resolver reaches them. That is a real limit and you should say so when someone at a board meeting assumes otherwise, while noting the two things that are still available to you: guardians on the campus guest network are covered like everybody else, which matters more than it sounds during enrolment evenings and parent conferences, and you can check hostnames deliberately — typo variants of your own domain, the payment vendors you actually direct families to, and anything a parent forwards to the office — then warn your community about the confirmed ones through the channels you do own, because a verified answer on a specific hostname is a far better basis for a message home than a vague caution. The brand protection page describes how that watch list gets built.
The database is rebuilt every 24 hours with the build landing at 04:30 UTC, and every entry is DNS-verified through rotating proxy infrastructure so only hosts with an active A record are included. That is why entries fall out when they stop resolving rather than piling up over the years. A single response carries dns_status of resolves, a last_checked date, and a confidence of 0.98 for a confirmed match against 0.0 for no match — nothing in between, deliberately, because a middle value would invite a threshold the evidence does not support.
No, and please do not present it that way to a funder. Your technology protection measure addresses categories of visual content, and this list does not speak to that requirement at all. The two sit alongside each other: the category product satisfies the certification, and this handles a threat the certification was never written about. Do not list it on the certification paperwork as if it were a technology protection measure. It is a security control that happens to deploy through the same appliance.
If you already run your own resolver or administer your own filter's custom blocklist, yes — this is a scheduled download and a reload, genuinely an afternoon plus a staleness alert. If you administer neither, the honest answer is that you should probably not be the entity holding the subscription. Talk to your educational service agency, county office or state network about holding it centrally and serving it to member districts, exactly as they already distribute filtering and bandwidth. That is the right shape for a district with no capacity, and a much better use of your afternoon than building infrastructure you cannot maintain — so start by reading the API documentation and the feed options, then ask whether anyone else in your region has raised it, because usually somebody has.
Partially, and the boundary is worth stating plainly. A student who registers a look-alike domain this morning and sends it to a teacher this afternoon is inside the window where no list helps, because nobody has observed the host yet. What the list does catch is the far more common case where the student reuses infrastructure that already exists, buys a kit, or points at a host that has already been used against somebody else. It also catches them on the second attempt, which for a teenager working alone is usually where the campaign really is. The controls that matter more for this specific threat are directory-side — multi-factor on staff accounts, alerting on gradebook changes outside normal hours, and not letting one sign-in reach the SIS without a step-up — and the blocklist is a floor beneath those rather than a replacement for them.
Confirm the database size from the open statistics endpoint, run the feed in log-only mode for a fortnight, and take your own buildings' numbers to the business manager. If the Chromebook fleet and the guest network are the priority, the daily feed is the deployment that keeps every lookup inside the district.
