A mobile network operator is impersonated by phishing crews and, at the same time, resolves the DNS queries of every subscriber on its network. Both facts point to the same control: a current, DNS-verified list of active phishing domains, applied at the recursive resolver and queried from the care channel.
No other industry sits on both sides of a phishing campaign at once, and the operational answer differs for each side.
Start with the target side. A mobile network operator or a fixed-line ISP has a subscriber base numbered in the millions, a monthly billing cycle that everyone recognises, and a brand that arrives on the handset legitimately several times a month. That combination is what makes an operator worth impersonating. The lure writes itself: a payment has failed, the account is in arrears, service will be suspended within twenty-four hours, click here to settle. The landing page is a copy of the self-service portal, sometimes a good copy and sometimes a rough one, and it asks for the same three things the real portal asks for. Because the message plausibly concerns money the subscriber genuinely owes, the conversion rate on this lure stays stubbornly high regardless of how much consumer education the operator funds.
The second target-side pattern is more damaging per victim and less visible in aggregate. SIM-swap and port-out fraud do not need to fool the subscriber at all; they need to fool the operator. A crew harvests enough identity detail from a phishing page dressed as an account verification step, then presents it to a retail store assistant, a care agent, or an online porting form. The credential that matters is not the subscriber's password but the operator's own trust in the person on the other end of the counter or the chat window. Retail staff and care agents are themselves phished directly, with lookalike domains built to resemble internal tooling, the CRM used in the care channel, or the single sign-on page that fronts the BSS and OSS estate. A compromised agent session is worth far more than a compromised subscriber login, because it can be used repeatedly and at speed.
Now the defence side. Whatever else the operator is, it is the entity that answers the DNS query when a subscriber taps a link. Consumer broadband customers overwhelmingly use the resolver their CPE was handed by DHCP; mobile subscribers use the resolver advertised by the packet core. The operator therefore has a single enforcement point that sits in front of every handset, laptop, smart television and unmanaged device on the network, including the ones that will never run a security agent, never receive an update, and belong to people who would not recognise the word phishing. Blocking a domain there protects the subscriber who is least equipped to protect themselves, and it costs the subscriber nothing.
Those two roles need different tooling from the same data. Defending the network means applying a large list of known-bad domains to a resolver at line rate, with no per-query call to anything external. Defending the brand and the care channel means asking a targeted question about a handful of domains at the moment a human is deciding whether something is genuine. This page describes both: the daily CSV feed as the artefact that feeds a response policy zone, and the lookup API as the call a care desktop or an abuse-desk triage script makes. A network security architect will care about the first. An abuse desk lead and a care operations manager will care about the second. The head of consumer protection will want to be able to describe both to a regulator.
Consumer, wholesale and enterprise lines of business are attacked differently, and the same domain list serves all three.
Phishing against a telecommunications operator is not one campaign type repeated. It splits along the operator's own commercial structure. The consumer line of business sees high-volume, low-sophistication lures delivered by SMS and increasingly by RCS, where a rich card with a logo and a button is more convincing than a plain text message ever was. The wholesale and interconnect side sees a small number of carefully researched invoice and settlement frauds aimed at a handful of people who move real money. The enterprise or B2B line sees credential phishing against the customer-facing portal that corporate accounts use to manage their fleets, order circuits and pull call detail records.
What unites them is infrastructure. Almost every one of these campaigns terminates on a registered domain that resolves to an A record at the moment the victim clicks. That is the observable the operator can act on, and it is the only observable that is common to a smishing link, a spoofed care portal, a fake device-financing offer and a settlement-fraud landing page. The six patterns below are the ones an abuse desk at a carrier reports seeing most consistently.
A short link in a text message, delivered through a grey-route aggregator or a SIM farm, resolving to a page such as account-verify-mobile.example.net. RCS makes the same lure look branded and verified, which raises the click-through rate without changing the underlying domain.
A near-pixel copy of the self-service payment page, timed against the billing cycle so it lands in the same week as the real invoice. It collects card details and, increasingly, the one-time code needed to complete a strong customer authentication challenge on the genuine payment.
A lookalike self-service portal harvests the identity attributes a retail assistant or care agent will later ask for. The phishing page is the reconnaissance step; the fraud happens at the counter or in the porting workflow minutes or hours afterwards.
Fake early-upgrade or handset-trade-in offers, often keyed to a real launch date, that ask for a deposit and an identity document. These sites also feed downstream identity fraud, because the operator's own credit-check flow uses the same attributes.
Settlement and interconnect teams reconcile large sums with a small number of counterparties on a monthly cadence. A domain one character away from a real carrier's, sending revised bank details ahead of a settlement run, is the classic form.
The B2B portal where corporate customers manage fleets, provision SIMs and download call records is a high-value target. A single compromised administrator account can be used to order SIM replacements across an entire organisation.
DNS-layer enforcement is the cheapest control an operator owns, because the query already passes through infrastructure the operator runs. A response policy zone, or RPZ, is the mechanism: a specially formatted DNS zone loaded into a BIND or Unbound-class recursive resolver that lets the resolver rewrite or withhold answers for names on the list. The zone is ordinary DNS data, transferred by AXFR or IXFR from a hidden primary, so it fits the change-management and monitoring the DNS team already has. No new inline appliance sits in the query path, and no new failure domain is introduced beyond the resolver itself.
The daily CSV feed is the natural artefact for this. Each export carries the domain, its category and its DNS status, which is exactly the shape a zone-generation script wants. A carrier typically runs the export through a small transform that emits one RPZ record per domain, signs or checksums the resulting zone, bumps the SOA serial, and notifies the resolver fleet. Because the feed is rebuilt every twenty-four hours and every domain in it has been confirmed to resolve, the zone stays roughly the size of the live threat rather than growing without limit. Domains that stop resolving are pruned upstream, which matters more than it sounds: an RPZ that only ever grows eventually becomes a memory and reload cost the resolver team will push back on.
Cache TTLs interact with a daily rebuild in a way worth planning for. RPZ is evaluated on the recursive resolver before the cached answer is returned to the client, so a newly added domain takes effect on the next query regardless of what is already cached for that name. Removal behaves differently: a client that has been sinkholed may hold the sinkhole answer for the lifetime of the RPZ record's own TTL, so keeping that TTL short, in the order of minutes rather than hours, limits how long a false positive lingers after it has been corrected. Zone reloads on a large RPZ are best done incrementally rather than as a full re-transfer.
Finally, decide between sinkholing and NXDOMAIN, because the choice is a policy decision more than a technical one. Returning NXDOMAIN is quiet and cheap: the browser shows a generic failure and the subscriber concludes the site is broken. Redirecting to a sinkhole address the operator controls costs a little infrastructure but buys two things a consumer-protection team values highly. The subscriber sees an explanation instead of an error, which turns a blocked page into a moment of education, and the operator gets a hit log that shows which campaigns are actually reaching its customers. Most carriers that deploy this at scale sinkhole rather than NXDOMAIN for exactly that second reason. If you want the wider pattern rather than the carrier-specific one, the DNS filtering use case covers resolver integration generally.
Handset or laptop taps a link from an SMS, an email or a browser tab.
Home gateway forwards the query, or the mobile core hands out the operator resolver by DHCP or PCO.
BIND or Unbound-class resolver receives the query behind CGNAT, before any upstream recursion.
Zone built from this morning's CSV export is consulted. A match rewrites the answer.
Operator-controlled address serves an explanation and logs the hit for the abuse desk.
Nothing is installed on the device. The control applies to every subscriber using the operator's resolver, including unmanaged and legacy hardware.
The resolver stops a click that has already happened. The API answers a question someone is asking right now, and there are four places in a carrier where that question comes up constantly. The first is the care agent desktop. A subscriber calls or opens a chat saying they have received a message about their bill and are not sure it is genuine. The agent needs a verdict in the seconds available before the conversation stalls, not a ticket to a security team. A single call to /api/v1/check from the CRM, rendered as a coloured chip next to the domain the subscriber read out, is enough to close that conversation confidently.
The second is the A2P messaging path. An operator that terminates application-to-person traffic, whether directly or through an SMS aggregator, screens content on short codes and alphanumeric sender IDs before delivery. Extracting the hostnames from candidate message bodies and batching them against the API gives a content-screening step a factual signal rather than a heuristic one, and it applies equally to a grey-route filter and to a legitimate aggregator's own compliance checks. The third is the operator's own self-service app: outbound links in in-app messages and push notifications can be checked before they are rendered, which stops the app itself from becoming a delivery channel if a content system is ever compromised.
The fourth is abuse-desk triage. Subscribers forward suspicious texts to a spam-reporting shortcode in large volumes, and the abuse desk lead needs to sort that queue by something better than arrival time. Batching the extracted domains and sorting by is_phishing turns a flat queue into a ranked one, and the domains that come back unknown are the ones worth a human look, because they may be new infrastructure the feed has not seen yet. The worked example below shows exactly that: four hostnames pulled from reported SMS, screened in one request.
curl -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{
"apikey": "YOUR_API_KEY",
"domains": [
"billing-account-restore.example.net",
"mobile-invoice-settle.example.org",
"sim-registration-update.example.com",
"myaccount-reconnect.example.net"
]
}'
{
"results": [
{ "domain": "billing-account-restore.example.net",
"is_phishing": true,
"category": "phishing/malware",
"dns_status": "resolves",
"confidence": 0.98 },
{ "domain": "mobile-invoice-settle.example.org",
"is_phishing": true,
"category": "phishing/malware",
"dns_status": "resolves",
"confidence": 0.98 },
{ "domain": "sim-registration-update.example.com",
"is_phishing": false,
"category": null,
"dns_status": null,
"confidence": 0.0 },
{ "domain": "myaccount-reconnect.example.net",
"is_phishing": false,
"category": null,
"dns_status": null,
"confidence": 0.0 }
],
"checked": 4,
"phishing_found": 2,
"credits_used": 4
}
The honest answer for most operators is both, but they are bought differently and it is worth understanding why before the procurement conversation.
The economics diverge sharply at carrier volume. A recursive resolver fleet serving a national subscriber base handles query rates measured in hundreds of thousands per second at peak. Calling an external API on every one of those queries is not an architecture; it is a denial of service against yourself, and it would add a network round trip to a path where the entire budget is a few milliseconds. The daily feed exists precisely for this case. You download the full database once, build a local zone from it, and every subsequent enforcement decision happens in the resolver's own memory with no external dependency at all. The feed subscription starts at $499 per month with annual plans available, which is a fixed cost independent of query volume.
The API economics run the other way. Each lookup costs one credit, and credits are bought in packs that get cheaper per unit as they get larger: $59 for 10,000 at the Starter end, through $249 for 100,000 and $499 for 250,000, down to $3,999 for 5,000,000 credits on the Scale package at $0.0008 each. Credits are valid for twelve months. For care-desk lookups, abuse-desk triage and messaging-path screening, the volumes are in the thousands or low tens of thousands per day rather than the hundreds of millions, so per-lookup pricing is not only workable but usually cheaper than it looks. The relevant question is not which model is better but which enforcement point you are talking about.
There is also a freshness argument that cuts both ways. The database is rebuilt every twenty-four hours and the CSV export runs at 04:30 UTC, so a resolver zone built from the morning's file is at most a day behind the database. An API call is always against the current database state, which is the right choice when a human is waiting for an answer about a specific domain that may have been added since the last export. Operators that run both accept a small window on the resolver and close it with a live call wherever a person is in the loop. The comparison below is the one a network security architect and a head of consumer protection usually work through together.
| Decision factor | Daily feed into the resolver | Per-lookup API call | Both together |
|---|---|---|---|
| Enforcement point | Recursive resolver, RPZ, DNS firewall, on-net gateway | Care desktop, CRM, abuse-desk triage, A2P content screening, app link handling | Network-wide block plus a human-facing verdict |
| Latency budget | Zero added latency; the decision is local to the resolver | Sub-50ms typical response, fine for a person waiting, not for line-rate DNS | Local for bulk traffic, remote only where a human is in the loop |
| Volume and credit economics | Flat subscription from $499/month regardless of query volume | 1 credit per domain; packs from $59/10,000 down to $0.0008 each at 5,000,000 | Fixed cost carries the network, credits carry the desk |
| Offline operation | Works with no reachability to the provider once loaded | Needs an outbound path at the moment of the call | Resolver keeps enforcing if the API path is unavailable |
| Freshness | As of the 04:30 UTC export; up to 24 hours behind the database | Current database state at the moment of the query | Bulk coverage daily, live confirmation on demand |
| Change auditing | Each export is a diffable file; daily changelog shows what moved | Per-call responses logged by your own system, with last_checked per domain |
Zone history for the regulator, call logs for the incident record |
The sequence most carriers follow, sized so each step can be reversed without touching subscriber traffic broadly.
Stand up one recursive resolver in a single region carrying internal or staff traffic. Log-only at first, so you see what would have been blocked before anything is.
Automate the transform from the 04:30 UTC CSV export to an RPZ zone file, with a serial bump, a size sanity check and an allowlist for operator-owned and partner domains.
Publish an operator-branded block page on an address you control, in the languages you serve, with a clear route to dispute a block and a reference the care desk can look up.
Add the single-check call to the agent desktop inside the CRM, so an agent can verify a domain a subscriber reads out without leaving the contact.
Feed sinkhole hit counts and reporting-shortcode submissions back into weekly review, so the SOC sees which campaigns are landing and consumer protection gets a number to report.
What an operator must do, what it may do, and why the documentation around a blocklist matters as much as the blocklist.
In the European Union, NIS2 names providers of public electronic communications networks and publicly available electronic communications services among the sectors in scope. For an operator that means cybersecurity risk-management measures proportionate to the risk, incident reporting to the competent authority on defined timelines, and, significantly, accountability at management-body level for approving and overseeing those measures. The practical effect inside a carrier is that a control like resolver-level phishing blocking stops being a discretionary engineering project and becomes something the board-level owner is expected to be able to describe. Member state transpositions differ in detail, so the specific thresholds and reporting windows should be confirmed against your national implementing law rather than assumed.
National telecommunications regulators have separately and increasingly set expectations around scam calls and scam texts. The pattern across jurisdictions is broadly similar even where the instruments differ: registers or restrictions on alphanumeric sender IDs, obligations to block or filter traffic with spoofed or implausible calling line identification, requirements to act on reported scam messages, and general customer-protection duties that require an operator to take reasonable steps to prevent foreseeable harm to subscribers. Where a regulator has published guidance on scam-text mitigation, a documented, dated, externally sourced blocklist applied at the resolver is a straightforward thing to point at, because it is evidential rather than aspirational. Operators should check the current position with their own regulator rather than relying on a general description.
GDPR applies throughout, and two aspects matter here. Article 32 requires security measures appropriate to the risk for the subscriber personal data the operator processes, which is a direct argument for phishing controls that reduce the chance of subscriber credentials being harvested and used for account takeover. Articles 33 and 34 govern breach notification, including the 72-hour notification to the supervisory authority, which is why the timeline evidence from a sinkhole log is worth keeping. Resolver query logs, separately, are among the most privacy-sensitive data an operator holds, because a full query history describes a person's life in some detail.
That sensitivity is worth being precise about when choosing how to integrate. The lookup API takes a domain and returns a verdict on that domain. It does not require and should not be sent a subscriber identifier, an MSISDN, an IMSI, a subscription reference or a source IP address. An abuse-desk triage script that extracts hostnames from reported messages and submits only those hostnames is asking a question about infrastructure, not about a person, and that distinction is the one a data protection officer will focus on when reviewing the integration. The daily feed goes further in the same direction: it is a one-way download of a list, so no query data leaves the operator at all. Where a legitimate-interests assessment or a DPIA is required, the fact that the enforcement decision is made locally on operator-run resolvers is usually the point on which it turns.
Finally, there are constraints on what an operator may block. Lawful-intercept obligations, net-neutrality style rules on traffic management, and general prohibitions on unjustified blocking of lawful content all shape the space. The broad principle in most regimes is that traffic management must be transparent, non-discriminatory, proportionate, and not used to block lawful content for commercial reasons, with security-related exceptions typically permitted where they are necessary and time-limited. Blocking domains verified as active phishing infrastructure sits comfortably inside those exceptions, but only if the operator can show its work: where the list came from, how a domain got on it, how often it is refreshed, how a wrongly listed domain is removed and how quickly, and who authorised the policy. That is an argument for an externally sourced, dated, diffable list with a documented removal path rather than an internally curated one that nobody can reconstruct. Treat the specifics as jurisdiction-dependent and confirm them with regulatory counsel.
Three routes, depending on whether you are sizing the network control, the desk integration or the commercial case.
The network-operator view: resolver placement, subscriber protection at scale, and what changes between fixed-line, mobile and MVNO deployments.
Read the use caseScreening links carried in messaging traffic, including short-code and aggregator paths, plus how batching maps onto message throughput.
Read the use caseWhat the CSV contains, when it is exported, how the changelog is produced, and what the subscription includes at $499 per month.
See the feedAdjacent material that carrier security teams often read alongside this page: threat intelligence integration, managed security services for operators reselling protection to enterprise accounts, and the sibling brief on ecommerce and retail, which covers the payment-page side of the same billing lures.
Start with a key and a handful of test lookups from the care desktop, or take the daily export straight into an RPZ build on a pilot resolver. Both use the same DNS-verified database, rebuilt every twenty-four hours.
