Monitoring is retrospective by construction: the alert fires because the data is already out. A feed of DNS-verified, currently-live phishing domains lets the same subscription intervene at the only moment in the timeline when the outcome is still cheap to change — the second before a credential leaves the keyboard.
Breach notification, dark web monitoring and credit alerts all share one structural property: they fire once the subscriber's data is already in somebody else's hands.
Draw the timeline of a consumer identity incident and the products in this market cluster at one end of it. A credential is phished on a Tuesday. It is tested against a dozen other services by Thursday. It appears in a combolist some weeks later, is ingested by a monitoring provider, and produces an alert. By the time the subscriber's phone buzzes, the useful decisions have all been made by somebody else. The alert is real, the monitoring worked exactly as designed, and the subscriber is still going to spend a fortnight on the phone.
The shape of a consumer identity incidentThis is not a criticism of monitoring — the market exists because that alert is genuinely worth having, and restoration support is worth more still. It is an observation about where the leverage sits. Every hour you move the intervention earlier reduces the cost of the incident by more than the previous hour did, and the curve is steepest right at the start. The single highest-leverage moment in the entire sequence is the one immediately before the subscriber types a password into a page that is pretending to be their bank. After that moment you are managing consequences. Before it, there are no consequences to manage.
A known-bad domain lookup is the cheapest tool that operates in that window. It does not need to be clever, it does not need to understand the page, and it does not need to reason about intent. It needs to answer one question quickly and correctly: is this hostname currently a live, verified phishing site? When the answer is yes, the product can stop the navigation, or refuse to autofill, or throw an interstitial, and the entire downstream chain of alerts and restoration calls simply never begins for that subscriber.
There is a commercial argument sitting underneath the security one, and product teams in this category will recognise it immediately. Retention in identity protection is a function of perceived value, and perceived value is a function of the subscriber seeing the product do something. A monitoring product is silent for months and then delivers bad news — which is precisely the wrong emotional shape for a subscription renewal. A product that visibly stops something, that lets a subscriber check a suspicious text and get an answer in a second, that occasionally says "we blocked this for you," creates the daily engagement the category has always struggled to manufacture.
The rest of this page is about where that lookup goes in a real product: the components that consume it, the alerting it makes possible, how it changes a restoration case, and the honest boundaries you have to design around so the in-app copy does not write cheques the data cannot cash.
None of these require a new product line. Each one is a lookup added to a component the subscription already ships, and every one of them is server-side.
Most identity suites already ship an extension for password autofill or breach warnings. Giving it a blocklist turns it into an active control: on navigation, resolve the host against the local copy of the feed and interrupt before the page paints. Keep the list in the extension's own storage and refresh it from your backend, never call the API from the extension itself.
If the app already routes traffic through a VPN profile or a custom DNS resolver for tracker blocking, phishing enforcement is the same mechanism pointed at a different list. This is the highest-coverage surface you own because it catches links opened from SMS and messaging apps, which is where most consumer phishing actually arrives.
A field in the app where a subscriber pastes a suspicious link and gets a verdict. Cheap to build, unusually sticky, and the only feature in most identity apps that a subscriber has a reason to open on a random Wednesday. The check endpoint strips protocol and path automatically, so a pasted full URL works without client-side parsing.
You know which institutions a subscriber has connected — their bank, their card issuer, sometimes their employer. Watching the daily feed for newly added domains that imitate those specific brands turns a generic threat stream into a personal notification that names an organisation the subscriber recognises.
A breach notification is more useful when it says what comes next. Populations exposed in a breach are targeted by follow-on phishing that impersonates the breached brand, so pairing the alert with the current verified domains imitating that brand converts a passive warning into an actionable one.
Every surface above consumes the same primitive — a hostname, a verdict — and none of them should ever hold your API key. The key is the username chosen at registration, and anything shipped to a subscriber device is public. Extensions get a list pushed from your infrastructure; mobile clients ask your backend, which asks ours; the link checker posts to your own endpoint where you can rate-limit, cache and log. Build the caching layer early: subscriber traffic is enormously repetitive, and a short-lived cache in front of the check endpoint will absorb most of it before a single credit is spent.
Identity products are bought once and opened rarely. A verdict tool is the rare feature subscribers have a genuine reason to return to, and it is a two-week build.
Ask anyone who has run growth on a consumer security product what their engagement numbers look like and you will get the same answer: the subscriber signs up, completes onboarding, connects a couple of accounts, and then does not open the app again until something goes wrong. Every feature added to fix this — dashboards, scores, educational content — competes for attention against everything else on a phone and generally loses, because none of them answer a question the subscriber is actually asking at that moment.
A link checker does. People receive suspicious messages constantly and have nowhere to take them. The current options are to ignore it, to click and find out, or to ask a relative who is assumed to be good with computers. A field in an app they already pay for, which returns a clear verdict in under a second, fills a real gap in a real moment. It also has the property every retention feature wants and few have: the subscriber arrives with intent, gets an answer, and associates the answer with the subscription they are paying for.
The implementation is small. The client posts a pasted string to your backend. Your backend normalises it and calls the check endpoint, which strips http://, https:// and any path segments automatically — so a mangled forwarded URL still resolves to a domain without client-side parsing. The response returns is_phishing, category, dns_status, last_checked and a confidence of 0.98 on a confirmed hit or 0.0 when there is no match. one lookup per API call, and a rate limit of ten requests per second per key that a normal consumer app will never approach.
The design work is in the copy, not the code, and it is where most implementations of this feature go wrong. Two verdicts are easy to write and one is hard. A confirmed hit is unambiguous: this address is a known phishing site, do not enter anything, here is what to do if you already did. A malformed input is easy too. The hard one is a clean result, because the honest meaning is "this is not on our list of known phishing domains" and the tempting meaning is "this is safe." Those are not the same sentence and a subscriber who is later defrauded by a domain that was too new to be listed will remember which one you showed them.
Say that no match was found against a database of over 200,000 verified live phishing domains updated every 24 hours, then immediately give the subscriber the checks the tool cannot do for them: did you expect this message, does the domain match the organisation exactly, and would you reach the same page by typing the address yourself. That framing is more useful than a green tick and it protects the product from a complaint you would otherwise deserve.
Product decisions downstream of a threat feed depend on knowing exactly what it contains and how often it moves. These are the numbers to plan against.
Two of those numbers deserve unpacking because they shape architecture rather than just budget. The 24-hour rebuild cycle is the reason a locally-held copy of the feed is viable for real-time enforcement: a browser extension or DNS component that refreshes daily is never more than one build behind the service itself, so pushing the list to the client costs you nothing in freshness compared with querying live. The 04:30 UTC landing time is what your scheduler should be built around, with a check that the file you fetched is genuinely newer than the one you are replacing.
The verification standard is the other thing worth understanding. Every domain in the database is confirmed via rotating proxy infrastructure to have an active A record, and only resolving domains are included. That is why the active figure sits at roughly 200,000 against nearly half a million observed all-time — the file is a snapshot of what is live rather than a growing archive. For a client-side list this matters enormously, because the size of the payload you push to a subscriber's browser stays bounded instead of climbing forever, and entries that have gone dark stop consuming memory and match time on a device you do not control.
Per-lookup pricing runs from $0.0040 on the Growth package down to $0.0008 on the $499/month Scale package, with lookups reset monthly. For a subscriber base of any size the arithmetic is dominated by how much you cache rather than by which tier you buy, which is why the caching layer is worth building before you tune the package choice. Teams running the feed rather than per-query lookups can ignore the credit maths for enforcement entirely and reserve credits for the analytical work: batch-checking domains extracted from a breach corpus, validating a support ticket, or confirming a host during a live restoration case.
Four stages, each of which you own except the first. The point of drawing it this way is that the subscriber-facing part is the shortest and simplest piece.
A scheduled pull of the CSV or JSON feed shortly after 04:30 UTC, plus the changelog of domains added and removed since the last build.
Load into whatever your services query — a hash set, a Bloom filter for the client payload, a table joined against your subscriber institution map.
Push a compact list to extensions and mobile clients, expose an internal verdict endpoint for the link checker, and feed the diff into your alerting engine.
Block the navigation, suppress the autofill, or surface an interstitial. The subscriber sees a warning instead of a login form, and nothing else happens.
A server-side hash set of a few hundred thousand hostnames is trivial. A client-side list is more interesting: shipping the raw file to every browser extension is wasteful, so most teams build a probabilistic structure — a Bloom filter sized for a low false-positive rate — push that to the client for instant local rejection, and confirm any positive against your backend before showing the subscriber anything. That gives you sub-millisecond local checks, no per-navigation network call, and no possibility of an incorrect block reaching a subscriber's screen.
Alerting needs to know what is new, not what exists — a component that re-scans the entire database daily to find newly-added domains impersonating a subscriber's bank is doing hundreds of thousands of comparisons to surface a handful of rows. The changelog collapses that to the additions and removals since yesterday, which is both cheaper and semantically correct: "this appeared today" is the fact you want to notify on.
The temptation is to build a rich warning experience with education, reporting and follow-up actions. In practice the subscriber is mid-task, mildly alarmed, and wants two things: confirmation that they should not proceed, and a way out. Give them a clear statement, the hostname, one primary action that takes them somewhere safe, and a small secondary link to a longer explanation. Anything more is designed for your product review rather than for the person on the other end.
The difference between a threat feed and a product feature is whose name is on it. You already know which institutions matter to each subscriber.
Identity products accumulate a quietly valuable asset during onboarding: a map of the institutions each subscriber actually deals with. Which bank, which card issuers, sometimes the employer through a benefits-sponsored plan, often the brokerage or the mortgage servicer. That map is normally used for monitoring coverage. It is also exactly the join key that turns a generic list of newly-registered phishing domains into a notification a subscriber will read.
The mechanics are unglamorous and that is the point. Take today's added-domains changelog. Match it against your institution list using whatever brand-token matching you trust — this is your matching logic, not something the API performs, and it is worth being conservative because a false match generates a frightening notification about a bank the subscriber depends on. When a confident match appears, notify the subscribers connected to that institution: a domain imitating their bank was verified live today, here is the hostname, your product is already blocking it on the devices where our extension is installed, and here is what a message from that domain would look like.
Breach-alert enrichment is the same idea pointed at a different trigger. When a breach is disclosed and part of your subscriber base is in it, the notification you send is usually a description of exposure plus generic advice. The population in that breach is about to be targeted by follow-on phishing that impersonates the breached brand, because attackers know exactly the same thing you do about who is anxious and who is expecting a message from that company. Attaching the currently-verified domains imitating that brand turns "your data may have been exposed" into "here is the specific thing that is about to arrive in your inbox, and we are blocking these hosts already."
That notification does something no monitoring alert can. It is timely rather than retrospective, it names an organisation the subscriber recognises, it arrives before anything bad has happened to them personally, and it demonstrates that the subscription is doing work on their behalf continuously rather than waiting for a disaster. Teams already running this kind of watch programme for their own brand will recognise the pattern from the brand protection use case; the difference here is that you are running it on behalf of institutions you do not own, for subscribers who do business with them.
Why a targeted alert lands differentlyThe failure mode for all personalised alerting is habituation: a subscriber who receives four of these a week stops reading them, and then does not read the one that mattered. Rate-limit per subscriber, collapse multiple domains impersonating the same institution into one notification, and set a high bar for the brand-match confidence. A quiet channel that fires rarely and is always right is worth more than a busy one that is usually right.
One faces the restoration specialist working an active case. The other faces the fraud team defending the brand a fake "your identity was stolen" page is imitating.
Start with restoration, because it is the part of these products that subscribers value most and that gets the least engineering attention. A specialist picks up a case with a distressed person on the other end who cannot reliably reconstruct what happened. The single most useful early question is what they visited and what they typed, and the answers arrive as fragments: a screenshot, a forwarded text, a half-remembered address, a browser history export the subscriber managed to produce.
Running those fragments through the batch endpoint — up to a hundred domains per request, one lookup each — turns a vague narrative into an established fact within a minute. When a hostname comes back confirmed, the specialist knows which credentials to treat as compromised, can date the exposure against last_checked, and can stop guessing about scope. When nothing matches, that is genuinely useful too: it is not proof of safety, but it redirects the investigation away from a phishing hypothesis toward the other ways an identity gets compromised. Either way the case notes now contain something verifiable, which matters if the case ever ends up in front of an insurer or a bank's fraud department. The workflow parallels the one described on the incident response page, scaled down to one victim.
The second job is defending yourself, and this industry has an uncomfortable structural problem. A fake page announcing "your identity has been stolen — verify your account immediately" converts extraordinarily well, because it manufactures precisely the panic that overrides careful behaviour. Identity protection brands are therefore attractive to impersonate, and your subscribers are pre-conditioned to expect alarming messages from you. Every reassuring email you send teaches your own users to respond to a template that somebody else can copy.
Practically this means running the same domain surveillance on your own brand that you run on behalf of subscribers' banks, and it means being unusually strict about your outbound communication patterns. Decide once that your alerts never contain a login link, say so in every message, and then never make an exception for a campaign. Publish the domains you send from. Watch the daily changelog for hosts imitating your own name and the names of the insurers or employers who white-label your service, because a fake page targeting an employer's benefits portal will use the employer's brand rather than yours and will not appear in a search for your own trademark.
When a subscriber forwards something claiming to be from you and asks whether it is genuine, the agent should not be making a judgement call from a screenshot. A verified lookup against the hostname gives a defensible answer in seconds, and gives your fraud team a running count of which impersonation campaigns are actually reaching your users rather than which ones you happened to notice.
The two halves answer different questions at different points on the timeline. Product marketing gets into trouble when it lets one of them borrow the other's promise.
| Capability | Monitoring & breach alerting | Phishing-domain blocking | Both in one subscription |
|---|---|---|---|
| When it acts | After the data is already exposed | Before the credential is typed | Both ends of the timeline |
| What the subscriber experiences | A notification about something that happened | A page that will not load, or an autofill that refuses | Prevention first, notification as the fallback |
| Handles a brand-new, never-seen domain | Not its function | No — it is a known-bad lookup | Only with your own additional signals |
| Generates day-to-day engagement | Silent for months at a time | Link checks and block events | A reason to open the app |
| Useful during restoration | Establishes what leaked | Establishes what the victim visited | Both halves of the narrative |
| Unit of the verdict | An identity attribute or record | A hostname — not a page or a path | Design the UX around both units explicitly |
| Cost shape as subscribers grow | Scales with records monitored | Flat with a feed subscription; per-lookup on credits | Feed for enforcement, credits for analysis |
Row three is the one to internalise. This service is a known-bad lookup against a verified inventory of live phishing hosts. It does not classify pages it has never seen, it does not score unfamiliar domains heuristically, and it will not catch a hostname registered this morning and used for the first time this afternoon. Anything you build on top of it should treat a clean response as the absence of a match and pair it with your own signals — domain age if you have it, whether the subscriber has ever visited the host before, whether the link arrived from a channel you consider risky, whether the destination is asking for credentials at all.
That layering is normal and every serious deployment does it. The value of the known-bad layer is that it is unambiguous where it applies: a hit is a hit, the confidence is 0.98, the host is confirmed to resolve, and you can act on it without a human in the loop. Reserve your fuzzier signals for the cases the list does not cover, and keep the two verdicts visually distinct in the interface so a subscriber can tell the difference between "this is a known phishing site" and "we are not sure about this one."
On layering the known-bad verdictEnforcement traffic — every navigation from every subscriber device — should never be billed per lookup, which is why the feed exists and why teams building the extension or the DNS component subscribe rather than metering. Credits are the right instrument for bounded, analytical work: restoration cases, support tickets, batch validation of a corpus, a one-off audit. Mixing those up is the most common way a team ends up with either a surprising bill or a component that cannot scale.
The daily record of domains added and removed is not only an operational artefact. It is the raw material for the recurring content this category perpetually needs.
Every subscription product in this market runs a newsletter, a dashboard panel, or an in-app feed that has to say something regularly. The people writing it are usually rewriting news coverage of last month's breach, which is neither timely nor differentiated — anyone can read the same article. The changelog gives you something nobody else is publishing: an observed, verified record of what actually appeared on the internet this week and what disappeared.
Group this week's newly-verified domains by the sector or brand family they imitate, count them, and write two hundred words about the pattern. Banking impersonation was up this week; a cluster of new domains targeted parcel delivery notifications; the tax-season shape appeared again in February. You are describing your own data, so the claim is defensible, and you can be specific about method — these are hostnames confirmed to have an active A record, verified in the last 24 hours, not a list of things somebody reported.
The removals half is more interesting and almost nobody uses it. Domains leave the list when they stop resolving, which is what happens when infrastructure is taken down, abandoned, or rotated away from. Watching that churn illustrates the single most important thing a subscriber can understand about phishing: these sites are ephemeral. They exist for days. The instinct that "I would recognise a fake site" fails not because people are careless but because the site is new, the campaign is short, and recognition was never a viable defence. That is a genuinely educational message and it is far more persuasive when it is illustrated with movement in a real dataset than when it is asserted in a bullet list.
A small module showing how many verified live phishing domains exist right now, when the database was last rebuilt, and how many were added since yesterday gives the subscriber a reason to glance at the app and a constant reminder that something is running on their behalf. The open /stats endpoint returns the database size and last update with no key, no credits and no authentication, which makes that panel trivial to build and impossible to get wrong. Teams doing this at scale usually pair it with the approaches on the threat intelligence and security awareness pages.
Describe what the data is and resist the urge to extrapolate from it. The changelog tells you what was verified in this database over a period; it does not tell you what happened across the whole internet, and it is not a measurement of attack volume. Write "we verified this many new phishing domains this week" rather than anything that sounds like a global statistic, and your content stays accurate as it gets shared.
Mostly about limits, cost shape, and how far the claims in the app can honestly go.
No. The API key is the username chosen at registration and anything shipped to a subscriber device is recoverable, so a key embedded in a client is a key you have published. Route every request through your own backend, which lets you cache repeated hostnames, apply per-subscriber rate limits, and rotate the key without an app release. For enforcement components that need local decisions, push a derived list — a hash set or Bloom filter built from the feed — rather than exposing credentials to make live calls.
No, and this is the most important copy decision in the whole integration. The service answers whether a hostname is a known, currently-live phishing domain. A response of is_phishing: false with a confidence of 0.0 means no match was found, not that the destination has been evaluated and cleared. Write the clean state as a status — "not found in our database of known phishing domains" — and follow it with the checks the subscriber should still perform. Presenting it as certification is the one mistake that converts a helpful feature into a liability.
The check endpoint strips http://, https:// and path segments automatically, so a pasted full URL resolves to its domain without any client-side parsing on your side. Verdicts are per-domain, which means a hostile path on an otherwise legitimate host is outside what this answers. Shorteners need your own resolution step first — follow the redirect on your backend, then check the final hostname — and you should decide deliberately what to show when a shortener will not resolve, because that is a common state and it is neither a hit nor a clean result.
Both, for different jobs. Anything driven by subscriber traffic volume — extension navigation checks, DNS-level enforcement, the link checker at scale — belongs on the Daily Threat Feed at $499 per month, because the cost is flat regardless of how much your users browse and the matching happens in your own infrastructure. Bounded analytical work belongs on credits: restoration cases, support escalations, batch validation. The annual feed plan includes 100,000 API credits, which covers that second category for most teams without a separate purchase.
The daily changelog of added and removed domains, which ships with the feed subscription. Newly added rows are what you match against your subscriber institution map to produce a targeted alert; removals are what keep your own index from accumulating dead hosts. Note that the brand-matching logic is yours to build — the service tells you a domain is verified phishing infrastructure, not which company it is imitating — so budget engineering time for that matcher and tune it conservatively, since a false match produces an alarming notification about a subscriber's bank.
No — the model is pull-based. You schedule a fetch of the feed and the changelog after the daily build lands at 04:30 UTC and drive your own downstream events from the diff. In practice this is easier to operate than a push integration: there is no endpoint of yours to keep available, no delivery retry semantics to reason about, and a failed pull is a condition your scheduler already knows how to alert on. Enterprise arrangements can cover SFTP or S3 delivery and custom update frequencies if your pipeline prefers to be delivered to.
Pick a monthly plan, then take a corpus you already trust — reported links from your support queue, hosts pulled from subscriber-forwarded messages over the last quarter — and run it through the batch endpoint at a hundred domains per request. That gives you a hit rate measured against your own traffic rather than a vendor's sample, which is the only number worth taking to a build decision. The /stats endpoint needs no key at all if you just want to confirm database size and freshness first, and the monthly plans carry a 14-day refund if under 10% of the credits are used.
Start with a monthly plan sized to your first month and measure the hit rate against links your own subscribers have already reported. When the extension, the DNS component or the link checker is ready for real traffic, the daily feed makes enforcement flat-cost and keeps every lookup inside your own infrastructure.
