How to Use Findomain: The Beginner's Guide (First Install, First Scan, the Monitoring Lesson, and the Rate-Limit Rule)

CodexFuse Team · 2026-11-06T20:52:16.511Z · 20 min read min read

What Is Findomain, and What Does It Actually Do?

Learning how to use Findomain means learning to list the subdomains of a domain quickly, using public records instead of guessing names one by one. Findomain is a small open-source tool, written in Rust, that queries Certificate Transparency logs and 54 passive sources in parallel and prints the subdomains it finds. It calls itself the fastest and complete solution for domain recognition, and it also supports screenshots, port scanning, HTTP checks, subdomain monitoring, and alerts through Discord, Slack, and Telegram.

As of November 2026, this guide describes Findomain 10.0.1, the current release, published on 2025-07-28, and every step below was checked against it. The project is 2,764 days old, it holds 3,810 stars and 395 forks on GitHub, which works out to 9.65 stars per fork and a 10.37 percent fork ratio, and its last code push was three days before this guide. It is free open source under the GNU General Public License v3.0, with 13 open issues, or 0.34 open issues per 100 stars, and it gains about 1.38 stars per day.

CodexFuse offers no Findomain tool, and this guide teaches the open-source software itself. You will run it on your own machine, only against domains you own or are authorized to test, and this findomain tutorial keeps that rule in front of you throughout.

Think of it as a librarian for the public internet: instead of knocking on every possible door, it reads the public logs where certificates were already issued and asks the indexes that already track those names. The subdomain finder guide explains the whole job of finding subdomains, and this guide covers only one tool for that job, Findomain, from install to monitoring. If you would rather click than type, the subdomain scanner runs the same kind of check in your browser, with no install at all.

How Do You Install Findomain?

Install the prebuilt binary first, because Findomain ships as a single static file and needs no runtime, no database, and no shell plugin. Pick one row from the table for your system, run it, and confirm the install with findomain --help before you scan anything. The whole findomain install is one binary plus one confirmation command.

Pin every step below to Findomain 10.0.1, the latest release, published on 2025-07-28 and 467 days old at the time of writing. The install docs mention that releases before 11.0.0 used different Windows asset names, but no 11.0.0 release exists yet, so do not plan around it.

The best-known independent install guide, on dev.to, is 555 days old and predates 10.0.1, so it misses the current flags and still calls PostgreSQL essential for monitoring, which is no longer true. One route is deliberately missing from the table: cargo install findomain is not a current official install route, because the install docs list a source build with cargo build --release instead, so do not copy a cargo install line from a forum post.

Two things are worth installing alongside it. Google Chrome or Chromium is the prerequisite for the screenshotting feature, and PostgreSQL is needed only if you want monitoring to use it instead of the default SQLite file. The Docker beginner guide covers the container habit if the Docker route is the one you picked.

curl -LO https://github.com/findomain/findomain/releases/latest/download/findomain-linux.zip
unzip findomain-linux.zip
chmod +x findomain
sudo mv findomain /usr/bin/findomain
findomain --help

brew install findomain
findomain --help
docker pull edu4rdshl/findomain:latest
docker run --rm edu4rdshl/findomain:latest -t example.com

Your First Scan in Seven Steps

Run one scan against a domain you control, read what comes back, and save it. These seven steps are the whole beginner arc, and they take about five minutes once Findomain is installed. They use example.com as the placeholder target, so swap in your own domain before you run anything.

1. Confirm the install with findomain --help and check that it prints the 10.0.1 usage text.
2. Pick a domain you own and keep it as the target for the whole arc.
3. Run findomain -t example.com and watch the subdomains print as they are found.
4. Run the same scan with -r added, so only subdomains that actually resolve are shown.
5. Save the run with -o, which writes the results to a file named example.com.txt.
6. Add -i to the next run, so each subdomain is printed with its IP address.
7. Compare the two files and keep the resolved list as your starting inventory.

A first scan usually settles in about twenty seconds, because the sources are queried in parallel and the search lasts as long as its slowest source. If a run feels slow, the archive indexes are the usual cause, and the later sections show the knobs that bound them.

What Do the Results Mean, and Which Flags Change Them?

Every line Findomain prints is a subdomain name that a public source already recorded, not a guess and not a live check unless you ask for one. The plain run prints every name it finds, resolved or not, and the flags below decide what else you learn about each name. Read the flags once, then build your own default command from them.

findomain -t example.com -r -i --http-status -o

The default resolvers are Google, Cloudflare, and Quad9, and the --resolvers flag lets you point at your own list instead. A subdomain that does not resolve is not necessarily fake: it may be a stale record, a name that existed once, or a host that is down today. The -r flag exists for exactly that reason, and a beginner's inventory should start from the resolved list.

Wildcard detection runs by default, so a domain that answers for every name does not flood your results with invented hosts. The --no-wildcards flag turns that protection off, and there is no beginner reason to use it.

How Does Findomain Find Subdomains So Fast?

Findomain is fast because it never guesses names and never knocks on doors: it reads Certificate Transparency logs and queries 54 passive sources, all in parallel, and prints what they already know. Every source parses a documented data format, JSON in almost every case, and no HTML scraping happens anywhere, so a redesigned web page can never quietly turn results into noise. This is findomain subdomain enumeration in one sentence: public records, asked all at once.

The project's own old benchmark, run on a BlackArch virtual machine against aol.com, found 84,110 subdomains in 5.5 seconds, which works out to about 15,293 names per second. Treat that as the project's own historical claim, not a fresh measurement: it predates the current release, and your own runs will depend on your network and your target. The README also says resolution runs at about 3,500 subdomains per minute in good network conditions.

The search is passive by default, which means it touches no target server directly, but three features are active techniques: the brute-force wordlist mode, the port scanner, and screenshotting. Those three reach out to the target, so save them for runs covered by the rule in the first section.

The archive indexes are Wayback Machine, CommonCrawl, the UK Web Archive, and Arquivo, and they are the slowest sources by a wide margin. The docs warn that CommonCrawl alone spends over two minutes on google.com to return exactly the hostnames it already had after twenty seconds, so the archive budget is the knob that decides how long a run takes. Raise it if you would rather wait than miss what the archives hold on a small domain, or skip the archives entirely with --exclude-sources wayback,commoncrawl.

findomain -t example.com --exclude-sources wayback,commoncrawl
findomain -t example.com --archive-budget 60

How Do You Save, Filter, and Reuse Your Results?

The documented output is plain-text files, and that is enough for the whole beginner workflow. The -o flag writes a file named after the target, the -u flag writes to a name you choose, and the --query-database flag reads back what an earlier monitoring run stored. No JSON or CSV export flag appears in the 10.0.1 manual or the docs examples, so do not expect a structured export from this version.

Filtering happens before the file is written. The --filter flag keeps only subdomains containing a string, --exclude drops the ones containing it, and --exclude-sources drops whole sources from the search. A beginner's habit is to save the raw run, then save a filtered copy, so the original is never lost to a filter that was too eager.

Findomain also reads other tools' output, which is how you reuse work you already did. The --import-subdomains flag takes one or more files, one name per line, and merges those names with the ones Findomain finds itself, and the whole set goes through the same resolution and filtering. The what DNS is guide explains why some of those names resolve and others do not, which is the background this section assumes.

subfinder -d example.com -silent > subfinder.txt
amass enum -d example.com && amass subs -d example.com -names -show > amass.txt
findomain -t example.com --import-subdomains subfinder.txt amass.txt -r

How Does Findomain Monitoring Work?

Monitoring turns one scan into a watch: Findomain stores what it found, runs again later, and alerts you only about the new names. The -m flag activates monitoring mode, and the results are stored in a SQLite file called findomain.db in the working directory by default, so nothing has to be installed or running. The --sqlite flag puts that file somewhere else.

PostgreSQL is optional, not essential, and the current docs say so plainly: it is used as soon as the run names it, through any --postgres-* option or a postgres_connection line in the config file. The 555-day-old dev.to guide still calls it essential for monitoring, which was the old behavior and is one more reason that guide should not be your reference.

Alerts go out through webhooks to Discord, Slack, or Telegram, and the webhook addresses are set as environment variables so they never sit in a command. The docs suggest exporting them in your shell startup file, so they do not need typing on every run. The --aempty flag sends an alert even when no new subdomains were found, which is how you confirm the watch is alive rather than broken.

Findomain is not a scheduler, and the docs say so in bold: to run it automatically, pair it with cron, systemd timers, or the Windows Task Scheduler. A daily cron job at midnight is the usual setup, and the monitoring guide the docs link to uses exactly that. The watch itself needs a machine that stays on, so a small server is the usual home for it, and VPS hosting is the cheapest way to keep a daily scan running.

A commercial version with monitoring starts at 15 dollars a month as of early 2026, according to MetricTower. The current price could not be verified, because the project's own site would not load on the day this guide was written.

findomain_discord_webhook=https://discordapp.com/api/webhooks/YOUR_WEBHOOK_ID/YOUR_WEBHOOK_TOKEN findomain -m -t example.com

0 0 * * * /home/user/findomain/schedule/example-daily.sh

What Is the Rate-Limit Rule?

The rate-limit rule is simple: use your own tokens, leave the shared ones alone, and give the sources time. Sources marked with two stars in the docs require your own access token to work, and the docs warn that a shared token fails once too many people lean on it. The --list-keys flag shows every source that takes a key, the config key, and the environment variable, without ever printing the values.

The tool's own flag is --rate-limit, which sets the rate limit in seconds for each target during enumeration. The three budget knobs from the earlier section are the other half of the rule: a 30-second source timeout, a 300-second whole-search budget, and a 20-second archive budget keep one slow source from turning a twenty-second scan into a ten-minute one. Lower the budgets when you are in a hurry, and raise them when a small domain deserves a thorough pass.

The deeper rule is about the sources, not the flags. These are public indexes run by other people, and hammering them with unlimited parallel scans is how a free source becomes a closed one. One scan per target, your own tokens, and the defaults left alone is the habit that keeps the tool working for everyone.

findomain --list-keys
findomain -t example.com --rate-limit 2 --source-timeout 30

How Do You Combine Findomain With Other Tools?

No single enumerator finds everything, and Findomain is built to admit it. The --external-subdomains flag pulls in results from amass and subfinder, and --import-subdomains merges any file of names, one per line, with what Findomain finds itself. The --no-discover flag goes further: it stops Findomain from searching at all, so it only resolves, filters, and stores the names you imported.

A common pipeline is one passive tool for breadth, Findomain for speed and monitoring, and a resolver for liveness. The bug-bounty write-up that used Findomain piped its output straight into httpx, which is the usual next step: enumeration finds names, and the next tool checks which ones answer. Keep each tool's job separate, and the pipeline stays debuggable when a run comes back empty.

The 2026 best practice from the roundups is the same shape: start passive, combine tools and de-duplicate, verify liveness, and monitor continuously instead of scanning once. Findomain covers the passive start and the continuous watch, and the other tools cover the depth.

Findomain vs Amass: Which One Fits Your Job?

Amass is the deeper tool and Findomain is the faster one, and the choice depends on whether you need depth or speed. Amass is written in Go, it does passive and active enumeration, DNS brute-force, permutation scanning, zone transfers, and certificate scraping, and it carries a larger config surface and longer runs. Findomain is written in Rust, it is one static binary, it enumerates passively from Certificate Transparency logs and 54 APIs, and it adds built-in monitoring and alerts.

The only head-to-head measurement found is old: a February 2020 test found Findomain listing 270 subdomains in about 6 seconds, roughly 45 per second, while Amass found 489 in about 20 minutes, roughly 0.41 per second. Amass found 1.81 times as many names, so the trade was speed against coverage, and the test is 2,463 days old, so treat it as a dated single datapoint rather than a current benchmark. A 2026 roundup puts it the same way: running Subfinder and Amass together yields 30 to 50 percent more results than either alone.

The practical answer is to use both, and Findomain makes that easy: its --import-subdomains flag merges Amass output into a Findomain run, and its --external-subdomains flag pulls Amass and Subfinder results in directly. Start with Findomain for the fast first pass and the ongoing watch, and bring in Amass when a target deserves the deep, slow enumeration. The star gap tells the same story: Amass holds 11,665 more stars than Findomain, which is 4.06 times as many.

from datetime import date

ref = date(2026, 11, 7)
repo_age = (ref - date(2019, 4, 14)).days
release_age = (ref - date(2025, 7, 28)).days
stars_per_fork = 3810 / 395
fork_ratio = 395 / 3810 * 100
issues_per_100 = 13 / 3810 * 100
stars_per_day = 3810 / repo_age
benchmark_per_sec = 84110 / 5.5
amass_stars = 15475
star_gap = amass_stars - 3810
star_multiple = amass_stars / 3810
print(repo_age, release_age, round(stars_per_fork, 2), round(fork_ratio, 2), round(issues_per_100, 2), round(stars_per_day, 2), round(benchmark_per_sec, 0), star_gap, round(star_multiple, 2))
# Output: 2764 467 9.65 10.37 0.34 1.38 15293.0 11665 4.06

Seven Mistakes Beginners Make With Findomain

Most Findomain failures are habits, not bugs. The seven below are the ones beginners repeat, and each has a one-line fix.

Is Findomain the Right Tool for Bug Bounty Recon?

For bug bounty recon, Findomain is the right first tool and the wrong only tool. It is fast, it is free, and its monitoring mode watches your in-scope domains for new subdomains while you work on something else, which is exactly the job a bounty hunter repeats every day. The bug-bounty write-ups that mention it use it as the first step of a pipeline, piped into a liveness checker, not as the whole pipeline.

The rule from the first section still governs here: bounty programs define their scope in writing, and a subdomain outside that scope is out of bounds even if Findomain lists it. Stick to the program's scope, keep the monitoring on your in-scope domains, and let the tool's speed serve the hunt rather than widen it. That discipline is what separates a recon run from a policy violation.

Start with Findomain when you need a fast first pass, a saved inventory, and a watch that alerts you to new names. Bring in Amass or Subfinder when the scope is large and depth matters more than speed, and keep the merged list as your single source of truth. That is the whole findomain bug bounty habit: fast start, saved list, continuous watch, scoped targets.

Sources

Findomain on GitHub (Findomain/Findomain): 3,810 stars, 395 forks, 13 open issues, created 2019-04-14, last push 2026-11-04, GPL-3.0, latest release 10.0.1 published 2025-07-28. The project README (raw, 11,507 bytes) and the install docs (raw, 20,757 bytes) supplied the install routes, the 54-source list, the timing knobs, the monitoring setup, and the flag inventory. The man page for findomain 10.0.1 (July 2025, Arch Linux) supplied the flag definitions quoted in this guide.

The dev.to install guide by Stephano Kambeta was published 2025-05-01, which makes it 555 days old, and it predates 10.0.1, while the Kali Linux tools page for findomain was updated 2025-12-09. The greatheart.io enumeration guide covers Findomain as one section among other tools, and the readmedium.com mirror of the automated subdomain scanning guide covers the PostgreSQL and Discord webhook monitoring setup with cron scheduling. The MetricTower roundup, updated about 210 days ago, supplied the comparison framing and the early-2026 commercial price, and the February 2020 head-to-head by Ricardo Iramar supplied the dated speed-versus-coverage numbers.

Amass on GitHub (owasp-amass/amass): 15,475 stars, 2,203 forks, 251 open issues, created 2018-07-10, last push 2026-10-25, written in Go. The Arch Linux package page shows findomain 10.0.1-3 built on 2026-10-31, the FreeBSD port page shows the port at 9.0.4_25, updated 2026-10-14, and the cyb3rmind Medium bug-bounty write-up, 780 days old, shows Findomain piped into httpx in a real recon pipeline. The project's own site could not be loaded on the day this guide was written, so no fact in this guide comes from it.

Frequently Asked Questions

Is Findomain free?

Yes. Findomain is free open source under the GNU General Public License v3.0, and the binary costs nothing. A commercial version with monitoring exists, priced from 15 dollars a month as of early 2026 according to MetricTower, but the open-source tool itself is free.

What is the difference between Findomain and Amass?

Findomain is a fast passive enumerator: one Rust binary, Certificate Transparency logs and 54 APIs, plus built-in monitoring. Amass is a deeper tool: passive and active enumeration, brute-force, and permutation scanning, with longer runs and a larger config surface. Use Findomain for the fast first pass and the watch, and Amass when a target deserves depth.

How do I install Findomain on Linux?

Download the 10.0.1 Linux binary from the releases page, unzip it, make it executable, and move it to /usr/bin, then confirm with findomain --help. Kali users can run sudo apt install findomain, and Homebrew users can run brew install findomain.

Does Findomain monitor for new subdomains?

Yes. Run it with the -m flag and it stores results in a SQLite file by default, then alerts you through Discord, Slack, or Telegram webhooks when new names appear. Pair it with cron or a systemd timer, because Findomain is not a scheduler and will not re-run itself.

Is it legal to run Findomain against any domain?

No. Only run it against domains you own or inside a written scope, such as a bug-bounty program or a client engagement. Findomain is passive by default, but that does not make an unauthorized scan acceptable.