PRIVACY NEEDLE PLAY · LEARNING RESOURCES
Six phishing email examples and legitimate messages explained
A request becomes trustworthy through independent verification, not through a familiar display name or polished writing. These six examples are drawn from the game’s original fictional scenarios. Each explanation identifies the facts behind the decision; the same surface feature can mean something different in another context.
Training examples only. All names and addresses below are fictional. The destinations are displayed as text and are not links.
EXAMPLE 01 · Bank security
A security alert
The independently verified context
You bank with fictional Sable Bank. Your saved banking address is bank.example.com. You did not initiate a verification request.
Decision: phishing
The message asks for your banking password and one-time code through a different domain. The deadline adds pressure. Open your saved banking app or contact the bank through a number you already trust; do not use the message link.
Takeaway: A bank name in an address is not proof of ownership. Never give an unsolicited sender your password or one-time code.
EXAMPLE 02 · Delivery
A delivery update
The independently verified context
You placed order HP-2408 yesterday. Your saved retailer receipt and parcel app independently show the same tracking reference and delivery window. parcel.example.com is the carrier address in that receipt.
Decision: legitimate
The message matches an order you placed and a tracking status you independently checked in the app. It requests no secret or additional payment. The classification relies on this verified context, not on a logo or polished writing.
Takeaway: Match delivery messages against your actual orders using the app or a saved retailer address.
EXAMPLE 03 · Business email compromise
A payment discussion
The independently verified context
Your company requires two-person payment approval and a call to a saved number for new beneficiaries. The finance director has not approved any acquisition payment in the verified finance system.
Decision: phishing
A familiar sender address can be spoofed or a mailbox compromised. This request bypasses approvals, introduces an unverified beneficiary and discourages a callback. Verify with the director through the established number.
Takeaway: A familiar address cannot replace payment authorisation and independent verification.
EXAMPLE 04 · Attachment safety
A revised purchase order
The independently verified context
You were expecting a PDF purchase order from orders@lumen.example.com. No format change was agreed. The file presented here has a double extension ending in .exe.
Decision: phishing
The final extension identifies an executable, and the sender asks you to ignore a security warning. The unverified sender and unexpected format add evidence. Confirm with your existing procurement contact and report the file.
Takeaway: Inspect the final extension and never run an unexpected executable to read a document.
EXAMPLE 05 · Spear phishing
A conference follow-up
The independently verified context
Your panel appearance and slides are publicly listed. The actual organiser’s verified portal is forum.example.org and does not require your employer’s password, recovery approval or broad email and file permissions.
Decision: phishing
Accurate personal context can be gathered from public information. The external page asks for credentials, a recovery action and excessive app permissions unrelated to sharing slides. Contact the organiser using the established event details.
Takeaway: Personalisation proves research, not trust. Verify the requested action separately.
EXAMPLE 06 · Breach response
A breach notification
The independently verified context
Your independently opened vault app displays the same incident notice. The security page reached through your saved homepage matches it. Your employer’s verified security team confirms the notification.
Decision: legitimate
An alarming subject does not by itself make a message phishing. This incident is confirmed through independent channels, and the advice avoids surrendering secrets. Follow the independently verified incident instructions.
Takeaway: Verify breach notices independently, then take the recommended protective steps.
Use the facts, not a shortcut
These examples do not create a rule that all payment requests, QR codes, urgent notices or internal addresses have the same answer. A sender account can be compromised. A genuine service can have an urgent incident. The request and independent checks must be considered together.
Play Spot the Phishing to investigate these and other cases, or read the scoring rules before you start.