Every appeal a charity runs is a template that somebody else can copy, and the copy converts. This page is about wiring a DNS-verified list of currently-live phishing hosts into the four places a non-profit genuinely controls: the mail path, the resolver, the links it publishes, and the inbox where a finance volunteer approves a payment.
A charity does not get impersonated because it is careless. It gets impersonated because the whole relationship it has built with the public is one of unquestioning goodwill toward a request for money.
Almost every other sector spends its time teaching people to distrust unexpected requests for payment. A charity spends its existence teaching the opposite. Supporters are conditioned by years of legitimate contact to respond quickly and emotionally when an email says a crisis is unfolding and money is needed now. When a criminal borrows that voice, the supporter is not behaving recklessly by clicking; they are behaving precisely as the sector has asked them to behave for two decades. That is the uncomfortable thing to sit with, and it is why awareness messaging on its own never closes the gap.
The asset being stolen is rarely the organisation's own bank balance, which is why the loss is so easy to miss internally. A cloned giving page takes card details, a name and an email address, then either forwards nothing at all or issues a plausible receipt from a look-alike sending domain. The supporter believes they have given. The finance team never sees a transaction, because on their side of the wire there never was one. The two facts only meet months later, when someone rings to ask why their annual statement is missing a gift they are certain they made.
The reputational damage is entirely the organisation's to carry. A supporter does not describe the incident as "I was defrauded by a criminal impersonating a charity." They describe it as "I donated to that charity and my card was cloned." Every corrective conversation after that point costs more staff time than the original gift was worth, and a proportion of those supporters simply stop giving rather than argue about who was at fault. For a body whose income rests on a few thousand loyal regular givers, that quiet attrition is the real cost.
Non-profits hold data about the people they serve, not only the people who fund them: case notes from a refuge, immigration status in a resettlement programme, addresses of families in a food-aid scheme, health details from a hospice service. That information has no resale value on a card-fraud market, which is exactly why nobody counts it, and it has enormous value to anybody who wishes a specific beneficiary harm. Protecting the donor and protecting the beneficiary turn out to be the same technical job.
None of this is solved by a single control, and it would be dishonest to present a blocklist as though it were. What a verified list of live phishing hostnames does is remove the destination: when the clone's address is already known and resolving, the click produces nothing, the card details are never typed, and the sequence stops before anybody has to notice. It is a narrow intervention in the direction that matters, because it behaves identically for a fifty-year supporter, a new trustee, or a volunteer who started on Tuesday.
The threat has the same shape at every size, but the staffing, the systems and the realistic response do not. These four cases cover most of the sector.
Income arrives through one hosted giving page and a card reader at events. There is no IT function, the website sits on a builder platform, and the same login opens the mailbox, the supporter database and the donation dashboard. The realistic control is not a security product; it is a resolver that already refuses to look up the hostile hostname, plus a periodic sweep of the links the site publishes.
A foundation's exposure inverts the usual model. It publishes award decisions, corresponds with applicants nobody has met, and initiates payments to bank details supplied over email by organisations whose staff turn over constantly. The lure that works here is a grantee whose payment details have "changed", sent from a domain one character away from the real one, timed to arrive alongside the award letter.
Rescue groups, sports clubs, mutual aid networks and parent associations run on personal devices and handed-down credentials. Roles rotate at the AGM, the treasurer changes every couple of years, and the password lives in the back of a folder. Per-user policy and device management are fantasies here. Anything that works has to work at the network and the mailbox, without an administrator.
Country teams work over cellular routers, borrowed office links and satellite backhaul, in languages the head-office team does not read. Domain-level blocking is the one control that behaves identically regardless of what language the page is written in, which makes a distributable file far more practical than a product needing a console session per site.
Two distinct attacks live here. One clones the page a supporter gives on; the other steals the login to the portal where their history, their standing order and their address already sit.
Cloning a giving page is trivial, for structural rather than technical reasons. Donation pages are built to be shared, indexed, embedded in newsletters and linked from social posts, so their markup, imagery and copy are all public by design. Somebody saves the page, points the form at their own collector, registers a hostname that reads convincingly in a mail client, and buys enough placement to put it in front of people who were already intending to give. Nothing in that sequence requires access to your systems, which is why hardening your own hosting has no effect on it whatsoever.
Your organisation's name as a subdomain of an unrelated registered domain. Your name hyphenated with a word from the appeal — relief, emergency, fund, appeal, donate, support. Your name under a top-level domain you have never used, which works particularly well for charities whose real address sits on a country or sector suffix supporters cannot recite from memory. And plain typographic near-misses: a doubled letter, a swapped vowel, a hyphen inserted where the genuine domain has none.
Regular givers hold accounts storing a payment mandate, a gift history, a postal address and often a phone number, protected by a password chosen years ago and never changed. A page imitating your portal login harvests credentials that allow the bank details behind a standing order to be altered, a giving history to be downloaded for a far more convincing follow-up approach, or correspondence to be redirected. None of that trips a fraud alert, because the payment provider sees a legitimate account holder updating their own details.
Links in a newsletter draft, links pasted into a supporter's reply, links in a partner's co-branded appeal, links behind "Donate" buttons on old campaign pages — all of these go through the batch endpoint at up to a hundred domains per POST and one lookup each, called from a script on your own server. The response carries checked, phishing_found and credits_used. The API key is the username chosen at registration; it is a server-side secret and must never reach a supporter's browser.
This is a known-bad lookup and nothing more. A confirmed match returns a confidence of 0.98; everything else returns 0.0, with no scoring in between and no opinion about pages the database has never seen. A domain registered this morning and first used this afternoon will not be there yet. Put that sentence in the board paper rather than leaving somebody to discover it later: this is one layer that removes destinations already proven hostile, sitting alongside your mail filtering, your payment provider's own controls, and whatever verification habits your finance process enforces.
The gap between an emergency appeal launching and the first convincing copy of it is measured in hours, and every one of those hours is peak donor intent.
Emergency fundraising compresses every risk on this page into a few days. An appeal goes live because something terrible has happened; supporters give immediately and impulsively because immediacy is the entire point; and the organisation's own communications become urgent, high-volume and full of links, which is precisely the texture a fraudulent message needs in order to blend in. Nobody has to research your organisation to exploit that — plausible hostnames get registered the moment the event is in the news.
People giving to an emergency often have no prior relationship with the receiving organisation, so none of the familiarity signals that normally protect a regular donor are available — they cannot tell that a sender address is unusual, because they have never seen the usual one. Worse, legitimate coalition appeals genuinely do run on domains that differ from any single member charity's normal address, so "check the address matches the charity" produces a wrong answer for the honest case about as often as for the dishonest one.
The operational response is temporal rather than clever: during an active appeal, increase how often you fetch. Because the database is rebuilt every 24 hours with the daily build landing at 04:30 UTC, and because feed downloads are unlimited under a subscription, there is no marginal cost to fetching more often than strictly necessary. The shipped changelog of additions and removals is what keeps it cheap, since your reload applies a diff instead of reimporting the whole file.
This is also the moment to make a single hostname unambiguous in everything you publish. Choose one giving address, use it in every email, post and press line without variation, and resist the marketing instinct to spin up a memorable one-off domain for the campaign — that instinct is exactly what trains supporters to accept unfamiliar addresses from you. Where a coalition appeal requires a shared domain, name it explicitly and repeatedly rather than assuming supporters will recognise it.
The reason this fits an organisation with no security staff is that the maintenance burden sits with the database rather than with you.
Every entry carries an active A record, confirmed through rotating proxy infrastructure rather than accepted on report. That standard matters more to a charity than to almost anybody else, because a charity has nobody available to triage false positives. A list assembled from reports and never re-checked grows without limit, keeps hosts that went dark years ago, and eventually blocks something a supporter needs — at which point a two-person organisation has an angry phone call and no way to investigate it.
The response shape is deliberately unhelpful to anyone hoping for nuance, and for this audience that is the right trade. A confirmed match returns is_phishing true, a category of phishing/malware, a dns_status of resolves, a last_checked date and a confidence of 0.98. Everything else returns 0.0. There is no intermediate score for somebody to interpret, no risk threshold for a volunteer to tune, and therefore no configuration decision a non-technical trustee can get wrong.
For an organisation that checks in bursts — a link audit before a campaign launches, a sweep of the site after a redesign, a handful of hostnames pulled out of a suspicious message — the monthly plan fits better than any subscription, because a package stays billed monthly and the quiet months cost nothing. For an organisation whose exposure is a network or a fleet of field offices, the feed is the right shape instead: enforcement happens locally and no individual lookup is billed or transmitted anywhere.
The feed downloads as CSV with domain,category,dns_status, or as JSON. After that the comparison happens on your own equipment, so nothing about who visited what leaves the network.
The daily list of additions and removals lets a modest box apply a diff instead of reimporting the whole database, which is what allows a nightly job to survive on small hardware.
The /stats endpoint reports database size and last update with no API key, no credits and no authentication — which makes it a convenient monitoring check that the source is still current.
Fundraising fraud attracts the attention. The larger single losses in this sector come from a payment instruction that looked entirely routine.
Non-profit finance is unusually attackable for reasons that have nothing to do with technology. Approval frequently rests with a volunteer treasurer or an honorary officer who works remotely, reads email in the evening, and is deliberately kept at arm's length from daily operations so that the oversight is genuine. That separation is good governance and poor security: the person authorising the payment is the person least able to verify informally whether a request is real.
Organisations chase funding constantly, applications sit open for months, and portal notifications arrive from names nobody recognises on schedules nobody controls. A message saying an award decision is available, or that a compliance document is outstanding and the next tranche is on hold, is exactly the message a grants officer has been waiting for. The credentials harvested from its login page open the real portal — and from inside the real portal it becomes possible to read award correspondence, learn payment schedules and construct a request no outsider could have guessed.
A grant-maker paying out to dozens of small organisations receives bank-detail changes as routine business, because grantees genuinely do change banks, restructure, and lose the person who originally set the account up. Impersonating a grantee is far easier than impersonating a bank: register a near-miss of the grantee's domain, reply into an existing thread, and ask for the payment to go somewhere new. The foundation's internal controls are the last line, and time pressure at the end of a funding round is what breaks them.
Domain checking does not verify that a payment instruction is genuine — no blocklist can, and any process leaning on one for that purpose is badly designed. What it does is answer whether the hostname in the message is already confirmed live phishing infrastructure, converting a proportion of attempts into a hard stop rather than a judgement call. Run it at the gateway on inbound links, again before a bank change is actioned, and pair it with a callback rule nobody may waive: verification by voice to a number already on file.
The sector's staffing model breaks most security assumptions before an attacker turns up at all. A control that survives here has to keep working when everybody who set it up has left.
Churn is the defining operational fact. Programme funding is fixed-term, so contracts are fixed-term. Volunteers arrive for a season and leave. Trustees rotate on a governance cycle. The person who set up the mail domain was a contractor five years ago whose invoices are still in a filing cabinet. The practical consequence is not that people are untrained — it is that institutional memory keeps evaporating, so every account drifts toward being shared, because a shared account is the only thing that reliably survives a handover.
They break the entire identity-centred model of modern security. A compromise cannot be attributed to a person, so nobody feels responsible for it. It cannot be revoked without disrupting whoever else is mid-task, so revocation gets deferred. It produces no anomalous-login signal worth acting on, because the account has always been used from four devices in three places. And the advice to enrol everyone in multi-factor authentication runs into the fact that the second factor lives on somebody's phone, and that somebody is leaving in March.
A resolver that will not resolve a known-hostile hostname protects the account whose password lives in a folder exactly as well as the one behind a hardware key. It needs no enrolment, no training, no per-user configuration and — critically — no ongoing decision by anybody. When the treasurer changes, nothing about it needs revisiting. When a new volunteer plugs in a laptop, they are covered from the first DNS query without having been told anything at all.
It also removes a question small organisations answer badly: which of our people are high-risk? In a charity the person handling the most sensitive beneficiary records is frequently the lowest-paid caseworker, and the person whose click causes the largest financial loss is frequently unpaid. Trying to segment training and controls by role burns effort a two-person organisation does not have, whereas blocking a destination applies uniformly and asks nobody to self-assess.
Keep a written record of where the pull runs, what it reloads, and who to contact when it stops. A silently stale list is by far the most realistic failure mode here, and it is not caused by an attacker — it is caused by a laptop being wiped, a scheduled job on a machine nobody logs into any more, or a hosting account moving. One alert if the file is older than forty-eight hours closes that gap for the price of a monitoring check.
Six steps, each reversible, none of which requires a project plan, a consultant, or a budget line approved before anything can be tested.
Take the last dozen suspicious messages your team reported, extract the hostnames, and run them through the documented check endpoint. Confirm the database is current first via /stats, which needs no key, no credits and no authentication. Twenty minutes of this tells you more than any vendor claim will.
Export every outbound hostname from the website, the newsletter templates and the "useful resources" pages nobody has opened since 2019. Run them in batches of a hundred. Lapsed domains that somebody else has re-registered are the most common real finding, and they are sitting under your logo.
With hosted mail, a small server-side function that extracts links from inbound messages and flags matches is usually an afternoon's work. Flag first and quarantine later — a fortnight of logging without blocking gives you a hit rate from your own traffic and removes any risk of intercepting a funder's message on day one.
For most organisations that is a single router or a small resolver on the office network; in a serviced office it may be a conversation with the building's provider instead. The daily feed ships as CSV or JSON, and the import is a file replacement plus a reload, scheduled shortly after the 04:30 UTC build.
A default "access denied" screen produces a phone call to an office that cannot answer it. Say what happened instead: this address was verified as a fake page, nothing typed on it was sent anywhere, and here is the one giving address the organisation actually uses. That turns a dead end into a correction.
One page in the shared drive: where the job runs, what it downloads, what reloads, who holds the account, and the single alert that fires when the file goes stale. In a sector with this much turnover the handover note is the control — everything else is configuration that will outlive the people who understood it.
Two spending shapes, one of which is small enough to sit inside an existing administrative line without a procurement conversation.
The credit route suits an organisation whose usage is occasional and bounded: an annual link audit, checks on hostnames pulled out of reported messages, validation of a partner's campaign links before a co-branded appeal goes out. The feed route is what protects a network rather than an audit trail. Almost every organisation in this sector should be able to say in one sentence which of the two it is buying, and why.
Credits are monthly subscriptions via PayPal and remain billed monthly, with unused credits expiring at that point. The Growth package gives 10,000 lookups at $0.0040 per lookup; $99 Growth gives 25,000 at $0.0040; $249 Professional gives 100,000 at $0.0025 with priority support. A small charity doing periodic sweeps frequently finds the smallest package covers well over a year. A fourteen-day refund applies where under ten percent has been used, and above $4,000 bank transfer is available in place of card payment.
The Daily Threat Feed is $499 per month or $499/month and adding historical archive access, priority support, custom format options, a dedicated account manager and 100,000 API credits. Downloads are unlimited, so cost does not move with offices, staff or supporters. For a single small charity $499 a month is a real number; for a federation, diocese, national body with branches or consortium of members, one subscription distributed to members is the arrangement that makes the arithmetic sensible.
The framing that lands is not fear. It is that the organisation now holds a documented, dated technical control against a specific and well-evidenced risk to supporters and beneficiaries, at a cost small relative to a single lapsed regular gift. Funders increasingly ask about this in due diligence, and "we screen inbound links and published links against a DNS-verified list of live phishing hosts, refreshed daily, and here is the log" is considerably better than the answer most applicants manage — provided you record the limitation in the same breath.
Each check yields a dated result carrying last_checked and an explicit confidence value; each daily pull yields a file with a timestamp and a changelog of exactly what moved. Those two artefacts, retained on your own systems, are what an auditor or grant assessor actually asks to see, and neither requires a security platform to generate. Organisations formalising this alongside staff induction will find the security awareness page useful for the human half.
Including the ones without a comfortable answer, which are the ones worth reading first.
Partly, and the split matters. The audit work — checking your published links, checking hostnames out of suspicious messages — is genuinely achievable by anybody comfortable running a small script, and many organisations have a volunteer or a pro bono supplier who will set it up in an afternoon. The network deployment is different: it needs someone who can schedule a download and reload a resolver, and if nobody in your organisation can do that, the realistic path is a federation, diocese, umbrella body or managed provider who holds the subscription and runs the pull on your behalf. Pretending a two-person charity will maintain its own blocklist infrastructure would be setting you up to have a stale file and believe you were protected.
Not directly, and this is the most important limitation to understand: blocking works on the network where the block is applied, so if a supporter opens a cloned giving page on their own phone, at home, on their own broadband, nothing you have deployed in your office is involved. What the database gives you in that scenario is verification and evidence — you can check candidate hostnames and confirm which are already confirmed live phishing infrastructure, which is what a registrar or hosting provider wants before acting on a takedown, and what you want before warning your supporter base. The block protects your staff and volunteers; the verification supports your response for everybody else.
No, and do not describe it that way on a grant report. Training addresses judgement — verifying a payment change by phone, noticing that a request is out of pattern, knowing who to tell. This addresses destinations already proven hostile. The two fail in different places: training degrades as staff turn over, and a blocklist cannot see a domain nobody has observed yet. A funder asking about cyber practice generally wants to hear that you have both, plus a payment-verification rule nobody is allowed to waive under time pressure.
Plan for it and it becomes routine rather than a crisis. Keep a local allow-list that your reload script applies after each import, so an override is not wiped by the next update. Make the block page name the organisation and offer a way to reach a person quickly, because somebody halfway through an urgent application should not conclude the charity has locked them out. Verification through an active DNS check keeps the false-positive rate low, but no list is perfect, and the speed of your correction path matters more than the error rate itself.
Almost not at all any more, and it is worth actively retiring that line from your own materials, because a certificate is instant and costless for any domain, so a fraudulent page carries the same padlock a genuine one does. The advice that still holds is narrower and is about hostnames: publish one address, repeat it everywhere without variation, and ask supporters to type it rather than follow a link when they intend to give. Unglamorous, but it stays true, and it aligns with the technical control described here — because the whole attack depends on a supporter accepting an unfamiliar hostname.
Yes, and that is the practical case for the feed rather than per-lookup API calls in a distributed organisation. You download the database once — CSV with domain,category,dns_status, or JSON — and distribute the file to each site's resolver or firewall as configuration. Matching then happens locally at every location, so a country office on a poor satellite link is not depending on reaching an external service at the exact moment somebody clicks. Feed downloads are unlimited under a subscription, so adding sites does not change what you pay.
The database is rebuilt every 24 hours with the daily 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 — which is why the active figure sits above 390,000 rather than climbing indefinitely, since hosts that stop resolving fall out instead of accumulating. The gap you should assume exists is at the front end: a hostname registered and used inside the same hour has not been observed yet, and no list of this kind will contain it. That is a limitation of the entire category rather than a shortcoming of one product, and it is exactly why this belongs alongside other layers instead of replacing them.
Not on the monthly plan, which is precisely why it suits seasonal organisations. Credits are a one-off purchase, billed monthly, and consumed only when a call is actually made — a quiet quarter costs nothing at all. An organisation running two appeals a year plus an annual link audit can sit on a single Starter or Growth package and never touch a monthly commitment. The subscription only becomes the better answer when you want continuous network-level enforcement rather than periodic checking, which is a different decision with a different justification.
Start with a monthly plan sized to an annual link audit, or take the daily feed if the priority is network-wide enforcement across offices and field sites. Either way the deployment is a scheduled job and a handover note, not a security programme.
