Email OSINT: what an email address reveals

An email address looks like an identifier and behaves like one. It is the key you use to sign in almost everywhere, it is the address that password resets are sent to, and it is the value most services collect before they collect anything else. That combination is what makes it the single most useful starting point in an open source investigation.

It is also a record of your own behaviour. The part before the @ is often a name, a handle, or a fragment of a date chosen years ago. The domain tells you which provider or which employer a person used, and a corporate domain attached to a personal account says something about where that person works. None of that is secret, and all of it is legible to anyone who looks.

An email lookup returns records that already exist somewhere else. They are held by third party breach and intelligence sources, and this service obtains them from those sources through their published access methods. No lookup here reads your mailbox or opens a live account.

The records themselves are the residue of ordinary data handling. A retailer's customer table, a forum's user list, a marketing list that was sold and resold, a stealer log from an infected personal computer. When one of those stores leaks or is traded, the email addresses inside it join a corpus that sources index and resell.

That is why the same address shows up across many records with different levels of detail. One source may hold nothing but the address and a hash. Another may hold a name, a street address, a phone number and a password. The difference usually reflects how much the breached site collected, not how deliberately you were targeted.

Submitting an address returns the records in which that address appears, normalized into one schema and sorted newest first. Every row names the module it came from, so you can see whether a hit came from a large aggregated breach source, a stealer log index, or an open web source.

That source label is the part worth reading closely. A row from a stealer log usually means the address was typed into an infected machine and captured together with credentials. A row from an aggregated breach corpus usually means the address sat in a database that was later published. The two imply different follow up, so read the label before you read the values.

The first lookup on a new visitor runs in full. After that, queries still run and the fact that a record exists, along with its source, is still shown, but the values inside it are masked until the account holds credits or an active plan. That is deliberate: it lets you judge whether a paid lookup is likely to return something useful before you spend anything.

It cannot tell you whether anyone has used the data. A record shows what was exposed, not what was done with it. Usage shows up in your accounts, your inbox, your statements and your credit file, which is where you look next.

It cannot confirm that a record is accurate or current. Third party data is frequently stale, duplicated and wrong, and entries are sometimes fabricated when a database is assembled to make a leak look more valuable than it is. Treat a row as evidence that the address circulated, not as a statement of fact about you.

It cannot prove a negative. An empty result means the sources we query hold no record for that address today. It does not mean the address was never exposed, because coverage varies by source and by the age of the records we can reach.

It cannot build a profile of a person, and it is not designed to. We do not return home addresses, relatives or contact details scraped from directory sites, and we do not query people search brokers.

Work out what the row actually contains, then act on that and nothing else. Doing everything is not better than doing the right things.

Address and password: change the password on the account that belongs to the address, then change it anywhere you reused it. Reuse is what turns one exposed login into a dozen.

Address with a name, phone number or street address: the risk is targeted phishing rather than account takeover, because a message that quotes details the sender should not have is far more convincing. Expect that message and treat unexpected contact with suspicion.

Address inside a stealer log: assume the credentials captured alongside it were live at the time of capture, and treat every account that used them as exposed. Change them, then move the accounts that matter to an app based second factor so a copied password is not enough on its own.

Address on its own: this is the mildest case and the most common one. It still tells a sender where to aim, so expect more spam and better crafted phishing, and be sceptical of mail that references a service you do not remember using.

Whatever the row holds, check again after a few months. New records are published as fresh breaches surface, and an address that was clean last quarter does not stay clean by itself.

You may query an address you own, or one you are lawfully authorised to investigate. The Acceptable Use policy sets that boundary and it is not decorative: bulk or sequential queries run to assemble, enrich or resell a dataset are a breach, and so is using a record to harass a person or to make a decision about them where the law restricts it.

This service is not a consumer reporting agency, and nothing it returns may be used for credit, insurance, employment, housing or any other purpose regulated by the Fair Credit Reporting Act or comparable law where you are. Those decisions require data collected and verified to a standard these sources never met.

You are responsible for your own compliance position. Privacy and data protection law differs by country, and an address that is fair game in one jurisdiction can carry obligations in another. If you are unsure whether a use is lawful, the answer is to stop and take advice rather than to run the query and decide afterwards.

If you want to know whether an address is sitting in records other people can hold, that is the question the email lookup is built to answer. It is a record check rather than a monitoring service, so run it, read the source label on each row, and act on what is actually there.