Email OSINT Account Search — 120+ Sites

Email OSINT Account Search checks an authorized email address against a pinned catalog of 121 public account-registration modules and returns one structured scan record per email. It is designed for consent-based security testing, personal account-footprint reviews, brand protection, and threat-intelligence triage. Each service result is labeled FOUND, NOT_FOUND, or INCONCLUSIVE; a positive response is an account-registration signal, not proof of identity, ownership, or activity.

Best fit

Use this Actor when you start with one to three full email addresses and need a broad, repeatable account-signal sweep across social, developer, shopping, media, gaming, forum, productivity, business, and other services. The output preserves the catalog version, selected service names, source domains, detection method, rate-limit state, and scan timestamp so an analyst can review the result instead of treating a green check as certainty.

Scope boundary

This Actor is intended for authorized assessments such as personal account-footprint reviews, consent-based security work, defensive brand protection, and documented threat-intelligence triage. Its read-only probes provide account-registration signals; credentials, password submission, reset completion, messages, private profiles, full recovery contacts, and raw provider payloads stay outside the product surface. Email deliverability workflows belong with an email validation tool.

Output: one record per email

One dataset item represents one completed email scan. By default, results contains positive and inconclusive service signals; set includeNotFound to true when you need every checked service.

Field	Meaning
email	Normalized input address matched to the scan record
catalogVersion	Pinned module catalog version (holehe-1.61)
sitesTargeted / sitesChecked	Selected and completed service-module counts
accountsFound	Count of FOUND service responses
notFoundCount	Count of negative service responses
inconclusiveCount	Rate-limited, challenge, timeout, or transport-response rows
scanIncomplete	Whether the per-email timeout left modules pending
sitesTargetedNames	Stable names of every selected module, including hidden negative rows
results[]	Service, domain, category, status, detection method, and rate-limit signal
scannedAt	ISO 8601 persistence timestamp

Example result shape (illustrative values; the run output is the source of truth):

{
  "email": "analyst@example.com",
  "scannedAt": "ISO-8601 scan timestamp",
  "catalogVersion": "holehe-1.61",
  "sitesTargeted": 121,
  "sitesChecked": 121,
  "accountsFound": 2,
  "notFoundCount": 116,
  "inconclusiveCount": 3,
  "scanIncomplete": false,
  "scanDurationMs": 48200,
  "resultsReturned": 5,
  "sitesTargetedNames": ["github", "gravatar", "instagram"],
  "filters": {
    "includeAdultSites": true,
    "includeRecoveryChecks": true,
    "includeNotFound": false,
    "includeInconclusive": true,
    "siteCategories": [],
    "maxSites": 121
  },
  "results": [
    {
      "site": "github",
      "domain": "github.com",
      "sourceUrl": "https://github.com",
      "category": "developer",
      "status": "FOUND",
      "detectionMethod": "register",
      "isAdult": false,
      "rateLimited": false,
      "signalType": "site_registration_response"
    },
    {
      "site": "instagram",
      "domain": "instagram.com",
      "sourceUrl": "https://instagram.com",
      "category": "social",
      "status": "INCONCLUSIVE",
      "detectionMethod": "register",
      "isAdult": false,
      "rateLimited": true,
      "signalType": "rate_limited_or_error",
      "errorClass": "module_exception"
    }
  ],
  "_note": "FOUND means the service returned an account-registration signal; it is not proof of identity or account ownership."
}

Input

The required input is an emails array with one to three full addresses. The email field is marked secret in the Apify schema; keep credentials and unrelated personal data out of the other fields.

{
  "emails": ["analyst@example.com"],
  "includeAdultSites": true,
  "includeRecoveryChecks": true,
  "includeNotFound": false,
  "includeInconclusive": true,
  "siteCategories": [],
  "maxSites": 121,
  "concurrency": 25,
  "requestTimeoutSecs": 8,
  "scanTimeoutSecs": 90,
  "proxyConfiguration": {
    "useApifyProxy": true,
    "apifyProxyGroups": ["RESIDENTIAL"]
  }
}

The full catalog is the default. Set includeAdultSites to false for a narrower investigation, includeRecoveryChecks to false when recovery-style signals are out of scope, or use siteCategories and maxSites to keep a run small. concurrency, request timeout, and total per-email timeout control runtime and rate pressure; they leave the account-signal meaning unchanged.

How it works

1. Input is normalized and validated without writing target addresses to logs or terminal summaries.
2. The pinned Holehe 1.61 package is loaded without invoking its CLI or update checker.
3. Selected modules run with bounded concurrency through one consistent proxy session per email.
4. Raw module responses are reduced to service domain, category, detection method, status, and rate-limit state. Masked recovery hints and unrelated metadata stay out of the dataset.
5. One validated dataset row is written per completed email and coupled to the email-scanned event. OUTPUT, RUN_SUMMARY, and SUMMARY record the terminal result.

Interpret the statuses

• FOUND: the service returned a positive account-registration signal for the supplied address.
• NOT_FOUND: the service returned its negative/no-registration response.
• INCONCLUSIVE: the service was rate-limited, presented a challenge, timed out, raised an exception, or returned no usable module response.

FOUND is an account-registration signal, not an identity match. Services can have stale accounts, shared addresses, alias behavior, false positives, or changing anti-enumeration responses. Treat the output as a lead for authorized review and corroborate it through lawful, independent evidence.

Workflow story

An incident responder starts with an address from an approved case file, runs one bounded scan, and reviews accountsFound, inconclusiveCount, category, sourceUrl, and scannedAt. The responder exports the compact positive and uncertain rows to the case record, expands to includeNotFound: true when a complete service matrix is needed, and records every conclusion alongside independent evidence. A single service response is treated as one lead in the investigation rather than as identity proof.

Focused standalone workflow

This Actor is designed as a focused standalone workflow: email in, account-registration signals out. Its one-record-per-email contract keeps the scan easy for an operator or AI agent to call, review, and pass into an authorized case-management process.

Pricing

The Actor uses Pay per event plus Apify platform usage. The primary event is email-scanned, charged once per completed email scan; the Actor Start event is charged separately by Apify. The live Pricing tab is the source of truth for the effective event price and platform-usage setting.

The initial event price is designed for a bounded full-catalog scan:

event cost = completed email scans × email-scanned price
estimated total = event cost + Apify platform usage and proxy usage

For example, a one-address scan creates at most one email-scanned event. Use one-email runs for the simplest cost and evidence boundary. Residential proxy usage can be the larger variable cost for a 121-service sweep.

API example

curl -X POST "https://api.apify.com/v2/acts/khadinakbar~email-osint-search/runs" \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "emails": ["analyst@example.com"],
    "includeAdultSites": false,
    "includeRecoveryChecks": true,
    "includeNotFound": false,
    "maxSites": 121,
    "concurrency": 25,
    "requestTimeoutSecs": 8,
    "scanTimeoutSecs": 90
  }'

After processing finishes, read the returned defaultDatasetId and fetch https://api.apify.com/v2/datasets/{DATASET_ID}/items?clean=true&format=json. The OUTPUT and RUN_SUMMARY KV records explain partial scans, inconclusive responses, and charge-limit stops.

Use with AI agents through Apify MCP

The regular run Actor is exposed through the Apify MCP server. An agent should have an authorized email address, choose the minimum scope needed, and preserve the distinction between FOUND and INCONCLUSIVE.

Run an authorized email OSINT account-signal scan for analyst@example.com. Check the default 121-service catalog, omit adult modules, return FOUND and INCONCLUSIVE rows, and summarize the source domain, category, detection method, and rate-limit state. Treat FOUND as a registration signal for authorized review, with identity and ownership corroborated separately.

Tool identity: khadinakbar/email-osint-search through Apify MCP.

Reliability and limits

• The catalog is pinned to holehe==1.61 so module discovery is reproducible between builds; service endpoints and anti-automation behavior can still change.
• A full scan means 121 configured modules in the pinned dependency, not a guarantee that every service is reachable or that every service supports the same signal quality.
• The Actor preserves uncertainty rather than treating blocks or timeouts as negative results.
• Maximum input is three addresses per run, and the default scan has a 90-second per-email bound.
• Use an Apify Residential proxy or a caller-managed route when the target services rate-limit shared cloud IPs. Platform and proxy usage are additional to event charges.
• Cookies, passwords, login sessions, password-reset completion, email delivery, private content, full recovery contacts, and raw response bodies stay outside the collection contract.

Builder's note

I built the wrapper around a pinned upstream module catalog because the useful part of this workflow is the consistent result contract, not a claim that every service behaves identically. I designed INCONCLUSIVE as a first-class status after seeing how quickly account-enumeration endpoints change their response shape or apply rate limits. That decision keeps a partial scan useful while making uncertainty visible to both operators and agents.

Third-party attribution

This Actor installs the upstream holehe==1.61 Python package at build time. Holehe is GPL-3.0 licensed and its upstream module catalog is the source of the 121 checks. See THIRD_PARTY_NOTICES.md in the project source for attribution and the exact pinned dependency. The Actor wrapper and Apify schemas are separate project code.

Legal and responsible-use notice

Use this Actor for addresses and services you are authorized to assess, such as your own accounts, a consent-based security engagement, or a documented defensive investigation. Account-existence checks can expose sensitive personal information and may be restricted by law, contracts, or a service's terms. The operator is responsible for authorization, notice, retention, access controls, and lawful handling of every result.