# Holehe Detection Methods Explained: How Modules Identify Email Accounts Across Services

> Discover Holehe detection methods: register login password recovery and other. Learn how modules identify email accounts across services for enhanced security.

- Repository: [Palenath/holehe](https://github.com/megadose/holehe)
- Tags: internals
- Published: 2026-08-30

---

**Holehe uses four distinct detection methods—`register`, `login`, `password recovery`, and `other`—to determine whether an email address is associated with a web service.**

The open-source **Holehe** tool by **megadose/holehe** performs distributed reconnaissance to check if an email address exists on hundreds of services. Each module declares its **detection method** as metadata, categorizing how the service validates email presence. Understanding these methods helps security researchers interpret results and debug modules.

## Overview of Holehe Detection Methods

Every module in `holehe/modules/` defines a `method` variable at the top of the file. This string serves as descriptive metadata that appears in output reports. The core runner in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) executes all detection functions regardless of method type—the classification merely helps users understand *how* the verification occurred.

| Method | Purpose | Typical Use Case |
|--------|---------|----------------|
| `register` | Tests registration endpoints to see if email is already taken | Services that block duplicate sign-ups |
| `login` | Probes login forms or endpoints for email recognition | Services with exposed username/email validation |
| `password recovery` | Triggers password reset flows to confirm email exists | Services where recovery reveals account presence |
| `other` | Custom or non-standard verification techniques | Services with unique APIs or anti-bot measures |

## The `register` Detection Method

The **`register`** method is the most common in the Holehe codebase. Modules with this method query registration endpoints to determine if an email address is already associated with an existing account.

In [`holehe/modules/music/spotify.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/music/spotify.py):

```python

# holehe/modules/music/spotify.py

method = "register"

```

This indicates the Spotify module attempts to sign up with the target email and interprets "email already registered" responses as a positive hit. Other `register` modules include `google`, `amazon`, and `reddit`—any service where registration attempts leak account existence through error messages or response codes.

The `google` module in [`holehe/modules/mails/google.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/mails/google.py) demonstrates a more complex `register` flow with additional request handling and rate-limit management.

## The `login` Detection Method

The **`login`** method probes login-related endpoints to check if a service recognizes the email address. This often involves submitting the email to a login form and analyzing the response.

Modules using this method include:

- `anydo`
- `flickr`
- `hubspot`
- `wordpress`
- `yahoo` (in [`holehe/modules/mails/yahoo.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/mails/yahoo.py))

The Yahoo module exemplifies this approach by submitting the email to Yahoo's login validation endpoint and parsing whether the system prompts for a password (account exists) or reports "account not found."

## The `password recovery` Detection Method

The **`password recovery`** method initiates password reset flows to confirm email association. This technique is especially useful when registration and login endpoints are hardened against enumeration.

The `mail_ru` module in [`holehe/modules/mails/mail_ru.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/mails/mail_ru.py) implements this method:

```python

# holehe/modules/mails/mail_ru.py

method = "password recovery"

```

By triggering Mail.ru's password recovery and checking whether the email receives a reset link or the service reports "no account found," the module reliably determines account existence without attempting authentication.

## The `other` Detection Method

The **`other`** category captures custom or non-standard detection techniques that don't fit the three primary patterns. These modules often use proprietary APIs, unusual request sequences, or service-specific behaviors.

Notable examples:

- **`protonmail`** ([`holehe/modules/mails/protonmail.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/mails/protonmail.py)): Uses ProtonMail's internal API endpoints for email validation
- **`duolingo`**: Implements custom checks against Duolingo's user lookup system

These modules require individualized analysis of each service's behavior rather than following a reusable pattern.

## How Detection Methods Execute in the Core Runner

The execution flow in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) processes all modules uniformly:

```python

# Simplified from holehe/core.py

async def launch_module(module, client, email):
    # Extract the detection function and metadata

    method = getattr(module, 'method', 'unknown')
    result = await module.run(client, email)
    return {
        'service': module.__name__,
        'method': method,
        'result': result
    }

```

The core imports every submodule dynamically, extracts the `method` string for reporting, and executes the module's `run()` function asynchronously. Detection method classification does not affect execution logic—it purely enhances result interpretation.

## Running Holehe and Reading Detection Method Output

Execute Holehe from the command line:

```bash
$ holehe alice@example.com

```

Typical output shows the detection method implicitly through the module's behavior:

```

[+] spotify.com          # register → address registered

[-] amazon.com           # register → address not used

[+] flickr.com           # login → address recognized

[+] mail.ru              # password recovery → address found

```

To inspect a module's detection method programmatically:

```python
>>> from holehe.modules.music import spotify
>>> print(spotify.method)
'register'
>>> print(spotify.__doc__)

```

## Key Files and Module References

| File | Description |
|------|-------------|
| [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) | Core runner importing submodules and executing detection functions |
| [`holehe/modules/music/spotify.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/music/spotify.py) | `register` method implementation |
| [`holehe/modules/mails/google.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/mails/google.py) | Complex `register` method with rate handling |
| [`holehe/modules/mails/mail_ru.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/mails/mail_ru.py) | `password recovery` method example |
| [`holehe/modules/mails/protonmail.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/mails/protonmail.py) | `other` method with custom API usage |
| [`holehe/modules/mails/yahoo.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/mails/yahoo.py) | `login` method demonstration |

## Summary

- **Four detection methods** categorize Holehe modules: `register`, `login`, `password recovery`, and `other`
- **Metadata-driven classification**: The `method` variable in each module provides context without affecting execution
- **Core runner uniformity**: [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) executes all modules the same way regardless of detection type
- **Most common pattern**: `register` dominates the codebase for services that leak account existence during signup
- **Evasive techniques**: `password recovery` and `other` handle hardened services where standard methods fail

## Frequently Asked Questions

### How do I add a new detection method to Holehe?

Holehe does not require registering new detection methods in a central registry. Simply set `method = "your_custom_type"` in your module, and the core runner will include it in output reports. The string is purely descriptive—execution logic depends entirely on your module's `run()` function implementation.

### Why doesn't Holehe use only one detection method for all services?

Different services expose email validation through different vulnerabilities. Some leak information during registration, others during login, and hardened services require password recovery flows. The variety of **Holehe detection methods** ensures comprehensive coverage across diverse service architectures.

### Can detection methods be combined in a single module?

Each module declares exactly one `method` value. However, a module's internal `run()` function can implement hybrid approaches—performing multiple request types and aggregating results. The single method declaration simply indicates the primary categorization for reporting purposes.

### Where can I find examples of each detection method in the source code?

According to the **megadose/holehe** source code: `register` examples appear in [`spotify.py`](https://github.com/megadose/holehe/blob/main/spotify.py) and [`google.py`](https://github.com/megadose/holehe/blob/main/google.py); `login` in [`yahoo.py`](https://github.com/megadose/holehe/blob/main/yahoo.py); `password recovery` in [`mail_ru.py`](https://github.com/megadose/holehe/blob/main/mail_ru.py); and `other` in [`protonmail.py`](https://github.com/megadose/holehe/blob/main/protonmail.py). grep the modules directory for `method = "` to discover all implementations.