When an unexpected email asks you to sign in, open a document or change a payment, pause before following its instructions. Check what it wants you to do and verify the underlying request through a route you already trust. You do not need to visit a suspicious page to investigate whether an account actually needs attention.
Phishing uses deceptive messages or sites to obtain information or access. A familiar logo, convincing story or recognizable sender name can be part of that deception. The practical question is whether the request and its destination have been independently verified.
This guide provides a checking routine, a fictional invoice example, reporting instructions and an initial response if you have already interacted. Provider documentation was checked on October 25, 2026. For work accounts and devices, follow your organization’s reporting and incident-response process.
In this article
- 1. Look at the action the message is trying to trigger
- 2. Inspect the sender, but do not make identity a one-field test
- 3. Verify the request through a route the message did not supply
- 4. Keep links, attachments and sign-in prompts outside the investigation
- 5. Report the message using the right account’s tools
- 6. If you already interacted, identify exactly what happened
- 7. Strengthen the account and rehearse the routine
1. Look at the action the message is trying to trigger
Start with the requested behavior. Is the email asking you to enter a password, supply private information, open an unexpected attachment or make an unfamiliar payment? The FTC describes common phishing stories involving account trouble, suspicious activity and invoices. The story provides a reason to act; it does not establish that the request is genuine.
Compare the request with what you expected before receiving the message. A document you arranged to receive is a different situation from an unexplained attachment arriving with a deadline. An unexpected request still needs verification even if it refers to a project or account you recognize.
A useful habit is to describe the action in plain words: “This message wants me to enter credentials on a page it chose.” That removes some of the pressure created by its presentation. You can investigate the real account or conversation without accepting the message’s proposed route.
Sources: FTC — Recognizing phishing and responding after an interaction ↗
2. Inspect the sender, but do not make identity a one-field test
Microsoft explains that deceptive messages can use a spoofed source address and describes Outlook indicators for unverified senders or differences between the sender’s address and the displayed identity. It also notes that an authentication warning does not mean every affected message is malicious.
Inspect the available sender details rather than relying only on the name in the inbox. Compare them with contact information you already possess. A discrepancy is a reason to stop and verify; an address that looks familiar is not a substitute for checking an unusual request.
Treat branding and professional wording as presentation, not proof. The relevant question is whether the person or service actually issued this instruction and whether the requested action fits the established process. If you cannot establish that, keep the request unverified rather than trying to score its appearance.
For a workplace message, use the organization’s reporting tool or ask the responsible team through its known channel. Do not forward sensitive business content to an unrelated checking service just because it offers an instant verdict.
Sources: Microsoft Support — Phishing indicators and Outlook reporting ↗
3. Verify the request through a route the message did not supply
The FTC recommends contacting a company or bank through a phone number, email or website you already know is genuine when an unexpected message could be legitimate. The important change is the source of the contact route: use an existing trusted relationship or established account access, rather than details the message just gave you.
For a delivery or account notice, open the service’s known app or reach its website through your normal method. For a colleague or supplier, use the contact details already in your records. Ask whether the specific request was made, including any change in destination or payment details.
Here is a fictional example. An email labeled “Accounts Team” claims an invoice must be paid today to a replacement account. Instead of replying to confirm the new details, contact the supplier through its established number and follow your normal change-verification procedure. The claimed urgency should not determine which verification route you trust.
The same approach works when the message threatens an account closure. Check the account independently and look for the actual issue. You can respond to a real problem without using the email’s link or telephone number.
Sources: FTC — Verify unexpected requests using a known contact route ↗
4. Keep links, attachments and sign-in prompts outside the investigation
Gmail’s guidance says to heed security warnings and avoid untrusted links, downloads and requests for private information. It also advises going directly to the service rather than entering a password after following a questionable message link. A missing warning is not a promise that the request is safe.
Do not open a suspicious attachment simply to see whether its contents look convincing. Ask the purported sender through a known channel whether the file was expected and use the approved way to obtain it. If your organization has a process for examining suspicious files, let that process handle the investigation.
A document-sharing request deserves the same pause as an invoice. Identify who was supposed to share the document, why you need it and where you would normally access it. The request to sign in is part of what needs checking, rather than evidence that the file must be genuine.
Use a short stopping rule: if you have not established the request and its route, do not supply information or open content to resolve the uncertainty. Verification can happen outside the message.
5. Report the message using the right account’s tools
On Gmail for a computer, Google documents opening the message, choosing the More menu next to Reply and selecting Report phishing. This is a reporting action within the mail interface; it does not require visiting the email’s links or opening its attachments. On a work account, use the organization’s designated reporting process when applicable.
In Outlook.com and the Outlook experiences covered by Microsoft’s instructions, select the message and use Report, then Report phishing, above the reading pane. Microsoft notes that reporting does not itself block the sender from sending more messages. Controls and labels can differ between applications and managed environments.
Keep enough context for the responsible team to understand what arrived and whether you interacted. Follow its instructions about preserving or removing the message. Do not circulate it widely as a warning with its attachments intact, and do not reply to the suspicious sender to challenge it.
Sources: Gmail Help — Avoid and report phishing emails ↗ · Microsoft Support — Phishing indicators and Outlook reporting ↗
6. If you already interacted, identify exactly what happened
Stop further interaction and distinguish what occurred: viewing the message, visiting a page, entering a password, approving a request or downloading a file are different events. On a work device or account, notify the responsible team promptly and describe the action without minimizing or guessing its consequences.
If you entered account credentials, use the provider’s genuine security and recovery route. Google’s compromised-account guidance covers reviewing security events and devices, changing a compromised password and inspecting settings such as recovery information and unfamiliar forwarding rules. Follow the relevant provider’s process rather than returning to the suspicious page.
If you suspect harmful software was downloaded, the FTC advises updating security software and running a scan. Managed devices may have a prescribed response, so contact your IT team before improvising repairs or erasing potential evidence. If payment or financial information was involved, contact the relevant institution through a known genuine channel.
Deleting the email is housekeeping, not an assessment of an exposed account or device. Record the steps completed and any outstanding issue. The right next action depends on what information or access was actually given away.
Sources: FTC — Recognizing phishing and responding after an interaction ↗ · Google Account Help — Secure a compromised account ↗
7. Strengthen the account and rehearse the routine
After addressing any immediate issue, review the account’s supported authentication and recovery options. Our passkey guide explains how passkeys differ from passwords and why a backup sign-in route matters if a device is lost. Strong authentication belongs alongside careful approval of requests and secure account recovery.
Keep your important files recoverable as a separate precaution. The backup guide explains how to identify protected folders and perform a restore test. An account-protection measure and a usable file backup solve different problems, and neither removes the need to investigate an actual incident.
For a first rehearsal, use the fictional invoice example with no real payment details or active suspicious links. Identify the requested action, choose the trusted contact route and locate the reporting control in your own email application. The aim is a routine you can repeat while an unexpected message is pressuring you to hurry.
Sources: Related Trevioniq guide — Passkeys and account recovery ↗ · Related Trevioniq guide — Backups and a restore test ↗