theHarvester Tutorial 2026: OSINT Email, Subdomain & Domain Recon

Recent releases classify every data source into a capability tier so you always know whether a run touches the target. Understanding these three tiers is the single most important concept for using the tool safely on an engagement.

A single run against a mid-size organisation typically returns hundreds of artifacts. Each is deduplicated and tagged with the source that produced it, so you can weight confidence.

• 1Emails — harvested from search engines, PGP key servers and breach/OSINT feeds; the seed list for password spraying tests and phishing-resistance reviews.
• 2Subdomains & hosts — the backbone of external attack-surface mapping, largely from Certificate Transparency (crt.sh, certspotter).
• 3IP addresses & ASNs — netblocks that anchor further scanning scope.
• 4Employee names — feed username-convention guessing (e.g. first.last@).
• 5Open ports & banners — when Shodan/Censys keys are configured, without you scanning anything.

theHarvester is not just an attacker tool. The same output is a defender's external-exposure inventory — the shadow subdomains, forgotten dev hosts and leaked mailboxes an attacker would build their target package from.

Attack Surface Discovery

Enumerate every subdomain in Certificate Transparency to find the staging box nobody decommissioned.

Phishing Exposure

See which employee mailboxes are already public before an attacker builds a target list from them.

Recon Pipelines

Feed JSON output straight into amass, httpx and nmap for a full external-assessment chain.

Continuous Monitoring

Schedule runs and diff results to catch new exposed hosts the moment they appear.

uv is a fast Rust-based Python package/venv manager. It creates an isolated environment from the project lockfile so you get the exact dependency set the maintainers tested — the most reliable way to avoid the dependency-hell issues older pip installs were famous for.

Three commands take you from nothing to a working install. uv sync reads pyproject.toml / uv.lock, provisions the pinned Python, creates a .venv, and installs every dependency.

Run a tiny passive query against a domain you control. If Certificate Transparency subdomains come back, the toolchain is healthy.

Source modules break constantly as upstream sites change their markup or rate limits. Update often — a subdomain source that worked last month may silently return nothing today.

Clone the repo and build from the bundled Dockerfile. This bakes the pinned dependency set into an image so every teammate runs identical code.

Mount a host directory for output and pass CLI arguments straight through. The container is disposable; only the mounted results survive.

To run theHarvester as a persistent service — the REST API and HarvestView UI — use a Compose file. This runs as a non-root user, persists the run database in a named volume, and reads provider keys from a mounted secret file so credentials never live in the image.

Confirm it's present and current. If missing, the metapackage pulls it in.

If you don't want the uv workflow but still want an isolated, PATH-linked binary, install straight from the Git repository with pipx. This is ideal on a non-Kali analyst workstation.

Run three free P0 sources against a domain and cap results generously. This is the safe "hello world" of external recon.

Results stream to the terminal grouped by artifact type. A typical tail looks like this (values illustrative):

The -f flag writes structured output for later parsing. Modern builds emit JSON (grouped by type) and a JSONL stream where the first line is run metadata and each following line is a deduplicated finding with provenance. Runs are also retained in a local SQLite stash.

Keys are read from a YAML file in your home directory. Copy the template from the repo, then fill in the providers you have. System-wide paths (/etc/theHarvester/) also work for shared installs.

You do not need all 60. These are the high-value sources per artifact type; the free tiers are enough for most assessments.

Once keys are set, chain the sources that complement each other — CT logs for subdomains, Hunter for emails, Shodan for exposed services — in a single command.

Combine search-engine and email-specialist sources. The output seeds username-convention analysis and phishing-resistance reviews.

CT logs are the single richest passive subdomain source — every TLS certificate ever issued for the domain is public record. crt.sh and certspotter mine exactly that.

Add -r to resolve every discovered hostname. Now you have host-to-IP mappings — the input to netblock scoping and Shodan/Censys pivots.

-c brute-forces subdomains from a wordlist; -n runs reverse DNS across the resolved ranges to catch hosts that share a netblock. These touch DNS (not the target's web tier), so confirm scope covers active DNS queries.

-t checks discovered subdomains for dangling CNAMEs pointing at deprovisioned cloud services — the classic subdomain-takeover condition. This makes direct HTTP contact, so it is a P2 active check.

The --screenshot flag captures every reachable host to an output directory — a fast visual triage of what's exposed, from forgotten admin panels to default install pages.

Big estates need higher limits and more concurrency. Raise the per-source cap and the worker count, but back off if sources start rate-limiting you (HTTP 429).

HarvestView is a local browser interface for running, scheduling and reviewing harvests, and for tracking when a target's hostnames change between runs. It binds to localhost.

The API authenticates with an operator key sent in the X-API-Key header. Submit a run, poll for completion, then export JSONL — the pattern for wiring theHarvester into any orchestrator.

theHarvester is the front of the funnel. Extract its hostnames with jq, then feed live-host probing (httpx) and port scanning (nmap) — the standard external-assessment pipeline.

Scheduled Harvests

HarvestView schedules recurring runs so exposure data is never stale.

Hostname Diffing

Change-tracking flags new or removed hosts between runs automatically.

Pipeline Front-End

JSONL feeds amass, httpx, nuclei and nmap for a full assessment chain.

Run theHarvester against yourself on a schedule and treat the output as a to-do list. You cannot stop CT logging, but you can control what it reveals.

• 1Decommission dangling DNS records for hosts that no longer exist — kills both stale CT hits and takeover risk.
• 2Use wildcard certs sparingly on internal names so pre-prod hostnames don't leak into CT.
• 3Replace public role mailboxes with contact forms where practical to cut harvested emails.
• 4Enforce phishing-resistant MFA so a harvested-email spray has nowhere to land.

The -c brute-force stage produces a spike of failed DNS lookups (NXDOMAIN) for non-existent subdomains from a single source in a short window. Both queries below alert on that burst.

The P2 stages (-t, --screenshot, or a downstream httpx sweep) touch many of your hosts from one source in a short window. Web/WAF logs show one client hitting a large number of distinct hostnames.

Most theHarvester problems are source-side (rate limits, markup changes, missing keys), not bugs in the tool. This table covers the ones you will hit.