Phishing email examples: five patterns to inspect
ChatGPT
Claude
Gemini
Perplexity
GrokIn brief
Review five realistic phishing email examples, compare their warning signs, and learn how to verify suspicious requests without using the message.
Phishing email examples are most useful when they teach you what to verify, not which phrases to memorize. The five fictional messages below use different pretexts, but each exposes evidence you can check safely: the sender identity, the requested action, the real destination, and whether the request matches activity you can confirm elsewhere. None of the examples includes a live domain, working credential form, or malicious attachment.
At a glance
Quick takeaways
- A familiar display name or logo does not authenticate the person or company behind a message.
- Urgency matters when it pressures you to bypass a normal approval or verification channel.
- Inspect the destination separately from the visible link text, but do not visit a suspicious destination.
- Confirm invoices, account alerts, file shares, and support requests through a channel you already trust.
- Report suspected phishing through your organization's process instead of replying to the sender.
How should I read these phishing examples?
Treat each example as a small evidence exercise. The wording is not a detection rule. Good writing can be malicious, and awkward writing can be legitimate. The US National Institute of Standards and Technology describes phishing as deceptive messages designed to obtain sensitive information or induce harmful action. Its current guidance highlights unexpected requests, urgency, suspicious sources, and requests for sensitive information as useful signals (NIST phishing guidance).
The sender line and the message body are claims. They become more credible only when independent evidence supports them. That may include a purchase visible in an account you opened yourself, a colleague reached through a known directory number, or trusted receiver-added authentication results. Even then, authentication does not prove that every request or link is safe. For a line-by-line walkthrough of one message, use the existing phishing scam email example.
Five worked phishing email examples
All names, domains, ticket numbers, and amounts below are invented. Domains ending in .invalid cannot be registered for normal Internet use.
Invoice bank-change example
From: Northline Supply <billing@northline-payments.invalid>
Subject: Updated remittance instructions for invoice 48172
The USD 18,740 balance is due today. Our bank changed this morning.
Use the attached instructions and confirm by reply before 3:00 PM.
The concrete values make the message feel operational, but they also give the recipient something to verify. The sender domain differs from the established supplier domain. A same-day bank change and reply confirmation bypass the procurement record. The safe action is to call the supplier using the number already stored in the vendor system and compare invoice 48172, the amount, and approved bank details. Do not use a number in the email.
Account suspension example
From: Storage Security <alerts@storage-notice.invalid>
Subject: Your account will close in 27 minutes
We blocked a sign-in from 192.0.2.44. Review activity now:
https://files-login.invalid/session/7391
This example combines a countdown, an unfamiliar domain, and a sign-in claim. 192.0.2.44 is in a documentation address range here, so it does not identify a real attacker. Open the service from a bookmark or a typed official address, then review its security activity. The Federal Trade Commission advises contacting the company using a phone number or website you know is real rather than the contact details in an unexpected message (FTC phishing guidance).
Executive gift-card example
From: Maya Chen, CEO <maya.chen@executive-mail.invalid>
Subject: Need a private favor before the board call
Buy eight USD 200 gift cards. Send the codes to me and do not involve Finance.
The decisive clue is not the executive title. It is the attempt to remove the normal approver and move value through a hard-to-reverse channel. Verify the request using the corporate directory, and follow the organization's payment policy. This is also an example of spear phishing because the message targets a role and imitates a named leader rather than sending a generic account alert.
Shared-file example
From: Priya shared "Q4 Compensation Draft"
Reply-To: access@document-share.invalid
Open secure document
Visible label: company.share.example
Actual destination shown by the mail client: document-share.invalid
The pretext uses confidentiality to discourage questions. The visible label and actual destination disagree, and the unexpected document asks the recipient to sign in. Contact Priya in the normal collaboration tool or open the organization's approved file service directly. Do not test the suspicious link. A padlock would only describe the connection to that destination, not whether the destination belongs to the expected company.
Fake support-call example
From: Apple Account Support <case@apple-helpdesk.invalid>
Subject: Case 630184 requires phone verification
Call +1 202-555-0147 and read the six-digit code sent to your device.
The message asks the recipient to transfer an authentication factor to an unsolicited caller. The brand name does not make that safe. Open the vendor's official support route independently and check whether case 630184 exists. Never provide a password or one-time code because an inbound message claims support needs it. The Apple phishing email guide applies that verification pattern to current Apple guidance.
Compare the evidence instead of memorizing one phrase.
Use the matrix to choose a safe verification step. When an example turns on a link, the Palisade phishing link checker inspects that URL before you open it. It reports public threat signals for the destination; it cannot prove a site is safe, and it cannot inspect the message itself.
What evidence deserves the most weight?
A single misspelling deserves less weight than a request that conflicts with known business context. Start with facts the sender cannot control inside the message: an existing purchase record, a supplier's stored bank details, the security activity visible after you open an account independently, or a known colleague reached outside email.
Header evidence can help a security team determine which domain authenticated the message, but it has limits. RFC 8601 Section 1.2 explains that an Authentication-Results field is meaningful only within the receiver's trust boundary; a sender can insert an untrusted lookalike field (RFC 8601, Section 1.2). A message can also pass SPF or DKIM for an attacker-controlled domain. That is why phishing can pass SPF and DKIM without becoming legitimate.
When do these examples not apply?
These patterns do not establish that every urgent request, changed invoice, shared file, or support email is malicious. Real teams sometimes change banks, systems send genuine alerts, and colleagues share sensitive documents. The correct conclusion is "unverified," followed by independent verification, not an automatic accusation.
The examples also do not replace an incident-response process. If someone entered credentials, disclosed a code, opened an attachment, changed payment details, or sent money, stop the example comparison. Contact the authorized security or finance team using the established emergency path. Preserve the original message and relevant device or account evidence. Do not forward an active attachment to people who do not need it.
What should I do with a suspicious example in my inbox?
Stop interacting with the message. Capture the observable details your organization requests, such as sender, subject, time, claimed transaction, and visible destination. Then use the mail provider's phishing report control and the organization's security channel. The FTC also accepts reports at ReportFraud.ftc.gov and directs suspicious email to the Anti-Phishing Working Group at reportphishing@apwg.org (FTC reporting guidance).
Do not reply to challenge the sender. A reply can confirm that the address is active and keeps the conversation inside the attacker's chosen channel. If the message is merely unsolicited bulk advertising without deception, the spam versus phishing guide explains why the reporting path can differ.
Evidence
Sources and further reading
Questions readers ask
Frequently asked questions
Written by
Samuel ChenardCEO & Co-Founder, Palisade
Samuel Chenard is the CEO and co-founder of Palisade, AI-first DMARC software for IT teams and MSPs, from one domain to thousands.
More from Samuel →
