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), so they remain dependable technical evidence 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), and 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: read every header field as one clue in a larger set. A single anomaly could be a misconfiguration. When several independent header fields all indicate the same conclusion (an actual sending platform different from the one claimed, a telltale timezone, an informative Message-ID), the finding becomes far stronger. To actually see the full headers, most webmail and desktop clients require exporting the message as a raw .eml file: in that format the header block ends at the first blank line and the body begins right after it.
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 is worth flagging when it's 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). That combination 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, and typically fall back on predictable variations of their usual handle (numbers, dots, underscores, initials). Before enumerating, generate the likely variations systematically from what you already know (a full name yields a whole family of candidate handles) and check all of them. Username enumeration is the systematic search for a username across many platforms. Tools like Sherlock and Maigret automate this, and both accept multiple usernames as positional arguments in a single run:
python3 sherlock.py user1 user2 user3
maigret user1 user2 user3Linking 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. 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 |
| GPS coordinates matching a known location | Identical profile photo (it may have been copied) |
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.
robots.txt, sitemap, HTML source, HTTP headers, directory brute-forcing only where permitted) and looked for leaked staff directories or documents carrying full names.exiftool -a -u -g1) for camera serial numbers, document authors, and GPS coordinates..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 16 (OPSEC).