Spotting a Spoofed Email: Headers, SPF, DKIM & DMARC

Email spoofing is cheap, common, and the entry point for most phishing and business email compromise attacks. The sender field in your inbox is essentially a label anyone can write — the real proof lives in the raw headers and authentication results. If you know where to look, you can confirm whether a message genuinely came from the domain it claims, usually in under a minute.

Quick visual checks before opening headers

Before digging into technical details, a few surface-level signals catch a large portion of spoofed mail:

• Display name vs. actual address — A message from PayPal Support <billing@secure-paypa1.com> is an obvious forgery. The display name is free text.
• Reply-To mismatch — If the From address is ceo@yourcompany.com but Reply-To points to a Gmail or unknown domain, treat it as hostile.
• Unusual urgency or payment instructions — Wire transfers, gift cards, or password resets you didn't request.
• Lookalike domains — rnicrosoft.com instead of microsoft.com, or extra TLDs like paypal.security-login.co.

These don't confirm spoofing on their own, but they tell you which messages deserve a deeper look.

Open the raw email headers

Every email carries a full header block that records the servers it passed through and the authentication results those servers calculated. Getting to it depends on your client:

• Gmail: Open the message → three-dot menu → Show original.
• Outlook (desktop): Open the message → File → Properties → Internet headers.
• Outlook.com / Microsoft 365 web: Open the message → three-dot menu → View → View message source.
• Apple Mail: View → Message → All Headers.
• Yahoo: More → View raw message.

Copy the entire block — from the first Received: line down to the start of the body. That's your evidence.

The four header fields that decide spoofing

1. Authentication-Results

This is the single most important line. It looks like:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=newsletter@stripe.com;
  dkim=pass header.i=@stripe.com;
  dmarc=pass header.from=stripe.com

You want all three — spf=pass, dkim=pass, and dmarc=pass — and the domains on the right must match the domain in the visible From address. A pass on SPF for bounce.marketing-saas.net tells you nothing if the From says support@yourbank.com.

2. Return-Path

Also called the envelope sender or MAIL FROM. Legitimate mail almost always uses a Return-Path on the same organizational domain as the From address (or a known bounce subdomain). A Return-Path of bounces+random@sendgrid.net on a personal email from your boss is a red flag.

3. Received chain

Read these bottom-to-top — the bottom Received: is the original sending server. Look for:

• An originating IP that geolocates somewhere unexpected.
• A sending hostname that doesn't match the claimed sender domain.
• Open relays, residential IPs, or hosts with no reverse DNS.

4. DKIM-Signature

The d= tag identifies which domain signed the message. If a message claims to be from amazon.com but DKIM was signed by d=cheapmailer.ru, that's spoofing — or at minimum, not a message Amazon actually sent.

Using an analyzer instead of reading line by line

Parsing headers manually works, but it's error-prone — especially with long Received chains and multiple Authentication-Results lines added by forwarders. Paste the raw headers into the AXOX Hub Email Header Analyzer and you get the SPF, DKIM, and DMARC verdicts, the originating IP, the delivery path, and any alignment failures in a clean breakdown. It's faster and harder to misread than scanning Authentication-Results by eye.

Checking the domain's own anti-spoofing posture

If you administer a domain, you can verify whether you're publishing the records that make spoofing detectable in the first place. Run these from a terminal:

1. SPF: dig TXT yourdomain.com — look for a record starting with v=spf1. End it with -all (hard fail) for the strongest protection.
2. DKIM: dig TXT selector._domainkey.yourdomain.com — selectors vary by provider (Google uses google, Microsoft 365 uses selector1).
3. DMARC: dig TXT _dmarc.yourdomain.com — a policy of p=reject tells receivers to drop unauthenticated mail outright.

Without DMARC, even perfect SPF and DKIM can be bypassed because alignment isn't enforced.

Worked example: catching a fake invoice

Say you receive an invoice from accounts@acme-corp.com. Opening the headers shows:

From: Acme Billing <accounts@acme-corp.com>
Return-Path: <refund@mailer-99.xyz>
Authentication-Results: spf=pass smtp.mailfrom=mailer-99.xyz;
  dkim=none; dmarc=fail header.from=acme-corp.com
Received: from vps-3344.lowcosthost.ru ([45.x.x.x])

Diagnosis:

• SPF passed — but for mailer-99.xyz, not acme-corp.com. That's an alignment failure.
• DKIM is missing entirely.
• DMARC failed, which is the authoritative verdict.
• The originating IP is a Russian VPS, not Acme's mail infrastructure.

This message is spoofed. The right action is to report it to your security team, not to pay the invoice or click anything.

Edge cases that aren't actually spoofing

Some legitimate scenarios produce results that look suspicious until you understand them:

• Mailing lists rewrite From or add via list.example.org — DMARC often fails as a result, which is why many lists rewrite the From header entirely.
• Forwarded mail can break SPF because the forwarding server's IP isn't in the original domain's SPF record. ARC headers exist to preserve original authentication results across hops.
• Third-party senders (Mailchimp, SendGrid, HubSpot) require the sending domain to authorize them in SPF and publish DKIM keys — misconfiguration here causes false positives for spoofing.

When the visible From, Return-Path, DKIM d=, and DMARC alignment all point to the same organizational domain, the message is authentic. When they diverge and DMARC fails, you're looking at a spoof.

Run your suspicious message through the analyzer

Pop the raw headers into the free AXOX Hub Email Header Analyzer and get a verdict on SPF, DKIM, DMARC alignment, originating IP, and the full delivery chain in seconds — no signup, no install.