Overview

This article provides a low-risk, evidence-driven troubleshooting path for phishing email: what to do before you click anything. Work from identity and service checks toward more disruptive actions, and stop before a change could cause data loss, broaden access, weaken security, or interrupt other users.

Start with the safest layerRecord the current state before changing settings. Use only approved accounts, tools, and administrative processes.

Why this happens

Security warnings and suspected account compromise require evidence preservation, safe containment, credential protection, and coordinated administrator-side review rather than ordinary trial-and-error troubleshooting.

Before You Begin

  • Preserve screenshots, alert text, times, sender addresses, and other useful evidence.
  • Use a known-clean device for sensitive account changes when practical.
  • Do not approve unexpected MFA prompts or communicate secrets to an unverified requester.
  • If ransomware or active compromise is suspected, prioritize containment and escalation over ordinary troubleshooting.

Navigation reference: Official work account portal > Security.

Click-by-Click Troubleshooting

Step 1: Inspect without interacting

Action: Open the message in the mail client without selecting links or attachments. Review the visible sender, subject, and request.

Why this matters: Inspection without interaction preserves evidence and reduces the chance of triggering malicious content.

What to look for: Look for urgency, payment requests, password requests, mismatched names, or unexpected attachments.

Expected result: You should have enough visible evidence to decide whether the message is suspicious without clicking.

Step 2: Check the real sender

Action: In Outlook or Gmail, open the message details and review the full sender address and reply-to address.

Why this matters: Display names can be impersonated while the underlying address reveals the actual sender.

What to look for: Look for lookalike domains, unexpected external addresses, or a reply-to that differs from the sender.

Expected result: The sender identity should either match the expected organization or remain suspicious.

Step 3: Verify the request out of band

Action: Contact the supposed sender using a known phone number, saved contact, or established business channel - not the contact details inside the suspicious message.

Why this matters: Independent verification prevents an attacker from controlling both the request and the verification path.

What to look for: Ask whether the sender actually requested the payment, password action, file review, or account change.

Expected result: The request should be independently confirmed or rejected.

Step 4: Report the message

Action: Use the organization's approved phishing-report process or the mail client's Report phishing option.

Why this matters: Reporting helps administrators investigate related messages and protect other users.

What to look for: Confirm the report was submitted without forwarding sensitive content to unnecessary recipients.

Expected result: The message should be in the organization's incident-review workflow.

Step 5: Preserve evidence

Action: Capture the sender, subject, time received, and screenshots before deleting or moving the message if the reporting process does not already preserve it.

Why this matters: Evidence may be needed to identify related messages, domains, or compromised accounts.

What to look for: Keep only business-relevant evidence and avoid opening attachments to gather more.

Expected result: Useful incident evidence should be available to IT.

Step 6: Remove after reporting

Action: After the approved report/evidence step is complete, move the message to Junk or delete it according to organization policy.

Why this matters: Removing the lure reduces the chance of later accidental interaction.

What to look for: Confirm the suspicious message is no longer in the active inbox.

Expected result: The message should be removed without losing necessary evidence.

What to Look For

  • Whether the issue affects one user/device or multiple users.
  • Whether a clean browser or alternate approved client changes the result.
  • Whether the error points to identity, permission, licensing, service, device, or network state.
  • Whether the same controlled test succeeds after the targeted correction.

When to Stop

Stop before troubleshooting becomes riskyDo not broaden access, bypass MFA/security, erase evidence, permanently delete business data, change tenant-wide settings, or perform destructive resets unless the approved IT process specifically requires it.

When to Contact IT

Contact J3 Systems Group if the issue remains unresolved, affects multiple users, requires administrator-level changes, involves security or data-loss risk, or the next step would be disruptive. Include article code KB-07.001, the affected account/device/resource, exact error, time observed, and the results of the controlled tests above.

Need help with this issue?

J3 Systems Group supports small businesses and nonprofits with Microsoft 365, Google Workspace, cybersecurity, devices, documentation, and day-to-day IT operations.

Contact J3 Systems Group

Authoritative references

Vendor interfaces, licensing, and security guidance can change. Verify current platform behavior against the primary documentation below before making high-impact production changes.

Article KB-07.001 · Review after material vendor, licensing, interface, security, or service changes.