Phishing Defense Checklist — Verify Before You Trust an Email

Objective

Decide, in minutes, whether a suspicious email is a phishing attempt — and contain it before anyone clicks, replies or shares credentials. The outcome is a verdict + containment action, not just a label.

When to use

Run this checklist when an email shows any of: unexpected sender, urgency or fear language, a request to click or enter credentials, an attachment you were not expecting, or a domain that looks close to a legitimate one. It also applies proactively before acting on any link-bearing message.

Prerequisites

• Access to the raw message (EML or “show original” export).
• Local-only tools — do not paste the full header or body into unknown online services.
• A ticketing or reporting channel (SOC mailbox, abuse mailbox, security team chat).

Step-by-step checks

1. Sender identity

• Does the From display name match the email address? (Display names are free text and can lie.)
• Does the Reply-To match the From domain? A divergent Reply-To redirects replies to the attacker.
• Is the Return-Path / envelope sender different from the From header? Mismatch is a spoofing signal.
• Have you contacted the sender through a known, separate channel to verify? Never verify inside the same thread.

2. Header & authentication signals

• SPF (spf=pass/fail) — did the sending server pass the domain policy?
• DKIM (dkim=pass/fail) — was the message signed by the claimed domain?
• DMARC (dmarc=pass/fail) — did the alignment hold, and what policy did the domain publish?
• One or more fails = strong spoofing signal. Pass does not mean the message is safe — attackers use compromised or similar-looking domains.
• Review the Received chain: does the path make sense? Gaps or a single hop for an “important” message are suspicious.

3. Domain inspection

• Check the displayed domain against the actual href target (hover, never click).
• Look for typosquatting: rnicrosoft, paypa1, extra subdomains, or domains under a different TLD.
• Look up the domain with DNS — is SPF/DMARC published? A brand-impersonating domain without these is a risk signal.
• Check the domain reputation — is it newly registered or associated with spam/phishing history?

4. URL inspection

• Extract every link and analyze the URL structure (protocol, host, path, query) with a local analyzer.
• Reject the message if the URL is obfuscated: embedded credentials, @ in the host, raw IP host, or suspicious fragments.
• Never open the URL directly on a managed asset. Open it, if at all, in an isolated or sandboxed environment.

5. Attachments & indicators

• Treat unexpected attachments as hostile until inspected; check the file hash.
• Extract indicators (sender address, domains, URLs, hashes) into a structured list.
• Cross-check each indicator against reputation/IOC lookups and record the source of each result.

What indicates risk

• From/Reply-To/Return-Path divergence, failed SPF/DKIM/DMARC, recent-domain or low-reputation sender, obfuscated URL patterns, urgent credential requests, or a hash that matches known-malicious samples.

What is normal

• Alignment between From/Reply-To/Return-Path, passing authentication, a consistent Received chain, and a domain that matches what you see in the address bar of the expected service.

Tools

• Email Header Analyzer — inspect headers locally, no upload.
• URL Analyzer — parse a URL structure without fetching it.
• URL Reputation — check a link against intelligence before clicking.
• DNS Lookup — verify SPF/DMARC and domain records.
• IOC Lookup — check extracted indicators against known intelligence.
• Hash Checker — verify attachment hashes.

Evidence

Record per message: raw header excerpt, From/Reply-To/Return-Path, SPF/DKIM/DMARC results, inspected domains and URLs, indicator list with lookup results and sources, and the timestamp of each check.

Escalation

Escalate immediately when: credentials were entered, a link was clicked on a managed asset, an attachment was opened, or the message targeted a privileged account. Preserve the raw message (EML) untouched for forensics.

Mitigation

• Block the sender and domain at the gateway.
• Quarantine the message; notify recipients who received it.
• If credentials may have been exposed: force a password reset and revoke sessions; review sign-in logs.
• If a link was clicked: isolate the device and begin an investigation.

Verification

• Confirm the message is blocked/quarantined and no recipient clicked or replied.
• Verify authentication-related remediation (e.g., DMARC policy gaps) with your mail administrator.
• Log the case and the outcome so patterns can be correlated later.

Start a new investigation to track findings, evidence and the containment outcome per message.

References

• CISA — Secure Our World: Phishing
• CISA — Compromised Credentials Alert
• RFC 7489 — DMARC
• DMARC.org