Investigating Email, Web and Photo Clues

What you'll be able to do

You will be able to read the basic clues in an email header, a domain registration lookup and a photo's metadata, and state their limits.

• Follow the path of an email through its header and spot a mismatch.
• Read a domain registration lookup and know what it can and cannot tell you.
• Explain why an IP address, a timestamp or a file name is a clue, not proof.

All names, domains and addresses in this lesson are fictional and use reserved example names.

Clue 1: the email header

Every email carries a header: lines of information above the message that most apps hide. You can usually see them with an option such as "Show original" or "View message source". Lesson 2.2 introduced the idea; the header fields themselves are defined in an internet standard, RFC 5322.

The most useful lines for an investigator are:

• Received: each mail server that handles the message adds one of these at the top. So you read them from the bottom up to follow the message from its starting point to your inbox.
• From: the address you see. It can be a look-alike, and the display name can say anything.
• Reply-To: where your reply will go. If it differs from the From address, ask why.
• Date: when the sender's system says it was sent, including a time-zone offset such as +0000.
• Authentication results: many providers add a line summarising the SPF, DKIM and DMARC checks from Lesson 2.2.

One important limit: the lines added by your own provider's servers are the most trustworthy. Lines lower down were added before the message reached your provider — and a sender can fake them.

Read-a-header activity

Read this simplified, fictional header, then answer the four questions privately for yourself before opening the answers below.

Received: from mx.example.net (mx.example.net [198.51.100.25])
        by inbox.example.org; Tue, 3 Mar 2026 09:14:07 +0000
Received: from desktop-7 (unknown [203.0.113.45])
        by mx.example.net; Tue, 3 Mar 2026 09:14:05 +0000
Authentication-Results: inbox.example.org; spf=fail; dkim=none; dmarc=fail
From: "Northbank Security" <alerts@northbank-help.example>
Reply-To: refunds@example.com
To: student@example.org
Date: Tue, 3 Mar 2026 09:14:02 +0000
Subject: Unusual activity - confirm your details today

• 1. Which server first handed the message to the internet, and which server delivered it to the recipient?
• 2. What do the authentication results suggest?
• 3. What is odd about the From and Reply-To lines?
• 4. Does the address 203.0.113.45 tell you who sent the email?

Clue 2: the domain registration lookup

A domain registration lookup shows public details about who registered a domain name, through which company (the registrar), and when. The book calls this a WHOIS search. Since 28 January 2025, RDAP has been the definitive registration-data service for ICANN generic top-level domains (gTLDs), replacing the former WHOIS-service requirement. Generic top-level domains are endings such as .com, .org and .net. Country-code domains — two-letter endings run by national registries — follow their own registry's rules, so check each one separately.

A simplified, fictional lookup result might look like this:

Domain name:     northbank-help.example
Registrar:       Example Registrar Ltd
Created:         2026-03-01
Registrant:      REDACTED FOR PRIVACY
Name servers:    ns1.example.net, ns2.example.net

What it can tell you: the domain was registered two days before the email above arrived — a strong warning sign for a site claiming to be an established bank. What it cannot tell you: who is behind it. Personal details of registrants are often redacted for privacy, and criminals can register with false details anyway.

Clue 3: IP addresses — a connection, not a person

An IP address identifies a connection to the internet at a particular moment (Lesson 2.1). An IP address is a connection, often shared, not a person. Here's why:

• Everyone in a home, office or café usually shares one public address through the router.
• Many internet providers share a single public address among many customers at once. The internet standards even reserve a block of addresses for this sharing (RFC 6598).
• VPNs and the Tor network deliberately hide the user's real address, and the book warns that addresses can be spoofed.

At most, an internet provider's records for the exact time may link an address to a subscriber account. Even then, the account holder may not be the person who was typing. That's why IP evidence must be handled with great care, as Dr. Al-Doori stresses.

Clue 4: files, timestamps and photos

• File type versus extension. A file's name ending (".jpg", ".pdf") is just a label that anyone can change. Most file types begin with a recognisable file signature (sometimes called a "magic number") that reveals the real format. A "holiday.jpg" whose signature says it is a document deserves a closer look.
• Timestamps. Files record when they were last modified, last accessed and created. These are useful clues, but they can change when files are copied, moved or edited, and devices may use different clocks or time zones. Always cross-check them with other evidence.
• Photo metadata. Photos can carry hidden details called metadata (often EXIF data): the date, the camera or phone model and, if location was on, GPS coordinates. Lesson 3.5 showed how this exposes where you live. Apple's guidance explains how to turn location off when sharing a photo. For investigators, remember that metadata can be removed or edited, so its absence proves nothing, and its presence should be cross-checked.

Real-World Example

Imagine (a fictional scenario) a student, Dana, who receives a threatening message with a photo attached. A friend runs an online IP lookup on the sender's address from the header, finds it belongs to a café's internet provider in her town, and wants to go and confront the café's owner.

Dana does the careful thing. She keeps the original message, screenshots the header and writes down the date and time. Then she reports it to the platform and the police. The café's address could have been used by any customer, by someone on the café's Wi-Fi outside, or faked in a lower header line. The photo's metadata shows a date but no location. Investigators with legal authority can request the provider's records; a friend with a lookup website cannot.

From the Book to 2026

What the book teaches. WHOIS reveals who registered a domain or address; IP tracking can locate a user, though spoofing and Tor demand great caution; email headers can be traced to a message's origin; file signatures, timestamps and photo GPS data are valuable clues.

Why it made sense. For years, WHOIS records were the standard public lookup, and an IP address was a common starting point for investigations. The book's caution about IP evidence remains exactly right.

What has changed. Security guidance has evolved since the original text. For gTLDs, RDAP replaced the WHOIS-service requirement on 28 January 2025, and registrant details are often redacted. Shared addresses are now normal, through home routers and provider-level sharing, and VPNs are common, so the gap between "an address" and "a person" is wider than ever. Modern phones also make it easy to strip location from photos before sharing.

What to do now. Treat every clue as a lead to cross-check, never a conclusion. Say "a connection from this address at this time", not "this person". Pass leads to the people with legal authority to follow them.

What Would You Do?

A scam email reached your inbox. You open its header and see an IP address in the lowest Received line. A free website says the address belongs to a provider in a nearby city. A friend suggests posting the address online with the words "this is the scammer".

What would you do instead, and why? The answer note below resolves it.

Knowledge Check

Key Takeaways

• Read Received lines from the bottom up; trust the lines added by your own provider most, and check From, Reply-To and authentication results.
• Since 28 January 2025, RDAP has been the definitive registration-data service for ICANN gTLDs; country-code domains follow their own registries' rules, and registrant details are often redacted.
• An IP address is a connection, often shared, not a person.
• File signatures, timestamps and photo metadata are clues to cross-check, never proof on their own.
• Only inspect, test or change devices, accounts and systems you own or are explicitly authorized to work with — and pass leads to people with legal authority.

Sources

• ICANN — ICANN Update: Launching RDAP; Sunsetting WHOIS (27 January 2025)
• IETF — RFC 5322: Internet Message Format
• IETF — RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space
• IETF — RFC 1918: Address Allocation for Private Internets
• IETF — RFC 5321: Simple Mail Transfer Protocol
• Apple — Personal Safety User Guide: Manage location metadata in Photos
• Dr. Tahseen Al-Doori — Cyber Security Essentials, Chapter 21