How to investigate an email address with OSINT

An email address is often where an investigation starts: the sender of a suspicious message, the address someone used to sign up to your service, a new supplier's contact, or your own inbox. Open sources can tell you a fair amount about it without writing to anyone, and without the owner being alerted.

This article sets out a six-step method: what to check, in what order, what each result actually means, and how to avoid jumping to conclusions.

Why investigate an email address

It makes sense when there is a specific, defensible purpose. The usual ones are:

• Phishing triage. Does the sender's domain exist, when was it registered, and is it imitating a real organisation?
• Fraud prevention. Spotting sign-ups that use disposable addresses, or addresses with no history at all.
• Due diligence. Checking that a supplier's, customer's or partner's contact matches the organisation they claim to represent.
• Self-audit. Seeing which accounts, profiles and breaches the internet links to your own address.

What is not legitimate: tracking down someone who does not want to be found, or gathering information about a person to put pressure on them. The techniques are the same; the purpose is what differs, and it is the first thing to write down.

Step 1: read the address before you query anything

An address has two parts, the local part before the @ and the domain, and both carry information.

• The domain tells you who handles the mail. A corporate domain points to an organisation; a free provider (Gmail, Outlook, Proton and the like) says nothing about where the owner works.
• The local part may be a name, a set of initials or a handle the person uses elsewhere. It is a low-confidence pivot: there are thousands of "jsmith" addresses.
• Plus tags (user+shop@domain) are a filtering feature many providers support. The address that matters is the base one, without the tag.

Note down what you see before running a single query. It will help you later to keep what you observed apart from what you inferred.

Step 2: mail provider, MX records and domain age

A domain's MX records list the servers that accept its mail. Looking them up answers three questions:

1. Can it receive mail at all? If the domain has neither MX nor A records, no address on it receives anything. Without MX, SMTP falls back to the domain's A record, so check both.
2. Who hosts it? Server names give the service away: Google Workspace, Microsoft 365, a filtering gateway such as Proofpoint or Mimecast, or a self-hosted server.
3. Is it disposable? Public, maintained lists of temporary-mail domains exist. A sign-up from one proves nothing on its own, but in a fraud context it counts.

If the domain does not belong to a free provider, add two checks. First, its registration date, which you get through RDAP, the structured successor to WHOIS. Second, its TXT records, which usually hold the SPF policy and verification tokens for services such as Google or Microsoft. A domain registered last week that asks for an urgent payment is a clear signal in phishing triage.

One important caveat: an MX record does not mean the specific mailbox exists. Verifying a mailbox means asking the mail server, and many servers accept any address (so-called catch-all configurations), so that answer is often uncertain.

Step 3: public profiles tied to the address

Some services publish a profile linked to an email address, and you can look it up knowing nothing but the address:

• Gravatar. Links an avatar and, if the owner filled it in, a display name, location, employer and verified accounts on other networks. Profiles are found through a hash of the address.
• PGP keyservers. Anyone who published a public key left a name and one or more addresses in it. Other addresses on the same key very likely belong to the same person.
• GitHub. Some users show their email on their profile, and public commits carry the author's email. An address that appears as a commit author leads to an account and its repositories.
• Platforms with a public API that return the profile behind an email, such as Duolingo: username, display name, photo and join date.

Every profile is something someone published, usually the owner. It may be out of date, use a made-up name, or belong to someone else who mistyped their address.

Step 4: which services the address is registered on

Many platforms respond differently on their sign-up or login forms when an email is already in use. Open-source tools such as Holehe automate that check across more than a hundred services.

Two caveats are worth knowing:

• Some checks go through password recovery, which can send the owner an email. Pandora turns those modules off: the investigation stays passive and nobody is alerted.
• A registration tells you the address was used to create an account, not who uses it today or since when. Use it to decide what to check next, not as evidence.

Pandora also leaves adult-content and health services out of this sweep. Knowing that an address is registered with them reveals data the GDPR gives extra protection, and it is rarely necessary for the purpose of an investigation.

Step 5: breach exposure

Services such as Have I Been Pwned, XposedOrNot and LeakCheck tell you which known breaches include an address, when they happened and which types of data were exposed. That gives you two things:

• A minimum age. If the address appears in a 2016 breach, it existed in 2016. When assessing a suspicious sign-up, age matters: an address with no prior trace is not guilty of anything, but it has no history either.
• A risk map. In a self-audit, knowing which of your details are circulating explains some phishing attempts and tells you which passwords to change.

Pandora shows exposure (breach name, date and data types) and never the leaked values: no passwords, no hashes.

Step 6: pivot carefully

The previous steps produce new data: a handle, a name, a domain, another address. Each one opens a new line of inquiry. The handle can be checked across hundreds of sites; the domain in DNS and company registers; the name in public sources.

Every pivot also raises the risk of merging two different people. A practical rule: record how confident you are in each new data point, and do not pivot from a weak one as if it were solid. In Pandora, the local part of an address comes in as a "candidate handle", not a confirmed one.

Corroborate before you conclude

What separates a useful investigation from a harmful one is how you get from data to conclusions. Three habits help:

1. Separate fact, inference and hypothesis. "There is a Gravatar profile named Ana Ruiz" is a fact. "The address belongs to Ana Ruiz" is an inference. Write them down separately.
2. Look for independent sources. Two websites copying the same Gravatar profile are not two sources. A Gravatar profile and a PGP key created years earlier under the same name are.
3. Tell strong corroboration from weak. Strong: the same public key on two accounts, the same photo on two profiles, one profile linking to the other. Weak: the same handle, a common name, the same city.

Record negative results too, along with the date of every query. Something missing today may have existed before, and what does show up may be years old.

In Pandora, every data point keeps the transform and source that produced it, and the Dossier shows how many distinct sources back it up: green for several, yellow for just one.

Where Pandora fits

In Pandora you type the address and it recognises it as an email, then runs the automatic sources: mail profile and MX, Gravatar, PGP keys, GitHub, platform registrations and breaches. Deep mode goes round again on any handles, emails, domains and IPs that turn up.

Before you start, you state the purpose of the investigation, which is stored in the audit log alongside every query. Results stream into a live graph, each with its source, and the case can be exported as JSON, CSV or GraphML, or as a printable report.

Legal and ethical note

An email address that identifies a person is personal data, and processing it requires a legitimate purpose and a lawful basis, even when the information is public. Keep your search to what that purpose needs, do not retain more than necessary, and do not use what you find to contact or pressure anyone.

This article describes a technical method and is not legal advice. If your case has legal implications, speak to a lawyer or your data protection officer.