Email Header Analysis and Sender Tracing

An email message consists of two parts separated by a blank line: the header section and the body. The header section is a series of name-value pairs, each on its own line (with long values wrapped using whitespace). Many headers are set by the sender's mail client or the originating mail server: From, To, Subject, Date, Message-ID, Reply-To, and Content-Type. These are client-controlled and can be freely set to any value the sender chooses. An attacker composing a phishing email can write any address in the From field.

The headers that matter most for forensic analysis are those added by servers in transit, because the sender's client cannot control what subsequent servers write. Every server that receives the message and passes it along prepends a new Received header at the top of the existing header block. This means the Received headers accumulate in reverse chronological order: the top Received line was added by the server closest to the recipient, and the bottom Received line was added by the first server to accept the message from the sender.

A typical Received line contains: the hostname or IP the message was received from, the hostname of the receiving server, the protocol used (SMTP, ESMTP, ESMTPS), and a timestamp in RFC 2822 format. A minimally informative example reads: Received: from mail.attacker.com (203.0.113.45) by mx.victim.com with ESMTP; Mon, 23 Jun 2025 14:22:01 +0530. The IP in parentheses is the address the receiving server observed the connection coming from. That IP is the forensic data point: it is what the server recorded, not what the sender declared.

The goal of Received-chain analysis is to identify the IP address from which the message first entered the public mail infrastructure. Starting from the bottom Received line, read the IP address recorded in parentheses after the from clause. This is the address the first public-facing receiving server observed. If the bottom line shows a private IP range (10.x, 172.16-31.x, 192.168.x), the message was submitted from inside a local network and the next line up is the first external hop.

Once the candidate IP is identified, look it up with WHOIS and in a Regional Internet Registry database. ARIN covers North America, RIPE NCC covers Europe and the Middle East, APNIC covers Asia-Pacific, LACNIC covers Latin America, and AFRINIC covers Africa. The lookup returns the organisation that holds the IP block, the allocation date, and contact details. If the IP belongs to a consumer ISP, the next step is a legal request for subscriber records. If it belongs to a cloud provider, VPN service, or Tor exit node, the interpretation changes: the IP identifies the service, not the individual.

Check the geolocation of the IP using a service such as MaxMind GeoLite2 or ipinfo.io. Geolocation is approximate, not reliable to city level, but country-level accuracy is generally high and can immediately flag whether the originating country is inconsistent with the claimed sender. A message claiming to be from a bank headquartered in one country but originating from an IP geolocated to a different continent is a strong indicator of fraud.

Modern mail systems record the outcome of authentication checks in the Authentication-Results header, added by the receiving server at each hop that performs the checks. A single Authentication-Results field can contain results for SPF, DKIM, and DMARC. The field is structured: the reporting server's name appears first, followed by each mechanism and its result.

SPF checks whether the IP address that connected to the receiving server is listed in the DNS TXT record of the domain in the Return-Path. Possible results: pass (authorised), fail (explicitly not authorised), softfail (the domain discourages but does not prohibit), neutral (the domain makes no claim), and none (no SPF record found). An SPF fail means the sending server was not authorised to send for the Return-Path domain. In a spoofed phishing email, the attacker typically sets the From to a legitimate domain but routes the message through their own server, producing SPF fail.

DKIM provides a cryptographic signature over specified header fields and the message body. The receiving server retrieves the public key from DNS and verifies the signature. A DKIM pass means the message was signed by the claimed domain and was not altered in transit. A DKIM fail means the signature did not verify, which could indicate tampering, key rotation that broke existing messages, or a forged DKIM-Signature header. A missing DKIM signature is recorded as none and is not itself suspicious, since many smaller mail servers do not implement DKIM.

DMARC combines both mechanisms with an alignment requirement: it requires that either the SPF-checked domain or the DKIM-signed domain aligns with the domain in the visible From header. If an attacker spoofs a From address at bank.com but routes through their own server, SPF checks their server's domain, not bank.com, so SPF alignment fails. If they have no DKIM key for bank.com, DKIM alignment fails too. DMARC therefore fails. The Authentication-Results header records dmarc=fail, along with the reason.

Spoofing covers several distinct techniques that header analysis can differentiate. In a direct domain spoof, the attacker sets the From header to an address at the exact target domain (from: admin@targetbank.com) while routing the message through their own server. This produces SPF fail and DMARC fail and is the simplest form to detect. If the target domain has published a strict DMARC policy (p=reject), compliant receiving servers will reject the message entirely; the investigator may encounter it only in mail server logs.

A lookalike domain spoof uses a domain registered to resemble the target: targetb4nk.com, target-bank.com, or targetbank.co. The attacker controls this domain and can configure SPF and DKIM to pass. Authentication checks pass legitimately; the attack succeeds by visual deception in the display name or domain. Investigators should check the exact From domain against the expected domain using string comparison, not visual inspection. Run WHOIS on the From domain: registration date, registrar, and registrant contact are all investigatively useful.

A display-name attack leaves the actual email address at a different domain but sets the display name to a trusted name: the From field displays as Finance Director <accounts@random-provider.com>. Mail clients that show only the display name, not the actual address, make this effective. The full raw From header reveals the real address. Investigators must always examine the raw header, not the rendered mail client view.

Manual parsing of a long Received chain is error-prone. Several free tools automate the process. Google Admin Toolbox Message Header Analyser parses the Received chain and renders each hop with timestamp deltas. MXToolbox Email Header Analyzer extracts the originating IP, checks it against common blocklists, and displays authentication results in a readable format. For investigators who need to process multiple messages, Python's email standard library can parse raw message files (eml format) programmatically, and the imaplib module can retrieve messages directly from a mail server.

After extracting the originating IP, look it up in threat intelligence sources. VirusTotal aggregates data from multiple security vendors and shows whether the IP has been associated with malicious activity. AbuseIPDB records reported abuse from that IP. Shodan shows open ports and services running at that IP, which can indicate whether it belongs to a mail server, a residential connection, a proxy, or a VPN endpoint. A VPN or proxy IP does not end the investigation: many VPN providers retain connection logs and will respond to valid legal process.

For domain lookups, use dig or nslookup to query the SPF record directly: dig TXT targetdomain.com. The SPF record begins with v=spf1 and lists the mechanisms. Querying the DMARC record: dig TXT _dmarc.targetdomain.com. The DMARC record includes the policy (p=none, p=quarantine, or p=reject) and the reporting addresses. A domain with p=none has not enabled DMARC enforcement; attackers can spoof it with no automatic rejection. A domain with p=reject has the highest protection: receiving servers compliant with DMARC will reject spoofed messages before they reach the inbox.

Identifying the originating IP address is not the end of the investigation: the IP belongs to a network block owned by a provider, and the provider holds the subscriber records that map the IP to a customer at a specific time. Obtaining those records requires legal process, and the process varies by jurisdiction. The critical information for the request is the IP address, the precise timestamp including time zone (UTC preferred), and the protocol (SMTP, typically on port 25 or 587).

In India, investigators operate under the Information Technology Act 2000 for cyber offences and under the Bharatiya Nagarik Suraksha Sanhita 2023 (which replaced the Code of Criminal Procedure) for procedural steps including production orders. Section 69 of the IT Act empowers authorised agencies to direct an intermediary to provide information. Section 91 of the Bharatiya Nagarik Suraksha Sanhita 2023 covers summons for documents and records. The Bharatiya Sakshya Adhiniyam 2023 (which replaced the Indian Evidence Act 1872) governs admissibility of electronic records, including the certificate under section 63 that authenticates electronic evidence for court proceedings.

In the United States, the Stored Communications Act (18 U.S.C. 2701 et seq.) governs access to stored electronic communications and subscriber records held by providers. A subpoena (18 U.S.C. 2703(c)(2)) can compel disclosure of basic subscriber information. A court order under 2703(d) compels records of account activity. A search warrant under 2703(a) is required for content. In the United Kingdom, the Investigatory Powers Act 2016 governs the interception of communications and acquisition of communications data; production orders for subscriber records are issued under the Police and Criminal Evidence Act 1984 or the Proceeds of Crime Act 2002 depending on the offence. In the European Union, the e-Evidence Regulation (Regulation (EU) 2023/1543) establishes European Production Orders for electronic evidence held by providers in any member state.