Start with the requested action, not the logo
A message check should identify what the sender wants you to do and what that action would change. It might reveal a password, authorize an app, change an invoice beneficiary or install a tool. The same visual design can accompany very different requests. Naming the action gives the team a practical decision to verify instead of asking someone to judge an entire message by intuition.
Compare that action with work already agreed outside the message. Were you expecting this document or payment change? Does the person normally request it, and does the proposed route match your process? Unexpected timing is a reason to check. Expected timing is useful context, but it is not enough to approve a new recipient or access permission automatically.
Use a decision card rather than a safe-or-unsafe score
Our message decision card organizes the questions that matter before an action is taken. It is deliberately not a points system: a good logo cannot cancel out an unverified bank-account change. When a sensitive step remains unexplained, pause that step and escalate it to its owner. A screenshot or a clean-looking sender line does not supply the missing approval.
Record what you know without opening an attachment or following a destination merely to fill every field. An unknown destination can remain unknown while the administrator reviews it through an approved process. The immediate decision may simply be to open the known business portal separately or ask the established contact whether there is a legitimate task waiting there.
| Question | What to record | If it remains uncertain |
|---|---|---|
| What changes? | Requested login, disclosure, payment or installation. | Keep the sensitive action paused. |
| Was it expected? | The task agreed through another known route. | Ask the business owner separately. |
| Who is requesting it? | Full address and claimed role, without assuming authenticity. | Use a trusted contact already held. |
| Where does it lead? | Visible destination or permission request if safely available. | Do not open it just to investigate. |
| Who can approve? | The responsible person and normal process. | Use the defined backup approver. |
| Did anyone act? | Exact disclosure, approval, download or payment. | Start the relevant incident response. |
Read sender and destination details without overinterpreting them
Display names can hide important address differences, and a long address may look familiar at a glance. Read the actual details the mail app exposes without replying to the sender. If the interface does not show enough information, use the reporting route rather than guess. A message can be suspicious even when its wording and branding match the organization it claims to represent.
A familiar thread also needs the same action check. A request can introduce a changed destination or approval route inside an otherwise ordinary conversation. HTTPS describes a protected connection, not the sender's authority to demand information. Likewise, a destination containing a brand name somewhere in the address is not sufficient verification. Use the known app or independently established website for the expected task.
Verify through a route that the message does not control
The independent route must have a trustworthy origin. Choose a saved company contact, an established supplier record or a portal your organization already uses. Do not adopt the callback number printed in the suspicious message as the verification channel. Ask about the specific action and destination, rather than merely whether the organization sent something recently.
If the main contact is absent, follow a previously agreed backup process. Pressure to complete the task does not create authority to invent a new one. A small company can keep this workable with a short list of owners and deputies. Record who confirmed the action and which known contact was used so another approver can understand the basis for the decision.
Handle polished language and plausible context carefully
Good grammar is not a dependable clearance signal. The FBI's 2024 notice describes generative AI being used to make fraudulent text and impersonation more believable. That does not mean every well-written suspicious message was generated by AI, or that the recipient needs to identify its production method. The safer decision still depends on the request and its independent verification.
Apply the same process in every working language. A fluent local message should not bypass controls, and a legitimate supplier writing in a second language should not automatically be accused of fraud. Let evidence and authorization drive the business action. Where the message remains unresolved, keep a neutral record such as unverified request rather than publish a claim about the sender's identity.
Report the uncertainty in a way someone can act on
A useful report says when the message arrived, which business action it requested, what was expected and whether anyone acted. Use the organization's approved method to retain the original message. Avoid spreading clickable copies to colleagues or pasting confidential correspondence into a public checker. If you already disclosed information, tell the owner directly rather than wait for a final verdict on the message.
CyberFixCrew is an Israeli cybersecurity company serving worldwide businesses. We apply practical Israeli technical knowledge to business-email configuration, account access and website infrastructure. Describe the control or account concern in an initial enquiry; do not send passwords or live access codes. Technical review can support the process, while payment authorization and internal reporting remain with the business and its appropriate providers.
