Sherlock Forensics Email Header Analyzer Trace Email Origins

Phishing analysis on a suspicious email follows a repeatable four-step workflow: header forensics, SPF DKIM DMARC authentication review, URL extraction with threat scoring and attachment metadata surfacing. Phishing analysis at this layer is the practical core of email forensics for IT-admin spam triage and security-team incident response and a complete phishing analysis pass takes minutes per message once the workflow is familiar. The phishing analysis output feeds the downstream email evidence chain. Each step surfaces a different signal class. Together they answer the buyer's two questions: is this phishing email legitimate and if not, what attack does it represent. The same email investigation workflow covers IT-admin spam triage, security-team incident response and forensic examiner work for compliance audits.

Header forensics cross-correlates RFC-5322 fields: From, Reply-To, Return-Path and the Received chain. A spoofed phishing email typically shows mismatches between these fields (legitimate sender domain in From and attacker-controlled domain in Return-Path or the inverse pattern). SPF DKIM DMARC authentication results in the Received headers confirm whether the claimed sending domain actually authorized the message. SPF DKIM DMARC checks bypass attempts (typo squatting, lookalike domains, Unicode homoglyphs) show up in the header forensics output as authentication failures and visible header-field drift.

URL extraction collects every link inside the suspicious email, unwraps link-shorteners (bit.ly, t.co, ow.ly) and traces redirect chains. Phishing analysis at this layer often catches the malicious URL even when the email body looks legitimate. Attachment metadata surfacing reads the filename, claimed MIME type, declared size and attachment count from the email headers. For the actual file-byte inspection (file-type validation against magic bytes, embedded macro detection, JavaScript or VBA payload analysis, PDF threat scanning) hand the attachment to the appropriate downstream Sherlock tool. PDF attachments go to Sherlock Forensics PDF Editor for PDF threat scanning. Image attachments go to Sherlock Forensics Metadata Inspector for EXIF and embedded-payload checks. The combined phishing email investigation output drops into the incident response workflow as a documented timeline.

Email forensics covers four high-leverage use cases beyond casual phishing triage. Incident response email analysis processes the suspicious email from a compromised user's mailbox to determine initial-access vector: header forensics tells you whether the attacker spoofed an existing partner, the URL extraction tells you what landing page or payload the user was directed to and the attachment metadata surfaces what file types arrived for downstream byte-level analysis. Incident response email analysis at the inbox edge typically saves hours of downstream forensic work because it scopes the compromise immediately.

Email forensics for legal hold preserves the email evidence with chain of custody documentation suitable for litigation. Sherlock's email analyzer surfaces every authentication result, every header drift signal and every URL/attachment artifact in a structured output that downstream review platforms ingest as email evidence. Email chain of custody at this stage covers the authenticity proof that opposing counsel will challenge: the From-field signature path, the Received chain, the SPF DKIM DMARC verification results. For the cross-product PST + email forensic workflow see our PST Viewer and the deleted email recovery guide.

Compliance audit email forensics work covers HIPAA, SOX, GDPR and FINRA regulated environments where email authentication enforcement matters. The same SPF DKIM DMARC authentication results that catch phishing email attempts also document whether the organization's outbound email is properly authenticated for regulatory reporting. Phishing campaign attribution is the final email forensics use case: correlate header artifacts (Received chain signatures, X-Mailer strings, time-zone anomalies) across multiple suspicious emails to identify the same threat actor across multiple targets. The combined email forensics workflow feeds incident response email investigations, legal hold productions and compliance reporting from one tool. Background on the mid-market vs enterprise tier positioning that applies here as well is in our Cellebrite vs Magnet AXIOM 2026 comparison.

SPF DKIM DMARC is the email authentication trifecta that determines whether a claimed sender is actually who the From header says it is. Each of the three protocols answers a different question and the SPF DKIM DMARC results in the email headers tell a forensic examiner exactly which authentication path passed and which failed. SPF DKIM DMARC bypass attempts are common in phishing email campaigns, so reading these results correctly is the practical core of email forensics.

SPF (Sender Policy Framework)

The SPF record at the claimed sender's domain lists the IP addresses or hostnames authorized to send mail on that domain's behalf. Email Analyzer reads the SPF record check result from the Received-SPF header: pass, fail, softfail, neutral or none. A pass means the sending IP matches the domain's SPF record. A fail means the IP is explicitly not authorized; this is a strong phishing signal. Softfail is a weaker negative signal (the domain publishes but does not enforce). Neutral and none indicate the domain has not configured SPF, which is itself a red flag for a regulated industry sender.

DKIM (DomainKeys Identified Mail)

DKIM signature verification proves the email content was signed by the claimed sending domain's private key. The DKIM signature in the email header includes the signing domain, the selector (which DKIM key) and a cryptographic hash of the relevant headers and the body. A passing DKIM signature means the email was not tampered with in transit and was authorized by the sending domain. A failing DKIM signature can mean the content was modified (forwarded, edited or rewritten in transit) or the signature was never valid (signing domain mismatch, common in phishing). Email forensics treats DKIM signature failures as high-signal evidence.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC combines SPF and DKIM with a published policy at the claimed sender's domain. The DMARC record specifies p=reject (drop failing messages), p=quarantine (route to spam) or p=none (monitor only, take no action). DMARC report aggregate data flows back to the sender's listed reporting address so the domain owner can see who is sending mail in their name. The DMARC report stream is the long-term phishing-attribution evidence channel for organizations enforcing DMARC across their domains. Email Analyzer surfaces the DMARC policy and the pass/fail authentication result from the Authentication-Results header. A DMARC pass with strict alignment is the strongest authentication signal; a DMARC fail with p=reject and the message still arrived means the recipient mail server did not honor the policy, which is its own forensic finding.

Honest scope on SPF DKIM DMARC authentication forensics: Sherlock Forensics Email Analyzer surfaces the SPF DKIM DMARC results from the email header that the recipient mail server already computed. It does not re-run the SPF DKIM DMARC queries against current DNS (that requires network access and a synchronized point in time with the original delivery). For forensic work this matters: if the suspect domain's SPF, DKIM or DMARC record has been changed since the email was received, the header forensics still reflects the state at delivery. That is the right forensic posture.