# Holehe Detection Strategies: How Modules Verify Account Existence

> Discover Holehe detection strategies for verifying account existence. Learn how modules use register, login, and password recovery methods to check email associations with online services.

- Repository: [Palenath/holehe](https://github.com/megadose/holehe)
- Tags: how-to-guide
- Published: 2026-09-10

---

**Holehe modules employ four distinct detection strategies—register, login, password recovery, and other—to determine whether an email address is associated with online services.**

Holehe is an open-source OSINT tool developed by megadose that checks if an email address is registered across hundreds of online platforms. Each service is implemented as a Python module under `holehe/modules/`, and every module specifies a **detection strategy** via the `method` variable. These Holehe detection strategies determine the technical approach used to verify account existence without requiring authentication credentials.

## Overview of Detection Methods

The repository defines four distinct values for the `method` variable. Each value represents a different technique for account enumeration:

- **register**: Queries email availability or registration validation APIs to check if an address is already claimed.
- **login**: Attempts partial authentication flows to determine if an account exists for the supplied credentials.
- **password recovery**: Triggers password reset workflows where the server's response indicates whether the email is recognized.
- **other**: Custom detection logic that does not fit the three standard categories, typically used for complex API integrations.

## How Detection Strategies Work in Practice

Each module is an asynchronous Python function located in the `holehe/modules/` directory. The function signature accepts `email`, `client`, and `out` parameters, with the `method` variable declared near the top of the function body to specify the detection approach.

### Register Method

The **register** method checks if an email is already taken by querying registration or availability endpoints. In [`holehe/modules/social_media/twitter.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/twitter.py), the module declares:

```python
async def twitter(email, client, out):
    name = "twitter"
    domain = "twitter.com"
    method = "register"
    # ... implementation queries email availability API

```

This strategy leverages registration forms that return distinct error messages or status codes when an email is already associated with an existing account.

### Login Method

The **login** method attempts partial authentication flows to verify account existence. The [`holehe/modules/social_media/snapchat.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/snapchat.py) module demonstrates this approach:

```python
async def snapchat(email, client, out):
    name = "snapchat"
    domain = "snapchat.com"
    method = "login"
    # ... implementation initiates login flow

```

By submitting the email to a login endpoint and analyzing the response—such as whether the server requests a password or returns a specific error code—the module determines if the account exists.

### Password Recovery Method

The **password recovery** method exploits password reset functionality to confirm account associations. In [`holehe/modules/social_media/odnoklassniki.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/odnoklassniki.py):

```python
async def odnoklassniki(email, client, out):
    name = "odnoklassniki"
    domain = "odnoklassniki.ru"
    method = "password recovery"
    # ... implementation triggers recovery flow

```

This technique submits the target email to a password reset endpoint and interprets the response to determine if the email is registered.

### Other Method

The **other** category accommodates custom detection logic that does not fit standard patterns. Currently, [`holehe/modules/software/office365.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/software/office365.py) uses this classification:

```python
async def office365(email, client, out):
    name = "office365"
    domain = "office.com"
    method = "other"
    # ... custom implementation

```

This catch-all strategy allows developers to implement specialized verification techniques for complex authentication systems.

## Core Engine Integration

The [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) file orchestrates module execution and aggregates results. Each module appends a dictionary to the `out` list containing the detection method used, allowing the core engine to report which technique verified each service:

```python
import asyncio
from holehe.core import core

async def check_email(email):
    results = await core(email)
    for r in results:
        print(f"{r['name']}: exists={r['exists']}  method={r['method']}")

asyncio.run(check_email("user@example.com"))

```

The `method` field is preserved in the final output, displaying which of the four Holehe detection strategies was employed for each platform.

## Usage Examples

When running Holehe via the command line, the detection strategy appears in the structured output:

```bash
python -m holehe -e user@example.com

```

Example output structure:

```text
twitter: exists=True  method=register
snapchat: exists=False  method=login
odnoklassniki: exists=True  method=password recovery
office365: exists=False  method=other

```

Programmatically, you can filter results based on the detection method to prioritize certain verification techniques over others.

## Summary

- Holehe modules use four detection strategies: **register**, **login**, **password recovery**, and **other**.
- Each module declares its `method` variable in the function body, typically under `holehe/modules/<category>/<service>.py`.
- The **register** method queries email availability APIs, while **login** attempts partial authentication flows.
- **Password recovery** exploits reset endpoints, and **other** handles custom verification logic.
- The core engine in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) aggregates results including the `method` field to indicate which detection strategy was used.

## Frequently Asked Questions

### How many detection strategies does Holehe actually use?

While some documentation references three primary methods, the megadose/holehe source code defines **four distinct detection strategies**: register, login, password recovery, and other. The "other" category serves as a catch-all for services requiring custom verification logic that does not fit standard patterns, such as the Office 365 implementation.

### How can I identify which detection method a specific module uses?

Check the `method` variable assignment inside the module's source file. For example, open [`holehe/modules/social_media/twitter.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/twitter.py) and locate the line `method = "register"` near the function definition. This string value indicates the detection strategy employed by that module.

### Does the detection method affect the accuracy of results?

Each method has distinct reliability characteristics based on the target service's API behavior. Register and password recovery methods often provide definitive answers based on explicit server responses, while login methods may yield false negatives if rate limiting or bot detection intervenes. The `method` field in outputs allows analysts to weight results accordingly.

### Can I filter Holehe modules to run only specific detection strategies?

The standard Holehe CLI does not provide native filtering by detection method. However, you can create a custom script that imports specific modules from `holehe.modules` and executes them selectively, checking each module's `method` variable before invocation to build a filtered execution list.