How to read email headers for spoofing

The visible From address is presentation. Investigation begins by comparing it with Reply-To and Return-Path, reading Received hops from the bottom upward, and reviewing SPF, DKIM and DMARC alignment.

SPF checks whether an IP is authorized for the envelope-sender domain.
DKIM verifies a cryptographic signature from a signing domain.
DMARC evaluates alignment and the domain owner’s policy.
A pass is useful evidence but does not prove the request itself is honest.

Paste raw headers into the Email Header & BEC Analyzer.

Start with the original message

Copy the full raw headers from the message in your own mailbox. In Gmail on desktop, use the message menu and Show original. A forwarded screenshot omits the routing information you need; an inline forward may describe the forwarder rather than the original sender. Save the message before changing it, and remove personal addresses before sharing a report publicly.

Worked example: a plausible supplier request

Suppose a message shows From: accounts@example.com, but Reply-To points to billing@example.net. That difference deserves an independent check, especially if the message changes bank details. It is not enough to declare fraud: a supplier may use an external billing system. Call the supplier using a number in an existing contract, not the number or signature in the new message. Ask them to confirm the change without reading sensitive account information to an unverified caller.

Read authentication in context

Look for Authentication-Results added by your receiving mail service. An attacker can insert lookalike fields earlier in a message, so not every pasted pass result is trustworthy. SPF concerns the envelope sender, which can differ from the visible From address. DKIM concerns the signing domain and signed content. DMARC checks alignment with the visible From domain. Forwarding and mailing lists can affect authentication, while a compromised legitimate mailbox may pass all three checks.

What our analyzer can establish

The analyzer extracts header fields and flags mismatches for inspection. Pasted text cannot independently re-run the receiver’s SPF evaluation or verify a DKIM signature without the relevant message bytes and keys. Treat extracted authentication labels as claims recorded in the header. Received lines are usually examined from bottom to top, but only the portion inserted by trusted infrastructure is reliable. A clean-looking header never confirms a payment instruction.

A useful decision record

Record the original sender, reply destination, authentication results, the requested action and the independent confirmation channel. If the instruction remains unconfirmed, stop the payment and escalate through your organization’s established process. Preserve the original message and report suspicious mail to your provider. Avoid replying with passwords, verification codes or customer records.