# What an email reveals Human Guide

## What This Is For
Investigate an email address — MX and syntactic validation, Gravatar lookup, corporate email-format inference, breach exposure, and full mail-header analysis covering the Received chain. It gives the agent a clearer input/output frame for email marketing: what context to ask for, what decisions to make, and what usable artifact to return.

Use this as a human-readable version of the What an email reveals agent skill. It is meant for marketers, operators, founders, and other non-coders who want the workflow without reading agent-specific implementation instructions.

## When To Use This
- Use this when you need a repeatable process for what an email reveals.
- Use this when the task needs judgment, examples, constraints, or a clear output format rather than a one-off prompt.
- Use this when you want to hand an AI assistant enough context to produce a usable marketing artifact.

## When Not To Use This
- Do not use this when you only need a quick factual answer.
- Do not use this when the work depends on private data you cannot share with the assistant.
- Do not use this as a replacement for legal, compliance, financial, or medical review.

## What You Need Before Starting
- The goal or business outcome you want.
- The audience, customer segment, or market context.
- Any source material the assistant should respect, such as notes, briefs, examples, URLs, or brand guidance.
- Constraints such as tone, length, channel, deadline, region, or approval requirements.
- A clear definition of what a good final answer should look like.

## Step-By-Step Workflow
1. State the job clearly: "Use the What an email reveals guide to help me with..."
2. Add context: audience, goal, offer, channel, source material, and constraints.
3. Ask the assistant to identify missing inputs before producing the final output.
4. Have the assistant follow the skill-specific guidance below.
5. Review the result against the final checklist and ask for revisions where needed.

## Skill-Specific Guidance
- `google-like-a-spy` the full address in quotes, and the local part alone.
- Run `what-leaked-about-you`. Breach membership is the single best answer to
- Push the local part into `hunt-a-handle` as a username seed.
- Search code hosting for the address in commit metadata via
- `Message-ID` — the domain part and the ID's shape often identify the sending
- `Authentication-Results` — the receiving server's SPF, DKIM, and DMARC
- `X-Mailer` / `User-Agent` — client fingerprint, frequently left in place by
- `Return-Path` vs `From` — a mismatch is normal for mailing lists and
- **Catch-all domains defeat verification outright.** Everything validates.
- **Disposable and forwarding services.** Throwaway domains mean the address was
- **Role addresses** (`info@`, `sales@`, `admin@`) belong to functions, not
- **Inferred addresses are hypotheses.** Deriving `j.doe@company.com` from a

## Decision Points And Nuance
The original skill emphasizes: Step 1 — Authorized scope, Step 2 — Parse and validate, Step 3 — Gravatar, Step 4 — Where is this address registered, Step 5 — Read the headers, if you have the message, Where this goes wrong, Confidence grading, Worked example, Pivots, Legal and ToS notes.

Use these questions to steer the work:
- What is the intended audience or buyer?
- What source material must be preserved?
- What should the assistant optimize for: clarity, persuasion, accuracy, speed, creativity, or conversion?
- What examples represent the desired quality bar?
- What should the assistant avoid?

## Common Mistakes
- Never send mail to the subject as a research technique.
- the vendor, the accuracy limits do not change.
- explicitly, or don't do it.
- never meant to persist; relay and alias services (including provider-issued
- employee whose name you have. The output is always a *hypothesis*, and must be
- ticketing system. Never attribute one to a named individual. They are still
- useful: `abuse@` and `security@` are often required to be monitored and can
- Do not treat it as confirmed by an SMTP probe — probing is interactive, and

## Copy-And-Paste Prompt
```text
Use the What an email reveals human guide.

My goal:
[Describe the business outcome]

Audience:
[Describe who this is for]

Context and source material:
[Paste notes, examples, links, or existing copy]

Constraints:
[Tone, length, channel, timeline, must-include items, must-avoid items]

Before producing the final output, ask me for any missing information that would materially improve the result.
```

## Final Checklist
- [ ] The output matches the original goal.
- [ ] The audience and context are reflected in the answer.
- [ ] Important constraints and source material were preserved.
- [ ] The assistant made the relevant decisions explicit.
- [ ] The final artifact is ready to use, review, or hand to the next person.

## Source
This guide was generated from the useosint/skills skill entry for `what-an-email-reveals`.

## Source Skill Notes
These notes preserve the nuance from the original skill. Use them as supporting reference when the workflow above feels too generic.

# 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 — opening an SMTP session and issuing `RCPT TO` 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. `first.last`, `flast`, `firstl`, `f.last` each imply
a name and, on a corporate domain, a company-wide convention — see
[reference/corporate-formats.md](reference/corporate-formats.md).

**Gmail normalisation matters.** Gmail ignores dots in the local part and
everything after a `+`. `j.doe+news@gmail.com`, `jdoe@gmail.com` and
`jd.oe@gmail.com` are one mailbox. Consequences: addresses that look different
in two breaches may be the same person, and a `+tag` 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.

## Step 3 — Gravatar

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.

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

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

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

## Step 4 — Where is this address registered

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