A practical guide for the people who run central IT and information security at a university: how to get a DNS-verified list of currently-live phishing domains enforced across a network that includes departments you do not control, devices you did not buy, and halls of residence full of hardware that arrived last week. Written around the resolver, the change calendar and your own domain's reputation.
Where a blocklist lands when the estate has a dozen resolvers and three of them belong to faculties.
Why the academic year sets both the attack rhythm and your change windows, and how to plan around both.
Lookalikes, forgotten subdomains and what a compromised student mailbox does to your deliverability.
What this control genuinely does not catch, and what a year of it costs a university that counts everything.
Central IT rarely has the authority to standardise a campus. It almost always has the ability to answer a DNS query.
Apply the standard checklist to a research university and you cover the professional-services staff, some of the academic staff, a fraction of the postgraduates, and essentially none of the students.
Almost all of them ask a resolver you operate, because that is what the DHCP lease told them to do and because almost nobody changes it. That single fact is the one real point of purchase a central team still has.
The practical mechanics are unglamorous. You subscribe to the daily feed, pull the CSV on a schedule, transform it into whatever your resolver speaks — a response-policy zone, a sinkhole zone file, a firewall object group — validate the file before it replaces the live one, and reload. Every entry in that file has been verified as currently resolving in DNS, so you are not asking your resolvers to hold hundreds of thousands of dead names in memory for no reason. The changelog of additions and removals lets you apply a diff rather than a wholesale replace, which is what keeps your local exceptions intact and gives you something specific to write in the change record.
Nearly every large institution has at least one faculty, one research institute or one hospital-affiliated group operating its own DNS for historical reasons that were excellent at the time. You will not win an argument to consolidate them, and you should not spend political capital trying. Offer them the file instead. A departmental sysadmin who is handed a validated zone file, a one-line cron entry and a note saying the list is rebuilt daily and pruned of dead entries will usually take it, because it costs them nothing and makes their own life easier. Adoption by usefulness works considerably better than adoption by policy in an environment where policy is advisory.
Residential networks deserve their own decision. Halls of residence carry the widest device mix on campus and the least security oversight, and they are also where the tuition-fee and accommodation-payment lures land hardest. Applying the same resolver policy there is straightforward and high value. The caveat you should state out loud rather than bury is encrypted DNS: a student device configured to use DNS-over-HTTPS to an external provider bypasses your resolver entirely. You can block the well-known resolver endpoints if your institution's culture permits it, but most do not, and the honest framing is that you get very good coverage of the default path and no coverage of the deliberately reconfigured minority.
Any blocklist can be loaded. These are the properties that decide whether it is still working, and still trusted, two years later.
Ask what the qualifying condition for staying in the list is. Here it is active DNS resolution: a domain that stops answering drops out of the next build rather than sitting in the file forever.
A daily changelog of added and removed domains is what makes an incremental reload possible. Without it you are doing a full replace every morning and silently discarding every local exception you added.
A per-query cloud lookup means a third party accumulates a record of what your users resolve. In an institution with an information-rights office and a student union, that is a conversation you do not want to be having.
Anything that needs software on the endpoint has already excluded most of your population. Enforcement has to work identically for a managed staff laptop, an unmanaged research workstation and a first-year's phone on eduroam.
The first false positive will arrive during term, out of hours, on a service a research group depends on. If the only route to an exception is a central ticket queue, the group will simply switch their resolver and you have lost them permanently.
Per-seat security pricing is punitive for an institution whose population is mostly students. Network enforcement should cost the same for a specialist college of two thousand and a civic university of forty thousand.
Campaign volume against a university is not evenly distributed. It clusters on the same eight or nine dates every year, and those dates are published.
Very little else in security is this predictable. A university publishes, months in advance, exactly when its students will be anxious about money, exactly when they will be expecting unfamiliar administrative email, and exactly when a message about an account problem will be plausible rather than absurd. Enrolment week, the fee-payment deadline, the maintenance-loan or financial-aid disbursement date, the start of each semester, the exam and results windows, graduation, and the grant application deadlines that dominate the academic side. An attacker with a copy of your academic calendar has a targeting plan, and your academic calendar is on your website.
A new student has no prior for what institutional email looks like, no relationship with the service desk, and a legitimate flood of genuinely unfamiliar messages about registration, accommodation, library accounts, IT credentials and fee instalments. A phishing message asking them to confirm their account details is not an anomaly against that background — it is indistinguishable from it. Awareness training does not help, because the module is scheduled for week four and the campaign is aimed at week one.
A different failure, because the target is not naive — they are stressed. A student uncertain whether their maintenance payment has cleared, or whether their instalment plan is set up correctly, will click a link about it and type whatever the page asks for, because the alternative — being deregistered, losing accommodation — is worse than the small risk they are half-aware of. The lure does not need to be clever. It needs to arrive within a few days of a date you announced.
Grant deadlines, journal submission windows, conference calls for papers and reporting dates drive a stream of pretexts aimed at faculty: a funder portal that needs re-authentication before a submission closes, a peer-review invitation routed through a lookalike editorial system, a co-author document share, a request to reconfirm bank details for an award disbursement.
Results windows, graduation and clearing keep the pressure on into the summer, and they reach an audience that includes offer-holders and recent leavers. Faculty pretexts land on people who genuinely do receive that kind of message from unfamiliar domains, and whose institutional credentials frequently also open research data stores and computing accounts — lower volume than the student-facing waves, considerably higher consequence.
Two operational conclusions follow, and they point in opposite directions. The first is that your defensive coverage must be strongest exactly when your change freeze is tightest. Nobody sane pushes a resolver change during enrolment week, which means the enforcement has to be running, proven and boring by August. Plan the rollout backwards from that date: monitor mode over the summer, enforcement switched on with weeks to spare, exception process exercised at least once before the students arrive. The second is that the calendar gives you a cheap targeting plan of your own — schedule your lookalike-domain sweeps to run in the fortnight before each known pressure date, because that is when the registrations are happening.
A security team that turns up in June saying "we would like to load a blocklist" gets a queue position. The same team saying "we want this proven and stable before week one because that is when the fee-payment phishing lands, and here is what we saw last September" gets a decision. Our security awareness page covers using the same daily data to keep training material current rather than recycling screenshots from three years ago.
Four numbers that describe the file, and the rule that decides what is allowed to be in it.
The response to a single lookup is deliberately unambiguous: the domain queried, a boolean verdict, a category, the DNS status, the date the entry was last checked, a confidence value and the current database size. There is no gradient of suspicion for an analyst to interpret and no score for two people to disagree about at handover. That matters in an institution where the person triaging a reported message at four in the afternoon may be a placement student on the service desk rather than a security engineer, and where a clear yes or no is the difference between a resolved ticket and an escalation.
Because enforcement runs off a locally held file, no record of what any student or member of staff resolved is transmitted to us or to anyone else. The only outbound traffic in the enforcement path is your scheduled, authenticated download of the list, and that download reveals nothing about your network's activity. That is an architectural property rather than a contractual promise, which is a considerably stronger thing to put in front of a governance committee.
Half of this problem is inbound. The other half is what happens when your institution's name is the thing being imitated, or the thing doing the sending.
Universities carry a domain that means something. It sits on degree certificates, on funding applications, in the from-address of every offer letter, and in the trust assumptions of every alumnus who has not thought about the institution in fifteen years. That accumulated credibility is precisely what makes it worth imitating, and the imitation does not have to be sophisticated to work. A hyphenated variant, a different top-level domain, a subdomain of something else entirely with your institution's name in the leftmost label — any of these is sufficient when the recipient is an applicant awaiting a decision or a donor responding to an appeal.
The population reached through your brand is, awkwardly, the population sitting furthest outside anything you operate.
None of these people are inside your perimeter, so none of them are protected by anything you enforce at the resolver. What you can do is find the lookalike early, which is a detection problem rather than an enforcement one.
That is what the batch endpoint is for. Generate the plausible permutations of your institutional domain and your high-value service hostnames — the student information system, the virtual learning environment, webmail, the fee-payment portal, the accommodation system — and run them in blocks of a hundred on a schedule. Anything that comes back flagged and resolving is a dated finding you can hand to legal for a registrar complaint, to communications for a banner on the genuine service, and to the admissions or development team so the people they are writing to are warned before the fraudulent message arrives rather than after.
It is not primarily a data-loss event. Mail from a genuine institutional address passes SPF, DKIM and DMARC because it genuinely is your institution sending it, which means the next wave of phishing is authenticated, trusted, and often aimed at other institutions you collaborate with. The consequence lands on your domain's reputation: deliverability degrades for everyone, receiving providers start deprioritising your mail, and the first symptom is usually a registry office reporting that offer letters are landing in junk folders during clearing.
Blocking the credential-harvesting page stops the compromise that produces the sending platform. It is not the only control — mandatory phishing-resistant authentication for staff, sending-rate limits on student accounts, and an automated disable-and-reset path all matter — but it is the one that costs a fraction of a cent per lookup and requires no change to how anyone works. Our brand protection and email security pages go deeper into the monitoring and message-layer halves respectively.
Decentralised web publishing leaves universities with an unusually long tail of subdomains: project sites from finished grants, conference microsites, a survey tool a department pointed a CNAME at and then stopped paying for. A dangling record whose target has been released is a gift to anyone who wants a page that genuinely lives under your domain. Export your zone, extract the hostnames, and run them through the batch endpoint alongside a check that every CNAME target still belongs to you.
One scheduled download for enforcement, one endpoint for the service desk, one batch job for monitoring. That is the whole surface.
The enforcement path does not use the API at all. You subscribe to the daily feed, which delivers the complete database as CSV along with the added and removed changelog, and you transform it into whatever format your resolvers consume. Nothing about that path is billed per lookup, nothing leaves your network at query time, and an outage between your campus and us degrades nothing except the freshness of the file. Set one alert if the local copy is more than 48 hours old — a silently stale list is the only realistic way this deployment fails — and poll the database-stats endpoint, which consumes no credits, as an independent confirmation that the build is still moving.
A single GET against the check endpoint, wrapped in whatever internal tool your first-line staff already use, turns "is this link safe?" into a two-second answer rather than a forwarded email and a wait. This is the highest-value thing you can hand a help desk during enrolment, because the volume of reported messages in that fortnight is the highest it will be all year and the staff triaging them are frequently the least experienced they will be all year.
curl "https://phishingdetectionapi.com/api/v1/check?domain=student-portal-verify.example.net&apikey=YOUR_KEY"
{
"domain": "student-portal-verify.example.net",
"is_phishing": true,
"category": "phishing",
"dns_status": "resolves",
"last_checked": "2026-07-27",
"confidence": 0.98,
"database_size": 391284
}The monitoring job uses POST /api/v1/batch, which accepts a JSON body with your key and up to 100 domains and charges one credit per domain. Two schedules are worth running. A fortnightly sweep of permutations around your institutional domain and your named services, weighted to run before each pressure date on the academic calendar. And a termly audit of your own zone — every subdomain you publish, every CNAME target, plus the external hostnames embedded in your virtual learning environment, your library proxy configuration and the reading lists that departments maintain by hand.
curl -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{
"apikey": "YOUR_KEY",
"domains": [
"student-finance-portal.example.net",
"vle-login-secure.example.org",
"accommodation-payment.example.com"
]
}'On budget: credits are one per lookup, billed monthly, paid through PayPal, with no subscription and no per-seat licence on the API itself. For most institutions the discrete-lookup work is modest — the $99 Growth package is 25,000 lookups at $0.0040 each, which covers a year of service-desk checks and fortnightly sweeps for a mid-sized university comfortably. A large civic or research institution running per-faculty tooling on top usually sits at Professional (Professional at $249/month for 100,000 lookups). The full ladder up to the largest volume tiers is on the pricing page, and the delivery formats for the feed are on the daily feed page.
A known-bad lookup is a floor. Presenting it as anything more is the fastest way to lose the trust of the people you need on side.
Start with the timing gap. A domain registered this morning, stood up at lunchtime and mailed to twelve thousand students at two o'clock may not be in a build yet. Verification and inclusion take time, and any vendor claiming otherwise is describing a product that does not exist. What the daily rebuild cycle buys you is that the window is measured against a list that is actively pruned and refreshed rather than one assembled from historical reports, but the window is real and you should size your expectations around it.
This control operates on hostnames, and three common shapes fall outside that.
There is also traffic it never sees. A student on cellular data. A device using encrypted DNS to an external resolver. A researcher on a home connection with a personal machine and no VPN. A departmental network with its own upstream resolver that has not adopted the file. In each case the control is simply not in the path, and the correct response is to know the size of that population rather than to assume it away. Most institutions find the uncovered fraction is smaller than they feared and larger than they would like.
It removes a large, already-catalogued population of destinations from every path that does pass through your resolvers, at a cost that does not scale with the number of people you enrol, without an agent, without an endpoint policy, and without asking a single user to make a judgement they are not equipped to make. That is a genuine improvement to a baseline, and framing it that way — a floor rather than a solution — is what makes the rest of your security programme easier to argue for rather than harder. Phishing-resistant authentication for staff and privileged accounts remains the highest-value single investment; this sits underneath it and catches a different class of thing.
The eight objections below come up in almost every conversation with a university, and each deserves a direct answer.
Partially, and how partially depends entirely on how much of your traffic goes through resolvers you operate. In most institutions that is the large majority, because the central recursive resolvers serve the wired network, eduroam and the residential scopes even when a few departments run their own. Start there and you have meaningful coverage before any negotiation.
For the departmental resolvers, distribute rather than mandate. Hand the faculty admin a validated zone file or firewall object list, a cron entry and a short note explaining that the data is rebuilt daily and pruned of dead entries. Adoption in a federated institution follows usefulness, not policy, and a change that costs a department nothing is a change most departments will accept.
Some will, and you should say so before anyone else does. A device configured for DNS-over-HTTPS to a public provider bypasses your resolver entirely, and while blocking the well-known endpoints is technically possible, most universities will not accept the collateral or the optics. The honest claim is coverage of the default path, which is what the overwhelming majority of devices use because nobody changed it.
It is also worth noting who bypasses. The students most likely to reconfigure DNS are the ones most likely to spot a phishing page anyway. The population this control protects best — first-years in week one, international students dealing with fee instalments, alumni on the guest network at a reunion — is the population least likely to have changed a single network setting on the device in their hand.
Have the answer ready before you enforce, because the first false positive will arrive at an inconvenient hour on something a research group depends on. Three things need to exist on the day you switch enforcement on.
DNS verification keeps the error rate low — a domain has to be observed as active phishing infrastructure and confirmed to be resolving to enter a build — but the correction path matters more than the error rate in an environment where an annoyed department can simply point their machines somewhere else. A same-day override with a named owner buys you far more goodwill than a marginally lower false-positive claim.
Not in the enforcement path. With the feed you download the complete database on a schedule and match locally on your own resolvers, so no record of what any student or member of staff looked up is transmitted to us or to any third party. The only outbound traffic is your authenticated pull of the list, which discloses nothing about your network's activity.
The check endpoint is the exception, and a small one. That individual call does send the single hostname you asked about — which is appropriate for a service-desk agent verifying a reported link, and is exactly why user-facing traffic should run on the feed rather than the API. Being able to describe that split precisely is usually what a data-protection officer actually wants from the meeting.
If you already run a recursive resolver, yes — this is a scheduled download, a file transform, a validity check and a reload, which is genuinely an afternoon's work for whoever maintains that box. The ongoing cost is one cron job and one staleness alert, and there is no console to watch and no daily triage queue attached to it.
If you do not run your own resolver, look at whether your regional network provider, consortium or shared-services arrangement can hold the subscription and serve the list, in the same way such bodies already handle shared licensing and connectivity. That is the natural shape for smaller institutions, and it means the colleges with the least technical capacity get the same protection as the ones with a network team.
It is a technical control that reduces the likelihood of credential compromise, which is the usual precursor to unauthorised access to student records. It is not a compliance product and nothing here certifies you against any regime. Presenting it honestly as one documented safeguard among several will serve you far better than presenting it as a compliance answer. What it does give you is evidence with dates on it.
If your institution has to describe what it does to protect student and research data, "we block verified active phishing infrastructure at the resolver, refreshed daily, and here is the operating record" is a considerably better sentence than a policy statement.
Not by enforcement — they are not on your network, they are reading mail on personal devices, and no resolver you operate is in that path. Anyone who tells you otherwise is selling something. What you can do is detect the lookalike early, using scheduled batch sweeps of permutations around your institutional domain and your named services.
That detection is what admissions, development and communications actually need. A dated finding that a lookalike is live and resolving supports a registrar complaint, a hosting abuse report, a warning banner on the genuine service and a proactive message to the affected list — days before the first applicant reports losing a deposit.
Enough to make the decision on your own evidence. Take the hostnames out of six months of reported-phish tickets and run them through the check endpoint — that tells you the hit rate on traffic your institution actually saw, rather than a number from a brochure. The database-stats endpoint consumes no credits at all, so you can confirm the current size and last-update timestamp before you have decided anything.
Then run the feed in monitor mode: load it, log matches, block nothing, and let it sit across a full month of term. You will discover any overlap with a service your departments genuinely use before it becomes an incident, and you will walk into the change board with a count from your own resolvers. In a university, an internally generated number is worth more than any external claim.
Delivery formats, the sector-level argument for your executive board, and the adjacent problems that share the same dataset.
The delivery side: the complete database as CSV, the added and removed changelog, and the formats that suit resolvers, firewalls and SIEM ingestion.
Feed optionsFull parameters for the check and batch endpoints, the response fields, the stats endpoint and the rules on where a key may and may not live.
Read the docsThe sector-level version for an executive audience: why universities are targeted, how the campaigns land on students, academics and professional services differently.
Read the briefThe schools version of the same enforcement problem, where the device estate is more uniform and the filtering conversation is a different shape entirely.
Schools viewDirect-deposit redirection against staff self-service portals — the pretext that costs universities real money and rarely gets discovered before pay day.
HR patternsBackground material on how domains are verified, what the categories mean, and how the daily rebuild and changelog fit together operationally.
Browse articlesTest the list against the hostnames in your own reported-phish tickets, run the feed in monitor mode over the quiet weeks, and switch enforcement on with time to spare. The academic calendar decides your deadline; everything else here is a cron job and a reload.
