Research Methodology
How does Interisle identify abusive domain names?
We begin with data from prominent Reputation Block Lists (RBLs). These contain domain names and/or the URLs of known phishing pages, malware, and web pages that host dangerous or unwanted content. The RBLs we use are provided by professional security threat-reporting sources, and are used to protect billions of user accounts across the world. These providers continually add and remove domains and URLs from these lists, according to their own criteria.
RBLs are widely used as a defense measure. Internet service providers, email providers, Web browser providers, DNS resolvers, and other organizations use these RBLs to block access to (and traffic and email from) these domains and URLs, protecting their users from online threats. Pretty much every user of the Internet is protected by RBLs, including the users of corporate and university networks, ISPs, and public wifi networks and DNS resolvers. Web browsers such as Chrome, Safari, and Edge use reputation blocklists to prevent users from visiting malicious sites. Most e-mail providers use blocklists to protect email accounts.
This data provides a practical measurement of what is happening in the “real world,” the Internet ecosystem that uses the DNS. It shows what domain names are being blocked—the domains that professional anti-abuse sources have identified as harmful, and what domains are being blocked by security administrators at private and public networks and services around the world. Interisle uses this data to identify abusive domain registration and usage trends, such as what hosting providers, registrars, and services are most heavily used and exploited by cybercriminals.
ICANN takes a similar approach with its Metrica abuse measurement system. ICANN notes: “We believe that it is beneficial to collect the same DNS abuse data that is reported to industry and Internet users. Security systems such as anti-spam or anti-malware gateways or firewalls that protect billions of users incorporate these data into their DNS abuse mitigation measures. Domain Metrica thus reflects how the users and network operations communities see the domain name ecosystem through the lens of reported DNS abuse data.” https://www.icann.org/octo-ssr/metrica/faqs-en
What blocklists does Interisle use?
The APWG phishing feed (phishing; high-confidence only), OpenPhish (phishing), PhishTank (phishing; confirmed phishing only), Spamhaus DBL (malware, phishing, and other (untagged) malicious/risky domains), SURBL (malware, phishing, botnet C&C, and other (untagged) malicious/risky domains), URLHaus (malware), and Malware Patrol (malware). Each provider describes the general details of their processes.
How does Interisle choose what blocklists to use?
The blocklist providers we use meet important criteria including very low false-positive rates, coverage of relevant kinds of abuse, and wide adoption by companies, governments, and academia. Each RBL also provides a review or appeal process and the ability to redress false-positives. Academic literature and the extent of commercial use indicate that the false-positive rates are quite low among the lists we have chosen.
Our choices of blocklists, and how we use them, follow the considerations described in the “RBL Evaluation Methodology” paper by ICANN’s Office of the CTO, which is a useful guide.
We use more blocklists than some other organizations do. There is usually only a small overlap between the domains that one blocklistlist finds versus another. By using more feeds, we gain a better, more comprehensive understanding of what’s happening out on the Internet. For more about this, see below.
Does Interisle’s system find all instances of abuse?
No. The blocklist providers we use do not claim to detect or list all the abusive activity happening on the Internet. The data we have is only a subset of the abuse problem. Our numbers are a floor, and the number of domain names being used for abusive purposes is higher. We have found that our data provides reliable indicators of trends, and of where abuse is concentrated.
What other data does Interisle collect?
We gather data that gives context to blocklist data, and helps us understand where abuse is taking place. All of this data is publicly available. Among other things, we collect:
DNS query data. This tells us things such as what IP address a domain is on, and what nameservers a domain name is using.
Domain registration data. This is the authoritative information about when a domain name was registered, the name of the registrar and its IANA ID number, the domain’s contact data, and more. We collect it from domain registries and registrars using RDAP and WHOIS.
gTLD zone files
Passive DNS to find the “first observed “ dates of domains.
Feed-specific metadata. Some of our feeds provide additional information, such as the type of abuse a domain or IP address is associated with, the brand that is impersonated in a phishing attack, or a malware family or type.
How does Interisle count the data?
Blocklist providers continually add and remove domains and URLs from their lists, according to their own criteria. Our collection system collects updated data from each blocklist provider several times per day, and de-duplicates domain names (both within a list and across lists) as part of processing.
Some blocklists provide URLs. We only count a domain name once, irrespective of how many host names or URLs have been reported on that domain name.
A domain name that we extract from any blocklist will cause the domain name to be counted only once when we calculate unique domain abuse totals.
If a domain is listed for two or more types of abuse, that domain will be counted (again, once) in each relevant abuse category. For example, if one blocklist identifies a domain name as a malware domain and a second identifies that domain as a phishing domain, and that domain was not listed before, then:
The total unique domain count is increased by one,
The cumulative abuse count is increased by one,
The malware domain count is increased by one, and
The phishing domain count is increased by one.
Only unique domains are counted toward the total reported DNS abuse counts in a TLD or registrar portfolio.
Subdomain providers offer third-level domains, such as example.web.app, and many such third-level domains are used for phishing and other malicious activities. However, we count only the second level domain (web.app), and once only, when reporting domain totals for a TLD or registrar portfolio.
Some RBL providers add a domain to the blocklist and then remove it from the blocklist after a certain time, sometimes because the domain was suspended. In this report, Interisle counts how many and which domains were added to the lists, i.e. how many domains were identified as problems. We do count a domain for only the time period in which it waspresent on the blocklist.
How does Interisle determine the number of domains in a TLD or at a registrar?
We determine the numbers in each gTLD, and sponsored by each registrar, using domain counts from ICANN’s official registry reports. Interisle uses registrar IANA ID numbers to distinguish registrars.
ICANN and the NetBeacon Institute (services provided by KOR Labs) use the number of domain names found in zone files. Zone files always contain fewer domains than the registry itself, sometimes by 6% or more, because expired domains pending deletion are removed from the zone file. Domains suspended for abuse by registrars and registries (via ClientHold and ServerHold) are also removed from the zone file. This can increase the difference between domains-in-registry and domains-in-zone.
Verisign tends to report the number of domains in the .COM and .NET registries, which it operates. Otherwise Verisign uses zone file size to calculate gTLD renewal rates for the other TLD publishes in its Domain Name Industry Brief reports and gTLD registration and renewal trend dashboards.
The above differences can affect the numbers reported by various organizations, and can affect domain abuse scoring of registrars and TLDs. For example, for December 2025, Verisign reported 161 million domains in .COM in its industry brief, but 164.6 million in its ICANN registry report.
How does Interisle calculate renewal rates?
We use the registration numbers in the official monthly ICANN registry reports to calculate renewal rates. Those reports contain:
the number of domains in each gTLD registry at the end of each month, and
how many domains were sponsored (DUM, or “domains under management”), registered (created), renewed, and deleted by each registrar in each gTLD each month.
We use industry-standard methods to calculate the following:
New Registrations: The number of domain names added (Created) in a gTLD during a selected period. In the ICANN reports these are called net-adds. This includes domains created for more than a one-year term. We do not count domains added and then deleted in the Add Grace Period.
Renewals: The number of domain names in a selected period that were renewed (for any length of time). In the ICANN reports these are called net-renews.
Renewal rate: The percentage of domain names renewed during the selected time period. This is calculated as the number of domain names that are renewed divided by the number of domains that were eligible for renewal (which is the number of domains created one year prior (net-adds), plus the number of domains renewed one year prior). Rates are calculated with the simplifying assumption that all domain names expire and are eligible to renew each year. Multi-year registrations can cause the renewal percentage to be very slightly overstated. The number of Restored domains is negligible, and so we have ignored that effect.
Two other factors can make our renewal rate calculations vary slightly from those published by other sources:
Renewal rates are not fully measurable until 45 days after the end of a reporting period, and that factor is not reflected specifically in the ICANN reports. (Registries have the detailed information about exactly which domains were deleted in the 45-day Autorenew Grace Period.) This factor may make our renewal rate calculations turn out slightly lower than what a registry later reports publicly.
Instead of domains in the registry (which is what the ICANN reports contain), some parties use zone file size as a proxy for the size of the TLD. As noted above, zone files always contain fewer domains than the registry contains.
How does Interisle determine if a domain has been “maliciously registered”?
A malicious registration is a domain name that we determined was registered by a bad actor, for the purpose of carrying out malicious activity. A compromised domain is owned by a legitimate registrant, but a criminal has taken control of it by hacking or account compromise in order to carry out malicious activity. Distinguishing between the two is important. By identifying malicious registrations, we can see where and how criminals purchase domain names. Also, malicious registrations can be safely suspended by a domain name registry operator or registrar – the suspension will not harm anyone but the criminal. In contrast, suspending a compromised domain can harm legitimate users, preventing the innocent registrant’s web site and email from functioning. Those cases should be reported to the hosting provider and the registrant, who can secure the account and remove the harmful activity at the source.
We use multiple criteria to determine if a domain flagged by a blocklist has been maliciously registered. The most important are:
Domain age. We look at the number of days between the domain’s registration date and the time the domain was blocklisted. (Or if registration date is not available via RDAP or WHOIS, the time between the domain was firstobserved in a passive DNS query and when the domain is blocklisted.) We consider domains blocklisted within 90 days of registration to be malicious. Studies indicate that such domains are usually too new to have been compromised, and that a high percentage of maliciously registered phishing domains tend to be used within days of registration. This method excludes some maliciously registered domains that are “aged” by bad actors (by not using them for more than 90 days) in an attempt to improve domain reputation. Other researchers have considered domains as malicious if they were blocklisted within a longer 150-day period after registration.
The composition of the domain name. We search listed domains for tell-tale strings that indicate malicious use. These include strings designed to mislead users (login, security, etc.), and brand names that are the targets of phishing attacks (citibank, whatsapp, etc.). We also search for close misspellings and variations of these terms, which criminals often register to evade simple matching measures. Our tell-tale strings lists include strings that we have "observed in the wild,” i.e. seen used in confirmed attacks.
We look for clear evidence of common control and usage, such as batches of domains registered at the same time at the same registrar, delegated to the same nameserver pair, and for algorithmically generated domain names that follow patterns, such as sequences of numbers and letters. (See “bulk registrations” below.)
These methods share similarities with those used by other researchers, such as the COMAR and MalCom methods used by KOR Labs, the service provider to the NetBeacon Institute. Their and our calculations for malicious phishing registrations have historically been within a few percentage points of each other.
How does Interisle define malicious “bulk registrations”?
We define a set of domains to be bulk registered if the domains were blocklisted and at least ten domains were registered through the same registrar with no more than ten minutes between consecutive registrations. Domains within these sets usually share lexical/string characteristics, and the same nameserver set (registrar-nameserver combination), and we confirm the presence of those features for large batches. The domains in a bulk set are usually in the same gTLD, but sometimes bad actors register domains across several TLDs at the same time.
Our method under-counts the size and occurrence of bulk registrations, because it counts only domains that were blocklisted. There may have been more registered domains in the bulk set, but the blocklist providers did not list them all.Our method also fails to capture smaller (lower volume) batch registrations, and those spaced out over longer time periods.
Note that bulk registrations and the concept of associated domain checks under policy-making consideration at ICANN are two related concepts. The domains in a bulk registration set are by definition related to each other and were presumably registered by the same party. A competently performed associated domain check by the registrar should uncover all the domains in a bulk set we identified, plus perhaps others.
In research about malicious bulk registrations and associated domain discovery, researchers in ICANN’s Office of the CTO found that “batch registrations are prevalent, significantly predict overall abuse rates, and are useful for pivoting and expanding from known malicious ‘seed’ domain sets.”
Why are some domains blocklisted without a specific abuse type? What is a “spam” domain?
RBLs such SURBL and Spamhaus list domains that are used for a variety of abusive purposes. These domains get listed because the RBL provider finds them risky and worthy of blocking. Some of the domains on these RBLs are not tagged with a specific abuse type, as explained above. Since some of those undifferentiated domains were found in spam messages, and since that RBL may be used to filter email, some people colloquially call these “spam domains.”
However, “spam domains” is an often inapt term, and doesn’t explain why some domains are a problem and why they get blocklisted. Some of these “spam domains” are actually scam and fraud domains.
Spam has been traditionally defined as “bulk, unsolicited email messages.” With a few exceptions, the sending of bulk, unsolicited email messages violates the law in many countries. However, there are two even bigger problems.
First, most spam messages are sent via criminal and duplicitous means: via botnets, via hijacked IP space, and using fictitious (forged) business names and identities to obtain hosting and sending resources. Reputable senders follow best practices, do not send unsolicited messages, do not have their domains blocklisted, and do not advertise harmful content.
Second, domains that are advertised in unsolicited bulk email are used for various criminal purposes. Blocklist providers such as SURBL and Spamhaus find some malicious domain names by examining what is advertised in the body of spam messages. These are the destinations that spammers want potential victims to go to. Here spam is a delivery method, not the abuse being advertised. “Spam” therefore does not always describe why these domains are problems and get blocklisted. The Budapest Convention on Cybercrime (the major international treaty designed to address Internet crime) produced a guide to illustrate the multi-functional criminal use of spam.
It is a misconception that blocklist providers such as Spamhaus and SURBL focus entirely on spam, either as the primary detection method, or that they curate their lists to be used for email filtering exclusively. Rather, they focus on whether a domain may be malicious or risky, and their lists are used in a variety of protective systems. When describing whether to list a domain, Spamhaus uses this general methodology.
Some domains found by scanning spam messages are used to perpetrate scams and frauds – investment and cryptocurrency scams, romance and “pig butchering” scams, fake shops, scam casinos, advance fee fraud, and more. These types of frauds and scams resulted in the majority of cybercrime financial losses suffered in 2025. Other blocklisted domains are used to operate other types of fraud, such as illegal pharmaceutical sites and counterfeit product sales. These various scam, fraud, and abuse domains are detected by various methods in addition to email scanning.
Blocklist providers presently do not tag domain listings with specific “fraud and scam” abuse types, due to a lack of an industry-standard taxonomy, because of the diversity and wide-ranging nature of scams and frauds, and because of the challenges of making such classifications on the fly while processing large volumes of detections.
In the end, blocklist providers do not list all the domains they find in bulk unsolicited email. They list only those domains that they judge to be unacceptable risks to Internet users.
Interisle therefore counts domains as phishing or malware when a list is devoted exclusively to such an abuse type, or when a multi-abuse list such as SURBL or Spamhaus specifically tags domains for those abuse types. When looking at the overall use of domain names in this report, Interisle counts all of the domains that Spamhaus and SURBL list, such as when Interisle reports how many domains were blocklisted in a TLD for all kinds of abuse.
How do Interisle’s methods differ from those used by ICANN Metrica and the NetBeacon Institute?
The main differences are that:
Interisle uses more sources, consumes more data, and therefore becomes aware of more blocklisted domain names.
The organizations count and report some things differently.
These differences are important to understand, because different conclusions can be gained (or obscured) depending upon how the data is selected and presented.
All three organizations do some of the basics similarly. All three place an emphasis on feed trustworthiness and reliability, all three gather a range of associated data such as domain registration records, and all de-duplicate their lists to report about unique second-level domain names. They use some similar methods to determine which domains were maliciously registered versus compromised. To learn about their methodologies, please see: ICANN Metrica FAQ and the NetBeacon Institute methodology (provided by KOR Labs).
Here are the data sources that each organization uses, and how many domains each source listed over the course of a year:
INSERT RBL USE BY ORG TABLE HERE
There is some overlap in the domains that the above sources list. And each RBL lists some domains that are not found on any of the others.
Differences in Total Domains Identified
As illustrated above, NetBeacon uses far fewer sources than Interisle, and those sources list far fewer total domains than Interisle’s data sources. Interisle’s study set contains almost forty times as many domains as NetBeacon’s.
Interisle and ICANN Metrica use multiple sources to learn about each type of abuse. In contrast, NetBeacon uses three sources of phishing data, and only one source of malware data. Because NetBeacon uses fewer sources that detect far fewer domains, NetBeacon’s TLD and registrar domain counts and scores are significantly lower than Interisle’s and ICANN Metrica’s.
For example, for the November 2025 time period:
NetBeacon found 28,076 phishing domains, while Interisle found 299,369 – more than ten times as many.
NetBeacon reported that the .ICU TLD had 554 newly observed malicious domains (phishing + malware). Interisle found that .ICU had 8,683 new phishing domains alone in that period—more than 15 times what NetBeacon observed—plus additional domains flagged for malware and other problems.
Redactions and Transparency
NetBeacon redacts the names of some registrars and TLDs that have high levels of abuse. NetBeacon describes this choice as “a concept of consistency”: a TLD or registrar will only be listed if they appear in the top ten “for 4 or more of the last 6 months, otherwise they will be redacted.”
Interisle believes that such redactions are incompatible with studying the nature of domain abuse. It is common for spikes of abuse to occur when bad actors register domains in certain places, and for abuse to move between TLDs and registrars. As many researchers have documented, these spikes and movements often last less than four months, and some registrars display evidence of malicious batch registrations over short time periods only, as bad actors carry out malicious campaigns. Interisle therefore publishes unredacted statistics as a matter of transparency, and to reflect what happened where.
Differences Counting Abuse
ICANN Metrica subscribes to the SURBL and Spamhaus lists, but only counts a subset of the domains on those lists. Metrica counts only those domains that SURBL and Spamhaus specifically tag for phishing, malware, and botnet C&C. Metrica does not count domains that SURBL and Spamhaus do not specifically attribute to those abuse types. ICANN Metrica does not count those domains because ICANN’s contractual definition of DNS just encompasses malware, botnets, phishing, and domains used to send email advertising those, and the last category is not tagged or differentiated in the feeds.
When Interisle studies particular abuse types, Interisle counts domains as phishing or malware when SURBL or Spamhaus specifically tag domains for those abuse types. In this report, Interisle counts all of the domains that Spamhaus and SURBL list because the domains have been blocklisted as risky, and the destinations and delivery mechanisms are often interrelated and problematic.
Differences in Choices of What to Display
ICANN Metrica provides the number of domains that are currently on the blocklists that ICANN monitors, minus domains that are on the blocklists but do not appear in the zone file. This is meant to represent how many domains may be active threats on a given day.
Domains are being added to and removed from the blocklists each day. Metrica’s method tends to obscure that “churn” and does not give a picture of how many domains total are being listed over time. Also, certain providers keep domains on their blocklists for longer periods of time than others. ICANN Metrica can therefore tend to emphasize the effects of those blocklists, and can tend to show that abuse is in a steady state:
In contrast, Interisle might display the number of domains that are added to the blocklists in a given time period. This reveals spikes and lulls, and the cumulative number found over time. Here’s a chart for the same TLD (.info) and same time period as above:
