what-an-email-reveals

# What an email reveals 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. ## Step 1 — Authorized scope Read [../../ETHICS.md](../../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. ## Step 2 — Parse and validate Three different things get called "email validation". They are not interchangeable. | Method | What it proves | Cost | |---|---|---| | Syntactic | The string could be an address | Free, passive, proves nothing about the mailbox | | Domain / MX | The domain exists and accepts mail | Free, passive, `dig MX example.com` | | SMTP `RCPT TO` probe | The server claims the mailbox exists | Interactive, often blocked or lied to, and logged | Do the first two. The third — open...