Email forensics, digital identity, username correlation, deanonymization, and confidence scoring.
Identifying a person online is never a one-step process. It's the gradual accumulation of independent data points — each insufficient on its own — until a full, verifiable picture emerges.
Every email has two parts: the body (what you read) and the headers (metadata describing how the message was created, routed, and delivered). Headers are hard to fully fake — every server that handles the message adds its own record independently — which makes them a reliable source of technical intelligence even when a sender is actively trying to hide.
| Field | What it shows | Reliability |
|---|---|---|
From | The displayed sender address | Low — entirely user-controlled, trivially spoofed |
Received | Every server that handled the message (prepended, so read in reverse chronological order) | High — the most valuable field for tracing origin |
Date | Composition timestamp, with a timezone offset | Medium — a clue about local settings, not proof of location |
Message-ID | A unique ID; the domain after the @ often reflects the real sending server | High |
X-Mailer / User-Agent | The software used to compose the message, if present | Medium — some services strip it |
Reply-To | A different address for replies | A mismatch with From is a red flag for redirection or spoofing |
Reading the Received chain: read it bottom to top — the bottommost entry is the first server to touch the message (usually the sender's own mail server), the topmost is the last hop before delivery. Each entry usually contains an IP address, which is much harder to fake than a hostname.
Timezone offsets as a location clue: the Date header carries an offset (+0530, -0500) reflecting the local time setting of whatever device or server generated the timestamp. It's not proof of location — a technically savvy sender can change their system clock — but it's a useful corroborating signal, especially when an unusual offset narrows the field a lot.
The right mindset: treat each header field as one piece of evidence among several. A single anomaly could be a misconfiguration. Multiple independent fields pointing to the same conclusion — a different sending platform than claimed, a specific timezone, a revealing Message-ID — form a much stronger finding. To actually see the full headers, most webmail and desktop clients require exporting the message as a raw .eml file — everything above the first blank line is headers, everything below is the body.
A person's digital identity is the sum of information that exists about them online. Every interaction leaves a trace — active (content they deliberately shared) or passive (data collected without their direct awareness, like metadata baked into an uploaded file).
Naming conventions vary a lot by culture, and ignoring them leads to bad searches or missed results.
Practical rule: when researching a subject outside a Western cultural context, look up the naming convention for their country/language before you build your queries.
A specific, learnable tell for a fabricated persona: check whether the profile photo actually matches the photos the account posts elsewhere. A polished, professional-looking headshot paired with an otherwise-active account whose other photos never show the same person in an ordinary, unposed moment — a different setting, season, or context than the profile photo implies — is a concrete, nameable red flag. A genuine account accumulates photos of the same real person across many real moments over time; a fabricated one often has a single carefully chosen image doing all the identity work, with everything else either thin or visibly disconnected from it.
Usernames are one of the most consistent cross-platform identity signals — people reuse them out of habit, even while trying to stay anonymous. Username enumeration is the systematic search for one username across many platforms; tools like Sherlock and Maigret automate this.
Linking a username to a person across platforms always needs multiple corroborating points: profile bio text, profile photo, writing style, activity timing patterns. Never attribute an identity based on a single username match.
Passive location inference pulls geographic information out of text with no GPS or geotags at all: direct references (city names), indirect ones (local sports teams, weather, transit systems), and time patterns (posting times reveal a timezone). When several independent clues converge on the same city, you can state the finding with real confidence.
Sites leak information unintentionally through: HTML comments containing internal notes, server response headers revealing software versions, config files sitting in accessible directories, directories with file listing accidentally left on, sitemaps, and robots.txt.
| Tool | Use | Example |
|---|---|---|
curl | Manually inspect headers/source | curl -I http://target.local · curl http://target.local/robots.txt |
dirb | Brute-force directories/files with wordlists | dirb http://target.local -X .html,.pdf |
| Photon | Crawl a site and extract emails/links/metadata | python3 photon.py -u http://target.local --level 3 |
Deanonymization links an anonymous identity to a real person by stacking multiple data points. Example of a complete chain: a username surfaces → linked accounts appear on two platforms → a camera serial number ties them to the same device → an email domain leads to a corporate website → a leaked document confirms a full name.
Watch for the plausible-but-wrong lead specifically while pivoting: a name surfaces at the same employer, in an adjacent role, superficially matching your target — and it's tempting to treat that proximity as confirmation. It isn't. Two people at the same company are not the same person, and pivoting toward whichever record is easiest to find, rather than the one your evidence actually supports, is exactly how a correlation chain quietly goes wrong. Verify the specific individual the evidence points to, not just the organization they appear to share.
| Level | Basis |
|---|---|
| Low | A single unverified point (username match only) |
| Medium | Two independent converging points (username + email domain) |
| High | Three or more independent points (username + metadata + a document) |
| Confirmed | All of the above, plus direct proof of authorship |
| Strong | Weak |
|---|---|
| Camera serial number in EXIF | Username match (common name) |
| Document author metadata | Similar writing style alone |
| Email in a leaked organizational document | Unverified biographical claim |
| Multiple independent converging points | A single platform match |
ExifTool remains the go-to tool: exiftool -a -u -g1 image.jpg pulls out even hidden, non-standard tags, grouped by category.
One of the most common errors in OSINT: selectively looking for evidence that confirms your original hypothesis. Good practice: actively look for evidence that would disprove your attribution, document everything (including what doesn't fit), have a second investigator sanity-check the evidence chain, and assign confidence levels honestly, even when it's inconvenient.
.eml and compare the Received, Message-ID, and timezone offset in the Date header.curl -I against a public site of your choice and inspect the response headers — what do they reveal about the server or software stack?In exercise 1, you'll likely see the privacy-focused webmail leave fewer visible server hops in Received — that's exactly the kind of mismatch an investigator uses to work out which platform was actually used, even when From doesn't reveal it. In exercise 2, a good self-check: if you found "yourself" on a platform you don't even remember signing up for, that's a useful reminder of how easily we reuse usernames without noticing — the same lesson comes back in reverse in Chapter 14 (OPSEC).