Practice with national-level exam (FACT, FACT Plus, NET, CUET, etc.) mocks, learn from structured notes, and get your doubts solved in one place.
SMTP, POP3 and IMAP ports; reading Received headers bottom-up; SPF, DKIM and DMARC checks; PST, OST and mbox parsing; and the Indian IT Act and BNS provisions for prosecuting phishing and spoofed mail.
Email remains the single largest delivery surface for financial fraud in India. The CERT-In quarterly notes for 2024 and 2025 list phishing as the top single category of reported incidents, with banking-lookalike domains and HR-impersonation pretexts the dominant pretext types. The forensic question is rarely whether the mail arrived: the inbox has it. The forensic questions are who sent it, from which infrastructure, whether the From address was forged, and whether the chain of custody from inbox to charge sheet will survive Section 63 BSA scrutiny.
This topic walks the email evidence stack from wire to witness box. It covers the protocols and their ports, the MUA-to-MTA-to-MDA flow that puts a message on disk, the anatomy of an email header and the bottom-up methodology for reading the Received chain, the SPF, DKIM and DMARC authentication mechanisms, the spoofing indicators that drop out of those checks, the on-disk evidence containers (PST, OST, mbox, EML, MSG) and the tools that parse each, and the Indian statutory frame for prosecuting phishing under IT Act Section 66D and BNS 2023 Section 318. Throughout, the goal is to produce a report that the trial court can read on its own.
Three protocols, six ports, two security postures.
Email runs on three protocols that students have to memorise cold. SMTP carries mail outbound and server-to-server. POP3 and IMAP carry mail inbound to the client. Each has a cleartext default port and a TLS-protected variant.
| Protocol | Role | Cleartext port | Implicit TLS port | STARTTLS variant | What sits on the wire |
|---|---|---|---|---|---|
| SMTP (server-to-server) | Relay between MTAs | 25 | (none in common use) | Opportunistic, on 25 | Envelope, headers, body, in cleartext unless STARTTLS negotiates |
| SMTP submission | Client to MTA, authenticated | (587 typical) | (465 SMTPS legacy / now common) | 587 with mandatory STARTTLS | Same payload, plus SASL credentials over TLS |
| POP3 | Pull and delete mailbox | 110 | 995 (POP3S) |
From compose button to inbox, with audit lines along the way.
A single message traverses several agents before it lands in the recipient's mailbox. Each agent is a candidate evidence source.
The grammar of the hop trail.
The header block contains audit lines and metadata lines. The audit lines (Received, Authentication-Results, X-Originating-IP, X-Sender-IP) carry the forensic content; the metadata lines (From, To, Cc, Bcc, Date, Subject, Message-ID, Return-Path, Reply-To, MIME-Version, Content-Type) describe the message itself.
| Header | Set by | Investigative use |
|---|---|---|
| Received | Each MTA on the path | Reconstruct the hop trail. Read bottom-up. |
| Return-Path | Inbound MTA from MAIL FROM (the envelope sender) | Compare against the visible From. Mismatch is a spoofing indicator. |
| From | MUA, attacker-controllable | Display name and address shown to the recipient. Not trustworthy on its own. |
| Reply-To | MUA, attacker-controllable | Where replies go. Phishing often uses Reply-To to redirect to a different mailbox. |
| Message-ID | Sending MTA | Unique identifier. Useful for de-duplication and for cross-referencing MTA logs. |
| Date |
What the inbound MTA actually checks.
The three authentication mechanisms answer three different questions. Each is published in DNS by the sending domain owner. Each is verified by the receiving inbound MTA. Failure modes are distinct.
SPF (Sender Policy Framework) asks: is the connecting IP allowed to send for this domain? The domain owner publishes a TXT record like v=spf1 ip4:203.0.113.0/24 include:_spf.google.com -all. The receiver compares the SMTP connecting IP against the listed IPs and include-chains. A pass means the connecting IP is on the list; a fail means it is not; softfail (~all) means the domain owner is still testing. SPF aligns to the MAIL FROM (Return-Path) domain, not to the visible From.
DKIM (DomainKeys Identified Mail) asks: was this message cryptographically signed by a key authorised by the domain in the d= tag? The sending MTA computes a signature over selected header fields and the body, places it in the DKIM-Signature header, and the receiver fetches the public key from DNS (selector._domainkey.signing-domain TXT record) and verifies. A pass proves the message has not been altered in flight and that the signing domain controls the signing key.
DMARC (Domain-based Message Authentication, Reporting and Conformance) asks: does at least one of SPF or DKIM pass and align to the visible From domain, and if not, what should the receiver do? The domain owner publishes a TXT record like v=DMARC1; p=reject; rua=mailto:dmarc@example.in; ruf=mailto:dmarc-fo@example.in. The p= tag is the policy: none (monitor only), quarantine (deliver to spam), reject (refuse). The rua and ruf tags are the aggregate and forensic reporting addresses.
| Mechanism | Aligned to | Pass condition | Forensic value |
|---|---|---|---|
| SPF | Return-Path / MAIL FROM domain |
What the report quotes to prove forgery.
A spoofed-mail finding is a structured argument. The report needs to walk each indicator, quote the header value, and connect it back to the substantive offence under the IT Act or BNS.
The recurring indicator set:
The phishing-page evidence pairs with the email evidence. The mail carries the lure; the click trail and the captured page live in the browser. See our Web Browser Forensics topic for the click-side analysis; the two reports are usually annexed together in an Indian phishing charge sheet.
The phishing prosecution path in India runs through two main provisions:
Containers, parsers, and what the provider holds.
The mailbox lives on disk in one of a small number of container formats. The examiner needs to know which format applies to which client and how to parse each without altering the original.
| Container | Used by | Holds | Parser of choice |
|---|---|---|---|
| PST | Outlook (cached or archive) | Folders, messages, attachments, calendar, contacts | libpff (open source), Aid4Mail, Outlook Forensics, AXIOM Email |
| OST | Outlook against Exchange / Microsoft 365 | Local synced copy of the Exchange mailbox | libpff (with OST support), Aid4Mail, Magnet AXIOM |
| mbox | Thunderbird, Apple Mail (legacy), Unix MUAs | Concatenated RFC 5322 messages in one file per folder | MailXaminer, Python mailbox module, AXIOM Email |
| EML | Outlook Express, generic export | One message per file | Any text editor, MailXaminer |
The default cleartext port for SMTP server-to-server relay is:
| On 110 |
| USER/PASS, then message bodies |
| IMAP | Server-side mailbox with folders | 143 | 993 (IMAPS) | On 143 | LOGIN, then per-folder UID and body streams |
The choice between POP3 and IMAP shapes the on-disk evidence picture. POP3 traditionally downloads and deletes; the inbox of evidentiary value sits on the client. IMAP keeps the mailbox on the server and the client holds a synchronised copy (an OST for Outlook against Exchange, a local mailbox for Thunderbird against IMAP). Webmail is yet a third pattern: nothing of evidentiary value sits on the client beyond the browser cache (covered in our Web Browser Forensics topic). The acquisition plan has to match the protocol.
A practical Indian context point: many corporate phishing investigations involve submission on 587 (the attacker authenticated to a compromised mailbox) rather than open-relay on 25. The MTA log on the submission server then carries the SASL username, the source IP and the timestamp, which combined with login telemetry from the same provider often identifies the attacker's foothold account.
Each agent writes one Received header onto the message as it touches it. The chain of Received headers therefore reads bottom-up: the bottom-most Received was written first (by the sending MTA) and the top-most was written last (by the receiving MTA, immediately before delivery). Reading top-down inverts the timeline, which is the most common rookie error in header tracing.
The Authentication-Results header, written by the inbound MTA, summarises the SPF, DKIM and DMARC outcomes for that delivery. It is the single most useful line in the header for triage. A line that reads spf=fail dkim=fail dmarc=fail on a message claiming to come from a major Indian bank's domain is the first piece of evidence the report should quote.
| Sending MUA |
| Sender-claimed time. Compare against Received timestamps for clock skew or fabrication. |
| X-Originating-IP | Webmail providers (often) | Connecting client IP for webmail send. Empty or RFC1918 is a flag. |
| Authentication-Results | Inbound MTA | SPF / DKIM / DMARC outcomes summarised. |
| DKIM-Signature | Sending MTA | Cryptographic signature. The d= tag is the signing domain. |
| Content-Type / MIME-Version | Sending MUA | Structure of multipart bodies, attachments, alternative HTML/plain. |
The bottom-up method in five steps.
The X-Originating-IP header deserves a special note. Webmail providers (Yahoo Mail historically, several Indian webmail providers still) write the client connecting IP into X-Originating-IP. If this header carries an RFC1918 private address (10.x, 172.16-31.x, 192.168.x) the value is being reported from inside a NAT and the true source IP needs a separate subpoena to the provider. If the header is absent, the provider does not write it.
| Connecting IP listed in sender's SPF record |
| Strong evidence on connecting infrastructure; weak on identity (only the envelope sender domain). |
| DKIM | d= tag in DKIM-Signature header | Signature verifies against the published public key | Proves integrity in flight and key custody; the d= tag may differ from the visible From. |
| DMARC | Visible From domain | SPF or DKIM pass and align to From domain | Strong evidence on the visible From. A DMARC fail on a banking domain is the standout phishing flag. |
| Authentication-Results | Receiver records all three | Summary line; values are dkim=pass/fail, spf=pass/fail, dmarc=pass/fail | First triage line for the examiner. |
For an Indian banking-phishing case the typical pattern in the header is From: HDFC Bank <alerts@hdfc-secure-login.in> with Return-Path: <bounce@cheap-vps-host.example> and Authentication-Results: spf=fail (sender IP not in SPF) dkim=none dmarc=fail (p=reject). That single Authentication-Results line is enough to open the spoofing finding in the report; the rest of the analysis is corroboration. CERT-In advisories under the CDB-2024-* series have repeatedly published indicator lists for HDFC, ICICI and State Bank lookalike-domain campaigns, and the I4C portal at cybercrime.gov.in is the citizen-side complaint linkage that the IO references in the FIR.
The procedural anchor is BNSS 2023 (charge sheet under Section 193, FSL report annexure, see our BNSS topic) and the admissibility anchor is BSA 2023 Section 63 (statutory certificate for the email exhibit, see our BSA topic). The I4C portal (cybercrime.gov.in) is the citizen-complaint linkage that often originates the FIR.
| MSG |
| Outlook native export |
| One message with attachments, OLE compound file |
| libpff, Outlook itself, AXIOM |
| Maildir | Postfix-style Unix mailbox | One file per message in cur/new/tmp | Standard text tools, MailXaminer |
The acquisition discipline is the same for every container: image the file with a hash, work on a copy, never write to the original. PST and OST files routinely sit in %USERPROFILE%\AppData\Local\Microsoft\Outlook on Windows; Thunderbird mbox files sit under the Mail or ImapMail subfolders of the profile directory.
Webmail is a different proposition. The mailbox is the provider's, not the client's. The on-disk artefacts on the client are limited to browser cache, IndexedDB and any locally-downloaded EML / MSG files. The forensic source of truth is the provider, and the legal access path is a subpoena.
MTA-side logs are the third evidence source and the one most often missed. Postfix maillog (/var/log/maillog or /var/log/mail.log), Sendmail's queue and syslog entries, and the Exchange / Microsoft 365 message-tracking log all carry per-message records with queue ID, source IP, recipient list, size and SPF/DKIM outcomes. On the sending side these logs identify the foothold account; on the receiving side they corroborate the headers in the message itself.
The reporting toolset that most Indian state cyber-forensic units rely on includes MailXaminer for unified PST/OST/mbox/EML analysis, OST-PST Converter for conversion when a parser needs PST input, Aid4Mail for high-volume PST processing, EmailTrackerPro and eMailTracker for header analysis, MxToolbox as a quick online SPF/DKIM/DMARC tester, and Magnet AXIOM Email for integrated workflows. The Indian-context cross-link is that CERT-In phishing advisories (the CDB-2024 series and onwards) publish indicator lists that the examiner can match the case email against; the I4C portal at cybercrime.gov.in is the citizen-side complaint endpoint that often originates the FIR.