What you need
The message itself (do not reply, click links or open attachments), a way to view its source in your mail program, and five minutes. Everything on the analysis side runs on this site: the header analyzer parses pasted text, and Email Forensics reads a saved .eml or Outlook .msg without uploading it.
Reading the result
Here is a trimmed set of headers from a typical spoof, as the analyzer would show them:
Authentication-Results: mx.example.org;
spf=pass smtp.mailfrom=bounce.example.net;
dkim=pass header.d=example.net;
dmarc=fail (p=NONE) header.from=example.com
From: "Example Bank Security" <[email protected]>
Return-Path: <[email protected]>
Reply-To: <[email protected]>
At first glance SPF and DKIM both pass. But they pass for example.net, a domain the attacker controls, while the reader sees example.com in the From line. DMARC is the check that compares the two, and it failed. The policy p=NONE explains why the message was delivered anyway: example.com has published DMARC in monitoring mode only. The Reply-To pointing at yet another domain is a second red flag, because your answer would go to the attacker.
A genuine message from the same bank would read spf=pass smtp.mailfrom=example.com or dkim=pass header.d=example.com, and dmarc=pass header.from=example.com.
For the Received chain, read the table from the bottom up. The bottom hop is where the message entered the mail system. If a message claiming to come from a European bank first appears on a residential IP address on another continent, that is worth more than any single header.
Common pitfalls
- Trusting the display name. "Example Bank Security" is free text. Only the address and the authentication results matter.
- Trusting any Authentication-Results line. Only the one stamped by your own provider counts. It is normally the topmost one and names your provider's server (
mx.example.orgabove). An attacker can add a fake "all pass" line further down. - Treating "pass" as "safe". A criminal can register a lookalike domain such as
examp1e.comand set up perfect SPF, DKIM and DMARC for it. Compare the domain letter by letter; the Sender Analysis tab in Email Forensics flags punycode and confusable characters. - Reading the analyzer's summary as a verdict. The Security card only counts which authentication headers are present, not whether they passed. Always read the actual
spf=,dkim=anddmarc=values. - Blaming forwarding on attackers. Forwarded mail often fails SPF, and mailing lists that edit the subject break DKIM. A failure on a newsletter you forward to yourself is not proof of spoofing.
Going further
If you own the domain being spoofed, publish SPF and DKIM, then DMARC, and tighten the policy from p=none to p=reject as explained in How Email Authentication Works: SPF, DKIM and DMARC. Report the message to your provider's phishing button so its filters learn from it.