# EmailHarvester pulls public addresses out of search result pages

> EmailHarvester is a small Python tool that collects email addresses for a domain by querying search engines and by searching individual sites through those engines, then exports the result as text and XML. It is a reconnaissance tool rather than an exploit: everything it collects is already published in indexed pages, and the interesting engineering is in the plugin structure, the result limits and the fact that its last tagged release dates from 2016.

**maldevel/EmailHarvester** — Email addresses harvester

- Repository: https://github.com/maldevel/EmailHarvester
- Stars: 991 · Forks: 196
- Language: Python
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/maldevel-emailharvester

## What it actually collects, and where from

The tool's whole function is described in one line, a tool to retrieve domain email addresses from search engines. The mechanism is straightforward. You give it a domain, it issues search queries built around that domain, and it picks the addresses out of the result pages it gets back. The engines it knows are Google, Bing, Yahoo, Ask, Baidu, Dogpile and Exalead. There is a second mode on top of that, searching within popular sites through the search engines rather than the open web, with plugins for Twitter, LinkedIn, Google+, GitHub, Instagram, Reddit and YouTube. So the output is a list of addresses that were already published on indexed pages, not a guess of a naming pattern and not a breach of anything. The project says as much in its own description of the feature set, retrieve domain email addresses from popular search engines, and it credits its lineage to theHarvester and to a Rapid7 Metasploit auxiliary module, which is a fair description of the family it belongs to.

## The plugin system is where the work is

Engines and sites are implemented as plugins, and the repository has a `plugins/` directory for them, so adding a source is a matter of writing one more. The command line exposes that structure in three ways. The `-e` flag selects a single engine, and the value `all` runs every plugin that is not excluded. The `-r` flag excludes plugins, with the help text giving the example of excluding google and twitter, which is what you want when one source is slow or when you already have the addresses it would return. And `-p` lists all available plugins, so you can see what the build in front of you actually supports rather than guessing from the documentation. The design is a plugin per source with a common interface, and the practical consequence is that a site which starts blocking the request pattern can be replaced or dropped without touching the rest of the tool.

## A command line that has not moved since 2016

The usage text printed by the tool is worth reading, because it is a snapshot of the project. It reports version 1.3.2, and the help output is in the argparse style of that era, with optional arguments rather than the newer options wording. The flags are few and each does one thing. `-d` is the domain to search, `-e` the engine, `-l` a limit on the number of results, `-s` a file to save the results into as both text and XML, `-u` a custom User-Agent header, `-x` a proxy, and `--noprint` to suppress the output to the terminal. The proxy option is documented with the example of a local instance on port 8080. The examples section shows the same thing in use, one engine at a time, all engines, all engines with some excluded, a limited run, an export run, a custom user agent and a proxy run. Nothing here is exotic, and nothing has been packaged since 2016, which is the point of reading it: this is a tool whose interface has been stable for a decade because the underlying idea has not changed.

## Installing it is a clone and a pip install

The installation instructions are two lines, a git clone of the repository and a pip install of the requirements file. The requirements are four packages, termcolor, colorama, requests and validators, and the last of those is the one doing the actual work of deciding whether a scraped string is an address at all. Everything else is presentation or transport, which tells you how little of this tool is complicated. The Python version required is 3.x. There is a Docker route as well, and the image is Alpine based:

```bash
git clone https://github.com/maldevel/EmailHarvester
cd EmailHarvester
docker build -t EmailHarvester .
docker run -it EmailHarvester -d example.com
```

The Dockerfile is worth reading closely, because it does something slightly odd. The `COPY requirements.txt .` line is commented out, and the image clones the repository from GitHub inside the build instead, so the requirements file it installs is the one in the cloned tree rather than the one in your local checkout. If you are building from a modified copy, or from a branch, the image will not contain your changes. The rest of the file is conventional, a virtual environment, a pip install and an entry point of `python3 EmailHarvester.py` with `-h` as the default command.

## What limits the results, and what limits the tool

The `-l` flag caps the number of results, and that is the right control to reach for first, because the tool has no rate limiting, no politeness delay and no backoff. It sends its requests as fast as it can, and the two knobs for moderating that are the limit and the proxy. The user agent flag exists because search engines treat different clients differently, and the proxy flag lets you route through your own infrastructure, for example a local instance on port 8080, which is also the obvious way to keep the traffic on a network you control. The deeper limit is not technical. The tool can only report what has been indexed and made public, so a domain that has never been crawled, has a robots policy that excludes the paths holding addresses, or has been taken down since, will return little or nothing. The result is a lower bound on the public footprint, and a list that is only as current as the search engine's last crawl.

## The guide for newcomers, and what is not documented

The repository contains a `NoobGuide` directory, which tells you something about the project's audience, and it is worth opening before the code. What is not in the repository is a plugin author guide, and that is a real gap for anyone who wants to extend the tool, because the plugin interface has to be inferred from the existing plugins. There is also nothing about responsible use, and for a tool whose output is a list of personal addresses, that absence is more than a documentation nicety. The addresses are public, but the collection of them still has to fit the law of wherever you are, and the fact that a search engine indexed an address is not a licence to build a marketing list out of it. The tool itself is neutral on the question and provides no filtering, no rate limit and no logging, so the responsibility sits with whoever runs it.

## Maintenance state and what the licence means

The project is under the GPL-3.0, with the licence file in the repository root, which is a good fit for a tool you might want to modify and redistribute, subject to the copyleft obligations on derived versions. The release history is the part that will surprise you. The tagged releases are 1.3.2 from 2016-04-30, 1.3.1 from 2016-04-29 and 1.3.0 from 2016-04-23, three releases in eight days a decade ago, and the version string in the tool's own banner still says 1.3.2. The last push to the repository was on 2026-06-07, so the tree is not abandoned and something has changed since the last tag, but nothing has been packaged. If you pick this up, the sensible first step is to run it against an engine that still serves the page shape it expects, and the second is to look at what the plugins do now, since a decade of changes to search result markup is the most likely reason a source stops returning anything.

## Conclusion

EmailHarvester suits a security researcher gathering the public footprint of a domain before an assessment, since it gives a plain list of addresses from indexed pages with no guesswork about formats, and it suits a developer who wants a readable example of a small plugin driven command line tool. It is a poor fit if you need depth, because the tool only reads what search engines have indexed, and it is a poor fit for anything sustained, because the search engines it queries change their result pages and the tool has had no tagged release since 2016. Before you run it, check three things: the version you are using, with the help text still reporting 1.3.2 and the last push to the repository on 2026-06-07, that you have permission to collect the addresses you are collecting, since the addresses are public but the collection and the use of them are separate questions, and the terms of the search engines you are querying, since the tool sends its own requests with a user agent you can change.

## FAQ

### What does EmailHarvester do?

It retrieves email addresses for a domain from search engines, and it can also search within specific sites such as Twitter, LinkedIn, Google+, GitHub, Instagram, Reddit and YouTube through those engines. The addresses come from publicly indexed pages rather than from guessing patterns or from any breach.

### How do I install and run EmailHarvester?

Clone the repository and run `pip install -r requirements.txt`, which needs termcolor, colorama, requests and validators, then run the script with a domain, for example `./EmailHarvester.py -d example.com -e google`. A Docker route is documented too, using an Alpine based image built from the Dockerfile.

### Which search engines does EmailHarvester support?

Google, Bing, Yahoo, Ask, Baidu, Dogpile and Exalead, plus site specific plugins for Twitter, LinkedIn, Google+, GitHub, Instagram, Reddit and YouTube. The `-e all` option runs every plugin and `-r` excludes named ones, and `-p` lists the available plugins.

### Can EmailHarvester limit the number of results and use a proxy?

Yes. The `-l` flag limits the number of results, `-x` sets a proxy server, and `-u` sets a custom User-Agent request header. The tool has no built in rate limiting, so those flags and the limit are what you control.

### Is EmailHarvester still maintained?

Not in the sense of releases. The tagged versions are 1.3.2 from 2016-04-30, 1.3.1 from 2016-04-29 and 1.3.0 from 2016-04-23, and the version in the tool's own banner is still 1.3.2, though the last push to the repository was on 2026-06-07.

## Sources

- [Issues](https://github.com/maldevel/EmailHarvester/issues)
- [License: GPL-3.0](https://github.com/maldevel/EmailHarvester/blob/master/LICENSE)
- [maldevel/EmailHarvester on GitHub](https://github.com/maldevel/EmailHarvester)
- [README](https://github.com/maldevel/EmailHarvester/blob/master/README.md)
- [Releases](https://github.com/maldevel/EmailHarvester/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/maldevel-emailharvester