Brand teams do not lack candidate domains. Permutation engines, registry feeds and certificate logs will hand you thousands of strings containing your trademark, most of them parked, dormant or owned by somebody with a perfectly good claim to the name. This page is about the opposite problem: taking a daily list of hosts confirmed to be phishing and confirmed to be resolving, matching your brand strings against it, and turning the overlap into a takedown queue with evidence already attached.
The permutation is the cheap part. Knowing which permutations are currently serving a credential form is the part worth paying for.
An anti-impersonation programme almost always starts by enumerating strings. You take the registered mark, the product names, the support subdomain everyone recognises, and you run them through a generator that emits character swaps, insertions, deletions, transpositions, hyphenations and every plausible top-level domain. That produces a candidate set in the tens of thousands for a mid-sized brand and in the hundreds of thousands for a household one. It is a useful inventory and a terrible worklist, because the overwhelming majority of those strings turn out to be one of the following.
The six shapes below are the ones that actually turn up inside confirmed phishing infrastructure, and they behave differently enough that a single detection approach will not cover all of them. Two of them involve no domain registration at all, which is why a programme built exclusively around new-registration alerting will report a clean week while a cloned checkout page quietly takes card numbers from your customers on somebody else's hostname.
A single dropped, doubled or adjacent-key character. Trivially generated, trivially registered, and effective because the human eye reads the word rather than the letters. Mobile address bars, which truncate aggressively and hide the middle of a hostname, make them harder still to catch by inspection.
String distance 1–2Characters borrowed from other scripts that render identically to Latin letters at normal type sizes. The host resolves through its punycode form, so it looks nothing like your brand in a log file and exactly like your brand in a browser. Any brand string sweep has to run against both representations or it will miss these entirely.
Punycode awareYour exact mark plus a service word — a login form, a security notice, a verification step, a rewards portal, an account update. The trademark is spelled correctly, which defeats edit-distance matching completely, and the appended word supplies the pretext the message needs to sound plausible.
Exact mark + suffixNo registration happens. The attacker claims a free subdomain on a shared platform and puts your brand in the leftmost label, where a truncated address bar shows it first. The registrable domain belongs to a legitimate provider, so registry monitoring never fires and a careless blocklist entry would break a service thousands of people rely on.
Host level, not registryA near-exact scrape of your storefront or help centre, re-hosted with the payment form and the contact number rewritten. The hostname may contain none of your marks, which means string matching never finds it — it surfaces through customer reports, referrer anomalies, or a feed match on a host you were not watching.
Content, not stringA domain built around a named individual rather than the company: a chief executive's surname, an initials-plus-company construction, a fake board portal. It rarely trips brand monitoring because nobody thought to add the leadership team's names to the watch list, and it lands directly in finance approval workflows rather than in front of customers.
Names on the watch listEvery domain in this database has been confirmed to resolve in DNS at the time of the build. When a host stops resolving it is dropped rather than kept as history. That single property is what makes the data useful to a takedown queue: a match is not a domain that once looked suspicious, it is a host that answered a query today.
It is not a trademark register, a WHOIS aggregator, or a judgement about who is entitled to a name. It contains confirmed live phishing hosts. A domain that infringes your mark while hosting nothing hostile will not appear in it, and that is the correct behaviour for a security feed rather than a shortcoming.
Impersonation works because recognition is a feeling, and the attacker only has to reproduce the feeling.
The work a brand team does to make a name instantly recognisable is precisely the work an attacker inherits for nothing. A customer who sees your logotype, your colour, your button shape and your support tone does not perform a verification step; they experience familiarity and act on it. Verification is the thing brands spend years training people out of, because friction costs conversions. Nobody reads a hostname character by character before entering a password, and the small population who would like to has been handed a mobile browser that hides most of the hostname anyway.
When someone is defrauded through a page carrying your identity, the complaint arrives at your support desk, the chargeback lands on your merchant account, and the account-takeover cleanup consumes your fraud team's week. You did not host the page, you did not send the message, and none of that is legible to the person who lost money. Brand protection often sits under marketing because the word "brand" is in the title, but the operational consequences land on security, fraud and support — and the budget conversation goes considerably better once that has been said out loud in a room with all three.
The attacker's cost per attempt is close to zero: a domain, a scraped template, an hour of configuration. Your cost per response is not zero, because a takedown is a human-written request to a third party who owes you nothing, followed by a wait, followed sometimes by a second request to a different party in a different jurisdiction. If the queue is fed by everything that pattern-matches your brand, most of that human effort goes to parked domains and unrelated businesses. The only way the arithmetic works is to filter hard on the one property that predicts whether a takedown is both possible and worth pursuing: whether the host is answering right now.
Registration and certificate-log alerting is genuinely valuable as early warning, but the signal it produces is thin. It says a name was registered, or a certificate was issued for a name resembling one of yours, and then it stops.
The feed answers a narrower question with far more confidence: these specific hosts were serving phishing and were resolving when the database was last rebuilt. Matched against your brand strings, that produces a queue rather than an alert stream.
Brand teams need both, at different moments, and the usual mistake is forcing one of them to do the other's work.
You subscribe, you pull the complete database as CSV once the rebuild lands, and you run the matching locally against a list of strings you control: the mark, its common misspellings, the punycode forms of its plausible homoglyph variants, product names, the labels you use for login and support subdomains, and the surnames of anyone whose signature moves money. A simple substring pass over a few hundred thousand rows finishes in seconds; a smarter pass that also strips hyphens and digits and computes edit distance takes a little longer and finds more. Because you are searching a file you have already downloaded, there is no cost per string, so you can afford to watch two hundred terms rather than the twenty a per-query budget would tolerate.
GET /api/v1/check?domain=<host>&apikey=<key> answers one hostname in typically under fifty milliseconds for one credit, which is what you want when a customer forwards a suspicious link to the abuse mailbox, when a fraud analyst is staring at a referrer inside a chargeback record, or when your support tooling wants to annotate a URL somebody just pasted into a chat window. POST /api/v1/batch accepts up to a hundred domains in one JSON body at one lookup each, which suits a nightly pass over a shortlist or over yesterday's inbound referrers.
The feed approach means the strings you are curious about never leave your infrastructure, which is worth something when the watch list includes an unannounced product name or an executive whose appointment has not been published. The API approach means you send a hostname and receive a verdict, which is exactly right for a domain somebody else already sent you and entirely wrong as a way to test your own unreleased roadmap against a third party.
# One hostname, one credit, typical response under 50 ms
curl "https://phishingdetectionapi.com/api/v1/check?domain=secure-login-yourbrand.com&apikey=YOUR_KEY"
# Up to 100 hostnames per request, one credit per domain
curl -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{"apikey":"YOUR_KEY","domains":["yourbrand-verify.net","yuorbrand.com","yourbrand.portal.example"]}'
# Fields returned for each domain:
# domain, is_phishing, category, dns_status, last_checked, confidence, database_sizeThe key travels as a query parameter or in the POST body, so it belongs on a server you control. It must never appear in a browser extension, a customer-facing page, or anything a visitor can open developer tools on. Brand monitoring is server-side work by nature, which makes this an unusually easy rule to keep.
Knowing exactly what each field claims — and what it does not — is what stops a takedown packet from overstating its case.
A takedown request is read by somebody at a registrar or hosting provider who receives a great many of them, most of them vague. The ones that get actioned quickly are specific, independently verifiable and modest in their claims. That means quoting the fields you actually hold rather than paraphrasing them into something stronger, and it means respecting the difference between this host was confirmed serving credential harvesting and confirmed resolving as of the most recent daily build and "this domain is stealing from our customers" — the second is a conclusion the recipient has to reach on their own, and handing it to them as a premise makes the whole packet read as advocacy.
The database is rebuilt on a twenty-four hour cycle and the accompanying changelog records what was added and what was removed on each build. For brand work the removals matter nearly as much as the additions: a host disappearing is the signal that a takedown landed, that the infrastructure rotated, or that the campaign simply moved on, and each of those means something different for how the ticket should be closed.
The verdict itself. A boolean rather than a score to be argued over, and the thing your matching pass filters on before anything reaches a human being.
Whether the host resolved at build time. This is the field that ranks the queue, because a host that no longer answers is not an urgent takedown.
When the verification ran. Quote it verbatim in the packet so the recipient can see the observation is hours old rather than months old.
What kind of lure it is. Useful for routing, because a fake storefront belongs with a different internal owner than a fake payroll portal.
The binding constraint is analyst hours, so the ordering rule has to be defensible and applied before anyone reads a single row.
Most brand protection functions are one to three people, sometimes inside legal, sometimes inside security, occasionally inside a fraud team that also handles chargebacks. Whatever the reporting line, the constraint is identical: the number of takedown requests a human can write, send, chase and close in a week. Every design decision downstream follows from that number, and the most valuable thing an automated pass can do is decide the order in which those hours get spent.
A host answering DNS queries is a host that can currently receive a visitor, which means the harm is ongoing and the abuse desk on the receiving end has something concrete to act against. A host that has stopped resolving may still deserve a registrar complaint on trademark grounds, but it is no longer a security incident and it should not be competing for the same hours. Because every entry in this database is verified as resolving at build time, a feed match arrives already filtered on that property — a materially different starting position from a permutation list where you have to test resolution yourself, one hostname at a time, before you know whether the case is even live.
A combosquat reproducing your login form outranks a domain that merely parks your name, because the first has a mechanism for converting a visit into a loss. A cloned checkout page outranks both, because the loss is immediate and the victim never even reaches an account. Executive-impersonation domains deserve a lane of their own: they are usually low volume, they target a handful of finance approvers rather than the customer base, and the correct response is often a same-day internal warning to those approvers rather than a takedown request that will take a week to land.
Some registrars and hosts respond to a well-formed complaint within hours; some route everything through a web form that produces no ticket reference; a few are effectively unreachable. Keep a private record of which is which and let it influence ordering, because two hours spent on a responsive provider removes more live phishing pages than two hours spent on an unresponsive one. This is unglamorous institutional knowledge that nobody documents and every team rediscovers, and it is worth writing down the first time you learn it.
Keep the queue honest by closing tickets when the feed says the host has gone. If a domain you filed against stops appearing in the daily list, the changelog records its removal, and that removal is the cheapest possible confirmation that the page is no longer live. It is not proof your request caused it — attackers rotate infrastructure constantly and would have moved regardless — but it is a factual close condition with a date on it, and it stops the queue silting up with items nobody can ever resolve.
Seven steps, of which the first three should be fully automated and the last four should emphatically not be.
A scheduled job downloads the current CSV and the changelog. Diffing against yesterday's copy gives you the additions to sweep and the removals to reconcile against open tickets. Keep both files: a packet is much stronger when you can show a host was present across several consecutive builds rather than seen once.
Run substring, hyphen-stripped and edit-distance passes over the new rows in both the Unicode and punycode representations. Include product names, the labels you use for login and support hosts, and the surnames of anyone who can authorise a payment. Keep the string set in version control so every addition to the watch list is reviewable and attributable.
Collapse hosts sharing a registrable domain into a single case, attach the category so it lands with the right internal owner, and rank by the money-proximity rule. Anything below your threshold goes to a weekly review list instead of the active queue, so it is recorded without consuming the hours you do not have.
This is the step teams skip and later regret. Capture a full-page screenshot, the response headers, the resolved address, the certificate details and a plain copy of the page source showing where the form posts. Record the timestamp of your own capture alongside the last_checked value from the feed. Once the page comes down, none of this can be recovered.
Separate the parties: the registrar of record, the provider actually serving the content, the certificate issuer, and where relevant the platform whose subdomain is being abused. Subdomain cases go to the platform and never to the registrar, because the registrable domain is legitimate and a registry-level action would be both wrong and refused.
State the exact hostname, what it is serving, when you observed it and what you are asking for. Attach the capture. Cite the mark and its registration if you have one, but lead with the security harm rather than the trademark argument — abuse desks move faster on credential harvesting, and the two claims travel to different teams inside the same company on very different clocks.
Rather than re-testing the host by hand, let the next build tell you. When the hostname leaves the database the removal appears in the changelog and the ticket closes with a dated reference. If it is still present a week later, escalate to the next party up the chain with the intervening builds as evidence of persistence.
A takedown request gets about ninety seconds of attention from somebody with a queue of their own. Write for that reader.
They contain one hostname, one screenshot, one set of response headers, one timestamp and one sentence describing what the page does. They do not contain a paragraph about the value of the brand, an estimate of damages, or a list of forty related domains the sender also dislikes. The recipient is not adjudicating a dispute; they are deciding whether the evidence supports switching something off, and every additional claim they cannot verify for themselves gives them a reason to move the item down the pile.
Independent corroboration helps. One line stating that the host appears in a database of DNS-verified live phishing domains, with the verification timestamp and the number of consecutive daily builds it has appeared in, tells the recipient that somebody other than the complainant observed the same thing. It costs a sentence and it converts your claim from an assertion into a corroborated observation.
Registrars and hosts run abuse desks and legal desks separately, and the two operate on entirely different timescales. A credential-harvesting report reaches an operations team who can suspend a host today; a trademark complaint reaches counsel who will reasonably want to hear from the registrant first. Leading with the security harm buys the fast path, and the trademark material is still sitting there for the cases that need the slow one.
Asking for an entire registrable domain to be suspended because one subdomain is abusive is disproportionate and will be refused; asking for the offending content or that specific subdomain to be removed will not be. Requesting the wrong remedy is the single most common reason a well-evidenced complaint goes nowhere, and it is entirely avoidable by reading your own evidence carefully before writing the ask.
The sentence that reframes the whole programme: a brand protection team is not measured by how many infringing strings it discovers, it is measured by how many live credential-harvesting pages it removes — and those are two different lists that overlap far less than anyone expects on the day they first put them side by side.
The feed carries the bulk matching; credits cover the point lookups a queue and a support desk generate between them.
Work out credit consumption from the events that genuinely require a per-domain answer, not from the size of your permutation list. In a typical week that means hostnames customers forward to the abuse mailbox, referrers a fraud analyst wants annotated, links inside a phishing report a partner sent over, and one-off checks during an active incident. For most brands that is tens to low hundreds of lookups a day rather than thousands, because the bulk pattern-matching happens against the downloaded file at no per-query cost at all. lookups reset monthly, so a package sized against an annual estimate does not evaporate at the end of a quarter because one month was quiet.
If you also want a nightly batch pass over a permutation set, the arithmetic is one credit per domain and a hundred domains per request. Ten thousand candidate strings checked every night is roughly 300,000 lookups a month, which is a different order of magnitude entirely and argues strongly for doing the matching against the feed and reserving the batch endpoint for the subset your sweep already flagged as interesting.
| Package | Price | Credits | Per lookup |
|---|---|---|---|
| Starter | $59 | 10,000 | $0.0040 |
| Growth | $99 | 25,000 | $0.0040 |
| Professional | $249 | 100,000 | $0.0025 |
| Business | $499 | 250,000 | $0.0020 |
| Enterprise | $999 | 750,000 | $0.0013 |
Credits are bought outright through PayPal rather than subscribed to, and there is no per-seat licence on the API, so a three-person team and a thirty-person team pay the same for the same volume. The daily feed is a separate subscription because it is a genuinely different product — a bulk file rather than a metered service. Full details sit on the pricing page, and the daily feed page covers the file format and the changelog.
A known-bad list is a floor under the problem rather than a perimeter around it, and a programme that pretends otherwise will be surprised.
This database contains hosts confirmed to be serving phishing and confirmed to be resolving. A domain infringing your mark while hosting a parking page, a competitor's advertising, or nothing at all will never appear in it. If your remit includes defending the mark itself as well as protecting customers from credential theft, you need registry monitoring alongside this and you should not expect either product to cover the other's ground.
A domain registered this morning, weaponised at lunchtime and abandoned by evening may never appear in a daily build at all, and no list rebuilt on a fixed cycle will catch a campaign whose entire lifespan is shorter than the cycle. Fast-rotating infrastructure is a real technique and this data will lag it. What the daily rebuild guarantees instead is that the entries which are present are current rather than historical — that is the trade being made, deliberately, and it is the trade that makes the list useful for takedowns.
A cloned checkout page whose hostname contains none of your brand strings will only be found by a match on the host itself, which means it has to have been detected as phishing by some route other than your string list. Customer reports, referrer anomalies in your own analytics and payment-processor signals remain irreplaceable inputs; the feed complements them rather than replacing them. The same applies to impersonation that never touches a website at all — profiles, messaging accounts, app-store listings and paid search placements are separate problems with separate remedies, several of which are covered on our social media and online marketplaces pages.
Your evidence capture, your own judgement about what the page is doing, and where relevant your counsel's view are what turn a row in a file into a request somebody will act on. The data does one specific job well: it tells you every day which of the hosts wearing your name are actually up. What you do with the hours that saves is the part that removes them.
Pairs with registry monitoring. Use registration and certificate-log alerting for early warning, then use this feed to decide which of those warnings became live infrastructure worth a takedown.
Pairs with your own telemetry. Referrer strings, chargeback records and support tickets surface the clones that carry no brand string, and those hostnames can be checked directly through the API.
Related work sits nearby. Abuse desks see the same domains from the other side — see domain registrars and hosting providers.
Downstream teams benefit too. The same list feeds the workflows described on our incident response and threat intelligence pages.
The seven that come up in nearly every evaluation, answered without hedging.
Most brand monitoring products are built on registry and certificate data, which makes them excellent at telling you a name appeared and weak at telling you whether anything is being served from it. That gap is exactly where analyst hours disappear. This database answers the second question directly, because every entry has been confirmed as serving phishing and confirmed as resolving at build time.
The database stores hostnames as they resolve, which means internationalised domains appear in punycode form. Your matching pass therefore has to generate the punycode representations of your brand's plausible homoglyph variants and search for those alongside the plain Latin strings. That is a few lines of code with any IDNA library, and it is the single most commonly omitted step in a brand string set.
A domain that renders identically to your brand in a customer's address bar will be sitting in the feed while your sweep walks straight past it, because the two strings share almost no characters once encoded.
Yes, and you should. Because the matching runs locally against a file you have already downloaded, adding a term costs nothing, so there is no budget reason to keep the string set small. Surnames of anyone who can authorise a payment, initials-plus-company constructions, and the words that appear in your internal approval workflows are all worth including.
Treat the platform as the recipient and never the registrar. The registrable domain belongs to a legitimate business, so a registry-level action would be disproportionate and refused, and asking for one costs you credibility with the abuse desk you actually need. Send the specific fully-qualified hostname, the capture, and a request to remove that subdomain or its content.
If you push feed matches into a DNS blocklist for your own staff, blocking the registrable domain would break a service your colleagues and customers use. Block the full hostname or block nothing.
No, and it matters not to present it as though it does. A match proves the host was verified as serving phishing and verified as resolving. Whether a particular use of your mark meets the legal test for infringement in a given jurisdiction is a question for counsel, and it turns on facts the feed does not contain, such as the registrant's identity and intent.
It stops resolving, and at the next daily rebuild it is dropped from the database rather than retained with a historical flag. The removal is recorded in the changelog that accompanies the build, which is what lets you close a ticket with a dated reference instead of re-testing the host manually.
Yes for your own corporate estate. The file format suits DNS resolvers, firewalls and SIEM enrichment, so the same download that drives your brand sweep can also stop your own staff reaching those domains. That is a sensible second use of a subscription you are already paying for.
They are on their own networks and cannot be reached by your controls. Customer-side protection comes from getting the host removed and, where you operate an app or a portal, from checking outbound links server-side before you render them. That pattern is documented on the API documentation page.
Pull the rebuilt database each morning, sweep it against the names you protect, and spend your takedown hours on the domains answering queries today rather than on a permutation list nobody could ever work through.
