Every subscriber query already crosses your resolvers. Adding a list of DNS-verified live phishing domains to that path protects an entire base at once — but only once you have settled consent, the block page, what you log, and whether it is a default or a tier. This page is about running that as a service, at carrier volume, using a feed rather than per-query lookups.
Every other layer of phishing defence has to be installed, configured or agreed to by somebody. Yours is already in the path.
Consider the household you actually serve. There is a laptop with whatever security software came pre-installed and expired eighteen months ago. There are two phones on different operating systems. There is a tablet a child uses, a television that browses, a doorbell, a games console, a printer, and a smart speaker that resolves domains nobody in the house has ever heard of. Not one of those devices is going to receive a security agent, and the person paying the bill is not going to configure anything. What every one of them does do, without exception and without being asked, is send a DNS query to the resolver your DHCP or your mobile core handed them.
A control that requires installation reaches the subscribers who are already careful. A control that sits in the resolution path reaches everybody: the elderly subscriber who has never opened a settings menu, the household where nobody is technical, the thirty-pound handset bought outright with no management on it at all. The correlation between "will install security software" and "needs security software" runs in exactly the wrong direction, and network-level enforcement is the only layer that ignores it.
A subscriber whose account portal credentials are harvested through a cloned billing page generates a call, a fraud investigation, possibly a port-out dispute and occasionally a regulatory complaint. Credentials taken from a fake bill-payment page are frequently reused against the subscriber's bank, and their mental model of that event is not "I was phished" but "something happened to my account with you". You will be told about it either way; the question is whether you take the call before or after the harm.
Any subscriber can adopt it in ninety seconds by changing one setting, and several well-known providers offer it at no cost, so the subscribers who care already have. The differentiator is therefore not the blocking itself — it is the blocking arriving by default, with a block page carrying your brand and your support number, integrated with the account the subscriber already has. Doing nothing does not keep them on your resolver; it means they leave it for somebody else's, taking the visibility with them.
Expectations on operators to take reasonable, proportionate measures against foreseeable harms to subscribers have been tightening in multiple jurisdictions, and "we carry the traffic and take no view" is a weaker position than it was a decade ago. This page does not interpret any specific instrument — the sector-level view sits on the telecommunications industry page — but a documented, daily-refreshed blocklist with a clear scope and a published block page is far easier to describe to a regulator than an intention.
There are only two ways to put a verdict into a DNS path. You can ask somebody else about every query, or you can hold the answers locally and never ask anybody. At carrier volume the second is the only one that works, and it is also the only one that keeps subscriber behaviour inside your own network.
A scheduled job pulls the current CSV of DNS-verified phishing domains once per build cycle. A converter turns it into whatever your resolver platform consumes — an RPZ zone for BIND, local-zone directives for Unbound, a blocklist for whichever commercial resolver you run. A validity check confirms the file parsed and is roughly the size you expected before it replaces the live copy. The resolver reloads. Every subsequent match happens in memory, on your hardware, in the time it takes to consult a hash table.
Because the comparison is local, the added latency is a rounding error against the query you were already answering, and there is no third-party service whose availability becomes your availability. An upstream outage degrades your internet connectivity, as it always did. It does not degrade your protection, because there is nothing to be unreachable. That property matters more at carrier scale than anywhere else, since a resolver dependency that fails at nine in the morning is an outage with a press release attached.
That is a configuration-management problem rather than a networking one. The same file lands on every point of presence, pushed by whatever you already use to manage resolver config, so a subscriber in one region gets the same answer as a subscriber in another. Add one alert — the local copy is older than forty-eight hours — because a silently stale list is the only realistic way this deployment fails, and it fails quietly. The general pattern is covered further on the DNS filtering page.
DNS enforcement catches the click. Screening the message catches it earlier, and messaging volumes are bounded in a way DNS volumes are not.
SMS is a uniquely effective delivery channel for phishing and the reasons are all structural rather than technical. The message arrives in the same thread as legitimate service notifications, so it inherits their credibility. The rendering surface is a phone, where the address bar truncates and the full hostname is often invisible until deliberately expanded. Link shorteners are normal in SMS rather than suspicious, because the medium has a character limit. And the recipient is walking somewhere, one-handed, not sitting at a desk with time to think.
You carry the message, and you are also the brand most frequently impersonated in it — bill overdue, service suspension, a small refund waiting, a delivery that failed. The last of those is the most reliably productive lure in circulation, and it is aimed at the same subscribers who are least equipped to evaluate it. Where you can intervene depends entirely on which traffic you control.
For A2P entering through your own aggregator or messaging platform you are the sender's carrier, so you can screen before delivery: extract the hostnames from message bodies, expand shortener targets where your platform can, and check them in batches of up to a hundred at one credit per domain. A match is grounds to hold the message and to look hard at the sending account, which frequently turns out to be a compromised or fraudulently-obtained sender identity rather than an isolated message. The related patterns are covered on the messaging platforms page.
Here the calculus is different and the honest answer is more cautious. Inspecting the content of subscriber-to-subscriber messages is a serious step with legal, contractual and reputational weight that varies enormously by jurisdiction, and it is not a decision an engineering team should make on its own. Many operators quite reasonably decline. Where that is the position, the DNS layer still catches the click even though the message was delivered — a weaker intervention than blocking the message, but a materially better outcome than nothing.
It is also frequently underused: give subscribers a way to report a suspicious message, check the extracted hostname, and act on the result. A single reported message, checked in milliseconds and confirmed as pointing at live phishing infrastructure, justifies adding the host to your resolver blocklist immediately rather than waiting for the next build — which protects every other subscriber on the network from the same campaign within minutes.
# Up to 100 hostnames per request, one credit per domain checked
curl -s -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{"apikey":"YOUR_KEY",
"domains":["billing-refund-notice.example",
"parcel-redelivery-fee.example",
"links.legitimate-brand.example"]}'
# A single reported message, checked from the care desk
curl -s "https://phishingdetectionapi.com/api/v1/check?domain=account-suspend-notice.example&apikey=YOUR_KEY"
# {"domain":"account-suspend-notice.example","is_phishing":true,"category":"phishing",
# "dns_status":"resolves","last_checked":"2026-07-27","confidence":0.98,
# "database_size":390000}Work the numbers honestly and the conclusion is immediate: the feed is the deployment, and the API is for the edges.
A subscriber base of any size generates DNS query volumes measured in billions per day. Set that against the monthly plan — one lookup per API call, with the largest published package at Enterprise at $999/month for 750,000 lookups per lookup — and the mismatch is not marginal, it is several orders of magnitude. A single mid-sized operator would exhaust the largest package before breakfast. Any vendor proposing per-query lookups for resolver enforcement at carrier scale either has not done this arithmetic or is not expecting you to.
It delivers the complete database as CSV on its own subscription, together with the daily added and removed changelog, and the cost does not move with your query volume, your subscriber count, your number of points of presence or how busy the network is on a Friday evening. One subscription serves an entire estate. That is the only pricing shape that makes sense for infrastructure, and it is also the shape that keeps subscriber queries local, since there is nothing to ask.
They suit exactly the workloads that are bounded, event-driven and human-scale. A care agent checking a hostname a subscriber has reported. A batch pass over the links in a queued A2P campaign. A periodic sweep of the hostnames in your own outbound subscriber correspondence. A brand-monitoring script checking candidate look-alikes of your own portal domains. All of those are thousands of lookups per month, not billions, and lookups reset each month so a quiet quarter costs nothing.
The product decision here determines the coverage, and coverage is the only variable that changes the outcome for subscribers.
Three models exist and they are not equally effective. Opt-in produces the lowest coverage and the least benefit, because the subscribers who go and enable a security feature are the subscribers least likely to fall for a cloned billing page. It is the safest position politically and the weakest one operationally, and it is worth naming that trade-off explicitly rather than pretending the models are equivalent.
It is a defensible position when three conditions hold — and under those conditions the subscriber has not lost any capability they would have chosen, while the small minority who want an unfiltered resolver can have one.
Charging for phishing blocking positions a control that costs you effectively nothing per subscriber as a premium, invites an obvious question about why the base package is knowingly left exposed, and reads badly in exactly the regulatory conversation you least want to have. The workable version is to make phishing blocking the default for everybody and to sell the things around it: household-level policy, per-device controls, category filtering, reporting dashboards, business-grade logging and custom allow-lists. Those are genuinely optional; the phishing floor should not be.
The architecture is what makes that argument true rather than merely reassuring. Because you hold the whole list locally, no subscriber query is transmitted to any third party — not sampled, not aggregated, not sent for a verdict. The only outbound traffic is your own authenticated download of the list once per build, which reveals nothing about any subscriber. That is a structural claim rather than a contractual one, and it is worth writing into your privacy notice in those words, because subscribers and regulators both treat "the vendor promises not to keep it" very differently from "the vendor never receives it".
It deserves its own deliberation. A count of blocks per hour is operationally useful and carries no personal data. A record of which subscriber line resolved which phishing hostname, retained indefinitely, is a subject-access request and a disclosure obligation waiting to happen. The defensible middle is aggregate counting by default, short retention on any per-line record, and a documented reason for every field you keep. The most common regret in this space is not blocking too much; it is logging too much.
It is the only part of this a subscriber ever sees, and it is the difference between a reassured customer and a support call.
Most block pages are written by whoever configured the sinkhole, and they read like it. "Access denied by network policy" is technically accurate, tells the subscriber nothing they can use, and reliably generates a call to a contact centre where the agent has no visibility of what happened either. At the scale of a national subscriber base, a badly worded interstitial is a measurable cost line, and the fix is a copywriting exercise rather than an engineering one.
This address has been verified as a fake site designed to steal passwords or payment details, and your provider blocked it before it loaded.
Nothing has been taken: the block happened before any information could be sent. That is the reassurance the anxious subscriber actually needs, and almost no interstitial gives it.
If they were trying to reach their bank or their account with you, they should use the app or a saved bookmark rather than a link from a message.
A real route to report a mistake, and — where your policy allows — a documented way to proceed at their own risk.
The page must be branded as yours, because an unbranded interstitial looks exactly like the sort of interception subscribers have been taught to distrust, and it wastes the goodwill the block just earned. And it must be reachable — served over HTTPS with a certificate for the sinkhole hostname, otherwise a meaningful share of subscribers see a browser certificate warning instead of your carefully written explanation, which converts a protective event into a frightening one.
This is where operators diverge, and it is worth being conservative. A monthly summary in the account portal — "we blocked twelve attempts to reach known fake sites on your line" — is proportionate, demonstrates value for something the subscriber may not otherwise notice, and gives your retention team something concrete to talk about. Per-event push notifications to a mobile app are almost always a mistake: they alarm people about something that has already been handled, and they train subscribers to dismiss security messages from you, which is the last habit you want to build.
When a subscriber calls about a blocked page, the agent should be able to check the hostname and read back a plain answer — confirmed phishing, category, when it was last verified — rather than escalating to a network team. That single check is one credit, it resolves the call in the first contact, and it turns the block from an unexplained interruption into a visible piece of service delivery.
The same list can protect brands you do not own. It still will not protect anybody from a domain registered an hour ago.
Host operators sit in an unusually good position here. If you provide the core and the resolvers for a set of MVNOs, the protection you deploy applies to their subscribers automatically, and you can offer it as a wholesale feature with per-brand configuration rather than as a per-brand build. Each MVNO gets its own block page — its logo, its support number, its wording — pointed at a sinkhole address you operate, while the underlying list, the daily refresh and the operational monitoring are shared. That is a genuinely attractive proposition for a small brand with no network engineering function at all, and it costs the host almost nothing incremental because the list was already loaded.
The feed subscription is held by whoever operates the resolvers, and the cost is amortised across every brand served by them rather than duplicated. Where an MVNO wants its own care-desk checking or its own campaign screening, credits are the natural instrument because those workloads are bounded and attributable per brand. Escalating from a host-wide default to per-brand policy — one brand wanting a stricter posture, another wanting a documented opt-out route — is configuration on the same infrastructure rather than a second deployment.
There are four of them. None is closed by a domain list, and each is better named up front than discovered later.
Taken together, that is the correct way to present this internally, to a regulator, and to subscribers. A defined, daily-refreshed set of verified live phishing hosts becomes unreachable on your network, by default, for every device including the ones nobody can install anything on. That is a large and cheap improvement over nothing at all, and it should never be described as more than it is.
Latency, list size, false positives, consent, and how any of this is paid for at subscriber scale.
On a local deployment the added work is an in-memory comparison against a loaded list, which is negligible against the recursion you were already performing. The list holds around 390,000 entries — small enough to sit comfortably in memory on any resolver built for carrier volume, and small enough that load time on reload is not an operational event.
Plan for it in the reload job rather than in an incident process. Keep a local allow-list that your converter applies after every import, so an override survives the next build instead of being wiped by it. That single design decision is what turns a false positive from an out-of-hours emergency into a one-line change.
That is a commercial and regulatory judgement rather than a technical one, and it varies by market. What can be said is that coverage is the variable that determines outcomes: an opt-in feature reaches the subscribers least likely to need it, so the protective effect of an opt-in deployment is much smaller than its adoption numbers suggest.
Not under a feed deployment. You download the complete database once per build cycle and every comparison happens on your own resolvers, so no subscriber query, sample or aggregate is transmitted anywhere. The only outbound traffic is your authenticated pull of the list itself, which contains nothing about any subscriber.
Yes, and it is one of the more efficient things a host operator can package. The list is loaded once on shared resolvers, and each brand gets its own block page and its own policy posture pointed at a sinkhole you operate. A small MVNO with no network engineering capability gets a security feature it could not have built, and your incremental cost is close to zero.
Nothing dramatic, and that is the design intent. The resolver keeps serving the copy it already has, so a failed pull degrades freshness rather than availability — you are protecting against yesterday's list rather than today's. The failure mode is silent, though, which is the actual risk.
It is cheap and it is a reasonable thing for an operator to offer inside an authenticated app or portal. A subscriber pastes a hostname, your server calls the check endpoint with your key, and your server returns a plain-language answer at one credit per submission. It gives the care function something concrete to point a worried customer at.
This page is about running phishing blocking as a subscriber-facing service: resolver deployment, consent, the block page, wholesale delivery and the economics of doing it at scale. It deliberately does not attempt a survey of carrier threat patterns or of the regulatory landscape.
Take the daily CSV feed, convert it for your resolver platform, alert on file age, and every device on your network is covered — including the ones nobody could ever install anything on. Keep credits for the care desk, the campaign screening and the brand checks where per-lookup billing genuinely fits.
