How to Detect Email Spoofing: Reading Headers, SPF, DKIM, and DMARC Results

Email spoofing is trivial to execute and still catches experienced users. The From address displayed in any mail client is just a header field — any mail server can put anything there. Authentication protocols (SPF, DKIM, DMARC) exist to make spoofing detectable, but only if you know how to read the results.

Here's how to analyze an email you've received and determine whether it's legitimate or spoofed.

Step 1: Get the Raw Headers

Every email carries a complete delivery history in its headers that most clients hide. Here's how to access them:

Gmail: Open the email → three-dot menu (⋮) → Show original → copy everything above the message body

Outlook: Open the email → File → Properties → Internet headers box

Apple Mail: View menu → Message → All Headers

Thunderbird: View menu → Message Source

Once you have the raw headers, paste them into the CyrusX Email Header Analyzer. It parses the delivery chain, extracts the originating IP, and checks SPF, DKIM, and DMARC authentication results automatically.

Step 2: Read the Authentication Results

Legitimate email from any modern mail provider will include an Authentication-Results header added by your receiving mail server. It looks like this:

Authentication-Results: mx.yourdomain.com;
  spf=pass [email protected];
  dkim=pass header.d=legitimate.com;
  dmarc=pass action=none header.from=legitimate.com;

SPF Result

spf=pass — The sending server is authorized in the domain's SPF record. The email came from a server the domain explicitly allows.

spf=fail — The sending server is NOT in the domain's SPF record. This is a hard fail. Spoofing indicator.

spf=softfail — The sending server failed, but the domain uses ~all instead of -all in their SPF record. Weaker indication, but still suspicious.

spf=none — The domain has no SPF record at all. Not conclusive, but increases risk profile.

DKIM Result

dkim=pass — A valid cryptographic signature from the signing domain was verified. The message wasn't modified in transit and came from an authorized server.

dkim=fail — The signature didn't verify. Either the message was modified, or the signature is fraudulent.

dkim=none — No DKIM signature present. Missing for messages from professional senders is suspicious.

dkim=temperror / dkim=permerror — DNS lookup failures or key configuration problems. Can be legitimate misconfiguration or an evasion technique.

DMARC Result

dmarc=pass — SPF and/or DKIM passed AND the authenticated domain aligns with the visible From address. The strongest positive signal.

dmarc=fail — Either the underlying authentication failed, or the authenticated domain doesn't align with the visible From address. Spoofing is likely.

Step 3: Trace the Originating IP

The Received headers form a chain showing every server the email passed through. They're added at each hop, with the most recent at the top and the original sender at the bottom.

Reading from bottom to top, the last Received header before leaving an internal network is the most reliable indicator of the true origin server.

A simplified example:

Received: from mail.legitimate-company.com (203.0.113.45)
  by mx.yourcompany.com; Fri, 11 Apr 2026 09:14:00 -0500

Received: from internal-relay.legitimate-company.com (10.0.1.5)
  by mail.legitimate-company.com; Fri, 11 Apr 2026 09:13:55 -0500

The Email Header Analyzer extracts the originating IP (203.0.113.45 in this case) and automatically runs an IP reputation check against it. If the IP belongs to a known spam network, bulletproof hosting provider, or has a high abuse score, that's a direct spoofing or spam indicator.

What Spoofed Email Headers Actually Look Like

Here's a real-world spoofed email pattern:

From: [email protected]
Received: from mail.some-vps-provider.ru (185.220.101.5)
Authentication-Results: mx.gmail.com;
  spf=fail smtp.mailfrom=some-vps-provider.ru;
  dkim=none;
  dmarc=fail action=none header.from=your-bank.com;

What this tells you:

• The visible From is your-bank.com
• The actual sending server is some-vps-provider.ru (no relationship to your-bank.com)
• SPF fails — that server isn't in your-bank.com's SPF record
• No DKIM signature — no cryptographic authentication at all
• DMARC fails — none of the authentication aligns with the From domain
• The action=none on DMARC fail means your-bank.com hasn't enforced a reject policy yet, so the message was delivered

The result: the email landed in your inbox because the domain hasn't moved from p=none to enforcement. The headers show clearly it's spoofed, but without enforcement, it gets through anyway.

Red Flags Beyond Authentication

Authentication is the definitive check, but visual inspection of headers can add context:

Mismatch between From and Reply-To The displayed sender is [email protected] but Reply-To: [email protected]. Replies go to the attacker's address, not the CEO's.

Time zone inconsistencies The email claims to come from your US-based bank but the Received headers show timestamps in CEST with a European IP. This doesn't prove spoofing but warrants investigation.

Unexpected sending infrastructure A message from PayPal should originate from IPs in PayPal's ASN. If the bottom Received header shows a Russian VPS or a residential ISP, that's wrong regardless of what the From address says.

No DKIM signature from a professional sender Major email providers — Google, Microsoft, SendGrid, Mailchimp — always sign outbound mail with DKIM. A message claiming to come from Gmail with no DKIM signature is suspect.

How to Check Suspicious Emails in Practice

1. Get the raw headers using the method above
2. Paste into the Email Header Analyzer — it extracts originating IP, parses the authentication chain, and flags issues automatically
3. Check SPF, DKIM, DMARC results — all three should pass for legitimate email from professional senders
4. Look up the originating IP using IP Reputation Lookup — a high abuse score or hosting on known bulletproof infrastructure is a strong indicator
5. Check the sending domain age with WHOIS Lookup — recently registered domains (days or weeks old) are a common phishing infrastructure tell

You don't need to read every header manually. The analyzer surfaces the critical signals. The interpretation is straightforward once you know what to look for.