Email OSINT: A Complete Investigation Workflow (2026)

Email OSINT is the practice of investigating an email address using only open sources: checking whether it exists, what services it registered for, which breaches exposed it, and what identities connect to it. Done properly, it turns a single string like [email protected] into a verified profile of accounts, usernames, aliases, and exposure history, without ever touching the target's devices or accounts.

This is the workflow we actually run, step by step, with free tools named at each stage. Five phases: validate → breach check → account discovery → username pivot → report. At the end I'll cover where an all-in-one platform like Revealer's email lookup fits. Useful when you need one query to consolidate what this pipeline produces manually across dozens of sites.

Ground rule before you open a tab: everything here uses publicly available information and lawful techniques. This workflow suits due diligence, fraud investigation, threat-intel work, and reconnecting with consented parties. It does not suit stalking, harassment, or anything requiring consent you don't have. Investigator discretion and local law apply.

Step 0: Scope and legal framing

Before touching a tool, write down two things:

1. The question you're answering. "Is this seller on a marketplace legitimate?" needs far less work than "who is behind this fraud network?" Scoping is how you stay out of rabbit holes.
2. What you'll do with the result. If your output could affect someone's employment, housing, or credit, stop. That's a consumer report under FCRA territory in the US, and consumer reports require regulated providers. OSINT output from this workflow is investigative context, not a screening product.

Log every query you run, with timestamps. It sounds bureaucratic until the day you need to prove how you reached a conclusion, or when opposing counsel asks.

Step 1: Validate the address

Don't investigate a dead address. Validation answers three questions: is the mailbox syntactically real, does the domain accept mail, and is the address a known disposable alias?

Free tools:

• dig MX example.com or an online MX checker. Confirms the domain can receive mail at all.
• hunter.io: free-tier verification that reports deliverability confidence.
• The disposable email domains list on GitHub. Grep the address's domain against it. mailinator.com, guerrillamail.com and thousands of others live there.
• HaveIBeenPwned's verification endpoint via their API, if you already have a key.

What the results mean:

A catch-all result matters more than beginners expect. Many corporate domains accept all mail, so "deliverable" proves less than you'd think. Record confidence levels, not just verdicts.

Step 2: Breach and exposure check

This is usually the highest-yield phase. A breached database tells you the address was real, roughly when it was active, and (if the leak included profile fields) sometimes a name, username, phone, or physical address.

Free tools:

• HaveIBeenPwned: the reference source for breach lookups. Free for manual searches; covers hundreds of breaches as of writing. Check both the main search and the paste-search section.
• DeHashed: deeper record-level search (names, phones, addresses attached to breach entries). Requires an account and charges for full records, but the free preview tells you whether records exist.
• Intelligence X (intelx.io): searches leaks, pastes, and darknet content; has a limited free tier.
• For stealer logs specifically (credential dumps harvested by infostealer malware rather than server breaches), coverage is spottier on free tools, since these datasets circulate in closed channels. Aggregators that ingest them exist commercially.

How to read breach data like an investigator:

• The list of breached services is an account inventory you got for free. Each service name is a lead for step 3.
• Dates matter. An address appearing in a 2013 breach but not a 2022 one may be abandoned. Consistent appearance across years says it's still in use.
• Password reuse risk: if a breach includes a plaintext or crackable password (some old ones do), never log in anywhere with it. Do note its structure. Targets reuse password patterns, and a pattern like Word+Digits+Symbol can help confirm ownership links between accounts later. Never attempt authentication against a live account with material you found; that crosses from OSINT into unauthorized access.
• Aliases: some people forward [email protected] to Gmail. Breach entries under different addresses that share a password pattern suggest the same operator.

If you're doing this repeatedly (monitoring client assets, tracking a threat actor's infrastructure), automated breach monitoring beats ad-hoc queries. Revealer's data breach lookup combines classic breach corpora with infostealer-log data and offers ongoing monitoring, which closes the gap between "I checked once" and "I'd know if this address surfaced tomorrow."

Step 3: Account discovery

Now find where the address is actually registered today. Breach data is historical; this step is about current footprint.

Free tools and techniques:

• Password reset probing (careful, ethical version): on a service's login page, request a password reset for the address. Many services reply "we sent an email" either way, but some explicitly say "no account found." That differential reveals registration without accessing anything. Do this manually, for a handful of high-value services only. Automating it at scale is abusive to the services and gets you banned. Never proceed into an actual reset flow beyond the probe.
• Sign-in-with-email flows: Google and Microsoft sign-in pages reveal whether an address has an associated account ("couldn't find your Google Account" vs. prompting for a password).
• Gravatar: load https://gravatar.com/avatar/<md5-of-email>. Many users carry a photo and display name across every site using Gravatar.
• GitHub-style public search: some platforms let you search users by email through their API or UI. GitHub's event API historically exposed commit emails, which is worth checking for developer targets.
• Search engines: "[email protected]" quoted, plus the bare local part ("jsmith1990") unquoted. Also try Bing; indexes differ meaningfully.
• HaveIBeenPwned's breach list as a shortcut. Again, each breached service name implies an account existed there.

Keep a spreadsheet: service, evidence type (reset probe / Gravatar hit / breach entry), date checked, confidence. This sheet becomes the skeleton of your final report.

Step 4: Username pivot

Account discovery gives you usernames: the GitHub handle, the forum login, the marketplace seller ID. Usernames are portable; people reuse them. Pivoting from username to username is where a single email expands into a full identity graph.

Free tools:

• WhatsMyName checks a username against hundreds of sites in one pass. Open source, maintained by OSINT practitioners, runs from a simple web form or the CLI.
• Sherlock is the classic CLI equivalent (python sherlock <username>). Fast, scriptable, occasionally noisy with false positives.
• Maigret is a Sherlock fork with more sites and richer per-site info extraction.

Handling false positives: automated username checkers flag any site where a matching handle exists, including unrelated people who happened to pick the same name. Confirm a hit before adding it to your report:

1. Does the profile show overlapping signals (same avatar hash, bio details, location, linked accounts)?
2. Does creation date align with the timeline you've built?
3. Can you find a direct link (the profile references the email, or vice versa)?

Two independent corroborating signals is our minimum before calling an account "same actor." One signal alone stays in the report as "possible, unconfirmed."

While you're here, also pivot on the phone numbers and names that breach entries surfaced. The same validate-and-discover logic applies, just with different tools. Revealer's broader people search and username search modules handle those pivots in one query if you'd rather not hand-roll them.

When to consolidate instead of hand-rolling

The manual pipeline above is the right teacher and the right tool for one-off cases. It stops scaling around the point where any of these are true:

• You run investigations weekly, not annually.
• The target set is dozens or hundreds of identifiers, not one.
• You need recursion: the AI-driven approach of following identifier → account → new identifier → new account automatically. Revealer's AI Deep Search does this agent-driven traversal across sources, which mirrors steps 2–4 but chains them without you babysitting each hop.
• Your findings feed an app or a SOC pipeline and need an API rather than copy-paste. Revealer exposes everything through its API.

Rough comparison of approaches, as of writing:

Check vendors' sites for current counts and pricing; these figures drift. We're obviously partial on the last row, so treat it accordingly and test any claim against your own cases.

Step 5: Reporting

An email investigation that lives in your browser tabs doesn't exist. Close with three artifacts:

1. Timeline. First seen in a breach, account creations, most recent activity signal. Chronology exposes evolution: burner address → real identity is a common pattern in fraud work.
2. Entity table. Every confirmed account with its evidence class and confidence level. Mark each row: confirmed (two+ signals), probable (one strong signal), possible (weak signal only).
3. Methodology appendix. Tools, queries, dates. This is what makes the report reproducible and defensible.

Write conclusions the evidence supports. "The address registered on four marketplaces within six weeks, consistent with the seller-farm pattern in case #X" is a finding. "The subject is a scammer" is an opinion that won't survive scrutiny.

Common mistakes

• Treating breach presence as account presence. A 2015 breach entry proves a 2015 registration. It says little about today.
• Trusting username-checker hits blindly. Every popular handle belongs to many people. Corroborate or label.
• Ignoring the domain side of custom addresses. WHOIS history, certificate-transparency logs (crt.sh), and DNS records on the target's own mail domain frequently outperform everything else in the pipeline.
• Skipping the negative space. "No accounts found on major social platforms" is a finding too, and sometimes the telling one. Burner behavior looks exactly like that.
• Over-collecting. If a data point doesn't serve the scoped question, leave it out. Less exposure to privacy rules, cleaner reports.

Frequently asked questions

Is email OSINT legal? Searching publicly available information about an email address is generally lawful in most jurisdictions, and everything in this workflow uses public sources only. It becomes problematic when used for stalking, harassment, or impersonation, or when accessing non-public systems. Laws vary by country. Know yours.

Can I find out who owns a Gmail address? Often partially. Gmail itself reveals nothing, but the address's footprint (breach entries, linked accounts, reused usernames, Gravatar images) frequently surfaces a name. Full attribution isn't always possible, and honest reports say so.

What's the fastest way to check if an email was breached? HaveIBeenPwned's free search. Enter the address and read the list of breaches with dates. For deeper record detail and stealer-log coverage, dedicated platforms offer more than the free tier shows.

Do free username checkers give false positives? Yes, routinely. They report any site where the exact handle exists, regardless of who owns it. Treat every hit as a lead needing corroboration (overlapping avatars, bios, timelines, or direct cross-references) before you attribute it.

Is it safe to use the password-reset trick for account discovery? The passive version, observing whether a service says "no account found" versus "email sent", is widely used and accesses nothing. Keep it manual and limited to a handful of services. Never take a reset further, and never automate it at scale.

When should I use a paid platform instead of free tools? When volume or speed matters: recurring casework, bulk identifiers, or automated pipelines. Consolidated services such as Revealer collapse validation, breach data, account discovery, and username pivoting into one query with API access. The trade-off is cost versus the free pipeline's labor.