An email address is usually the highest-value selector in an investigation: it carries a name, a domain, an account history, and a breach footprint. The beginner error is trying to prove the address exists. Existence is the least interesting thing about it, it is the hardest thing to establish passively, and the techniques that establish it are the ones that expose you. Work the structure and the footprint first; treat validation as a bonus.

Never send mail to the subject as a research technique.

Read ../../ETHICS.md. Write down subject, objective, in-bounds selectors, out-of-bounds actions, and the governing jurisdiction. Decide in advance whether interactive probing — SMTP conversations, password-reset flows, signup-form enumeration — is authorized. It usually is not. Everything below is passive unless marked otherwise.

Done when scope is written and the interactive-probing decision is recorded.

Three different things get called "email validation". They are not interchangeable.

dig MX example.com

RCPT TO

Do the first two. The third — opening an SMTP session and issuing to see whether the server accepts the recipient — is a live conversation with the subject's mail infrastructure from your IP. It gets logged, it gets your address range blocklisted, and against a catch-all domain it is worthless: a catch-all accepts every recipient, so every address "exists". Greylisting, tarpitting, and accept-then-bounce policies produce the same useless answer. Third-party validation APIs mostly wrap the same probe; the exposure moves to the vendor, the accuracy limits do not change.

Then parse the local part. , , , each imply a name and, on a corporate domain, a company-wide convention — see reference/corporate-formats.md.

Gmail normalisation matters. Gmail ignores dots in the local part and everything after a . , and are one mailbox. Consequences: addresses that look different in two breaches may be the same person, and a frequently names the service the address was given to, which is free intelligence about where the subject holds accounts. Not every provider behaves this way — check before assuming.

Done when the address is graded valid / invalid / unknown, the normalised form is recorded, and the name hypothesis is written down.

Gravatar maps an address to a public avatar by MD5 hash of the lowercased, trimmed address. Compute the hash and request the avatar; a returned image means the address was registered with the service, and the associated public profile can carry a display name, a location, links to other accounts, and verified accounts on other platforms.

printf '%s' "jdoe@example.com" | tr 'A-Z' 'a-z' | md5sum

Free, passive, no key. Run the avatar through . Treat a default fallback image as "no Gravatar", not as "address invalid".

Done when Gravatar presence is checked and any profile fields captured.

The honest position: reliable account enumeration by email is an oracle problem. Password-reset and signup forms disclose whether an address is registered, which is exactly why tools exist to automate them — and exactly why doing so is interactive, often against terms of service, and potentially notifying (a reset request can email the subject). Flag it, get it authorized explicitly, or don't do it.

Passive alternatives that cost you nothing:

Done when the service list is assembled and each entry is marked passive or interactive in provenance.

Only applies when you legitimately possess the message. Headers are where an email stops being a selector and becomes evidence.

Read the chain bottom-up: the bottom-most is the earliest hop, and the originating host is there unless the sending platform strips it. Everything below the first server you trust can be forged wholesale.

Field-by-field guide: reference/header-fields.md.

Done when the originating infrastructure is identified or explicitly stated as unrecoverable.

Given . returns records at a hosted provider — the domain takes mail. Gravatar: no avatar, so no profile pivot.

Two employee addresses in a conference PDF are and , so the convention is . That makes structurally consistent — evidence about the format, not evidence the person exists. No SMTP probe is run; interactive steps are out of scope here.

The dead end: returns nothing for the address, which initially reads as "not a real user". Re-running against the Gmail-normalised personal address recovered from a code-hosting commit gives three breaches, one of them a developer forum with the handle . That handle goes to . The corporate address stays graded inferred; the personal one is the working selector.

SMTP probing and password-reset enumeration are interactive, commonly prohibited by terms of service, and in some jurisdictions arguably unauthorized interrogation of a system. Get them in writing before you use them. Under GDPR and UK data protection law an email address is personal data on its own — collect only what the objective needs, store it encrypted, and set a deletion date with the case file. Message content you possess may carry separate confidentiality or privilege obligations independent of the OSINT question.

Run . State validity and how it was established, whether the domain is catch-all, the service list with passive/interactive provenance, breach exposure, and the identity attribution with its confidence grade.

Done when every address is marked observed or inferred, and no inferred address is stated as fact.