How to Detect a Spoofed Email — Step by Step OSINT Tool Guide

Email spoofing is one of the most common tactics in phishing, business email compromise (BEC), and social engineering attacks. The sender address shown in an email client can be set to anything the sender chooses — it is not verified by default. Detecting a spoofed email requires looking beyond the visible "From" field and into the email headers themselves.

This guide walks through the process step by step, using the kind of header analysis that investigators and security analysts perform in real cases.

What Is Email Spoofing?

Email spoofing is the practice of sending an email with a forged sender address. The SMTP protocol does not require the "From" address to match the actual sending server. This means anyone with access to a mail server or scripting tools can send an email that appears to come from any address.

Spoofing is used in:

• Phishing campaigns — impersonating banks, employers, or trusted services
• Business Email Compromise (BEC) — impersonating executives to authorize fraudulent payments
• Reputation attacks — sending offensive content that appears to come from a target
• Credential harvesting — directing recipients to fake login pages

Why Spoofed Emails Matter in Investigations

In an investigative context, determining whether an email is spoofed can be the difference between identifying the actual threat actor and pursuing a false lead. When an email appears to come from a known contact, the natural assumption is that it is genuine. Spoofing exploits this assumption.

Investigators encounter spoofed emails in:

• Fraud cases where wire transfers were authorized by email
• Harassment investigations where the apparent sender denies involvement
• Data breach analysis where phishing was the initial attack vector
• Internal investigations where email origin is disputed

Step 1: Get the Full Email Headers

The visible information in an email client — the "From" name, subject line, and body — can all be forged. The email headers contain the technical routing data that reveals where the message actually originated.

Once you have the raw headers, paste them into a header analysis tool to parse the routing information into a readable format.

Step 2: Trace the Routing Path

Email headers contain a series of Received: lines that record each server the message passed through. These lines are added from bottom to top — the bottom-most Received: header is the first server that handled the message.

What to look for:

• The originating server — does it belong to the claimed sender's domain?
• Unexpected relays — did the email pass through servers in unexpected countries or on unknown infrastructure?
• Time gaps — are there unusual delays between hops that might indicate queuing on a compromised server?

A legitimate email from user@company.com should originate from a server associated with company.com. If the first hop is an unrelated IP address or a known bulk-mail service, that warrants further investigation.

Step 3: Check SPF, DKIM, and DMARC Results

Modern email authentication relies on three complementary mechanisms. The results of each check are recorded in the email headers.

SPF (Sender Policy Framework) verifies that the sending server's IP address is authorized to send mail for the claimed domain. The domain owner publishes a DNS record listing which servers are permitted.

DKIM (DomainKeys Identified Mail) uses a cryptographic signature attached to the email. The receiving server checks this signature against a public key published in DNS. If the signature verifies, the email has not been altered in transit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with a policy. It tells receiving servers what to do when authentication fails — accept, quarantine, or reject.

Step 4: Examine the Originating IP

The originating IP address is typically found in the bottom-most Received: header or in the X-Originating-IP header (if present). This IP represents the server or client that first submitted the email to the mail system.

Look up the originating IP to determine:

• Who owns the IP block — is it the claimed sender's organization, a cloud provider, or a residential ISP?
• Geographic location — does it match the expected location of the sender?
• Reputation — is the IP associated with known spam or phishing activity?
• VPN or proxy detection — is the IP a known VPN endpoint or open proxy?

An email claiming to be from a corporate domain but originating from a residential IP in a different country is a strong spoofing indicator.

Step 5: Look for Header Inconsistencies

Spoofed emails often contain subtle inconsistencies that legitimate emails do not. Look for:

• Mismatched domains — the From: header says one domain, but the Return-Path: or Reply-To: uses a different domain
• Missing headers — legitimate corporate email systems add consistent headers (e.g., X-Mailer, Message-ID matching the domain); spoofed emails often lack these or have generic values
• Unusual Message-ID format — the Message-ID domain should match the sending domain; a mismatch suggests the email was crafted on a different system
• Multiple authentication failures — if SPF, DKIM, and DMARC all fail, the email is very likely not from the claimed sender
• Encoding anomalies — character encoding or MIME structure that differs from the sender's normal patterns

Common Spoofing Patterns to Watch For

Several patterns recur across spoofing campaigns:

• Display name spoofing — the display name shows "CEO Name" but the actual email address is an unrelated domain (e.g., ceoname@randomdomain.com)
• Cousin domain spoofing — using a lookalike domain such as company-inc.com instead of companyinc.com
• Reply-To manipulation — the email appears to come from a legitimate address, but the Reply-To: header directs responses to an attacker-controlled address
• Compromised third-party infrastructure — using legitimate but compromised email services to send spoofed messages, which may pass SPF
• Header injection — exploiting poorly configured mail servers to inject custom headers that make the email appear legitimate

What a Spoofed Email Looks Like in Practice

In a typical spoofed email investigation, you might see:

• The From: field shows finance@trustedcompany.com
• The Return-Path: shows bounce@bulk-mailer-service.net
• SPF result: softfail (the sending IP is not in trustedcompany.com's SPF record)
• DKIM: none (no DKIM signature present, or signed with a different domain)
• DMARC: fail (neither SPF nor DKIM aligns with the From: domain)
• The originating IP resolves to a VPS provider in a country where the company has no operations

Each of these indicators individually might have an innocent explanation. Taken together, they present a clear picture of spoofing.