A message in a familiar thread can feel safer than an unexpected email: the names, subject, and earlier details all seem to fit. But a conversation can be taken over, or a sender can be made to look like someone you know. That familiarity is useful context, not proof that the newest request is genuine. Before changing payment details, sharing sensitive information, or entering credentials, pause and confirm the request through a separate trusted channel. A brief check can prevent a convincing message from turning into an irreversible action.
The useful bits
- Treat a familiar thread as context, not authentication.
- Confirm sensitive changes using contact details you already trust.
- Verify the action and its outcome independently before considering it complete.
The conversation may be real; the request may not be
In a compromised mailbox, someone else may be able to read earlier messages and reply within an existing conversation. They can use the same subject and refer to real projects, dates, or names. A spoofed message can also imitate a familiar sender. In either case, the surrounding conversation may look ordinary even though the person asking for an action is not authorised to do so.
That is why a reply appearing beneath legitimate earlier messages does not settle who sent it. Nor does a plausible explanation, such as a changed bank account, an urgent login problem, or a request to share a document elsewhere. Treat the new instruction as unverified until you check it independently.
Notice what changed, not just who is writing
Look for a change in the requested action, destination, or urgency. A routine invoice discussion that suddenly asks for payment to a different account is a meaningful change. So is a familiar colleague asking for a password, a one-time code, or access to sensitive files through an unfamiliar route. A sender may be genuine and still have made a mistake; verification protects against both mistakes and impersonation.
Be especially cautious when a message discourages checking, insists that a deadline makes confirmation impossible, or asks you to keep a change quiet. These details do not prove fraud, but they are reasons to stop and use another route to confirm.
Choose a channel the message cannot control
Use contact information you already had before receiving the request: a known phone number, an established workplace directory, or a previously trusted contact method. Do not use a new number, link, or reply address supplied in the message as your only check. If you cannot reach the person, wait rather than treating silence or urgency as approval.
Ask a direct, neutral question that does not repeat sensitive information unnecessarily. For a payment change, confirm the payee and destination details using your established process. For a request involving credentials, do not send a password or one-time code; go to the service through a route you independently know is genuine. For sensitive sharing, confirm both the recipient and what they are authorised to receive.
A practical example: changed payment details
Suppose a supplier’s familiar invoice thread says its bank account has changed and asks you to pay today. The earlier messages and invoice may be genuine, but the new payment instruction still needs confirmation. Do not rely on the thread to verify its own change.
Message: “Please use the new account below for this invoice.” Safer next steps: 1. Pause the payment and do not use contact details supplied in that message. 2. Call the supplier using a number already on file or obtained independently. 3. Ask an authorised contact to confirm the change and the exact payment details. 4. Follow your organisation’s normal approval process before updating records or paying.
Keep the confirmation separate and specific
A useful confirmation identifies the change, not merely the general topic. Ask whether the sender requested this particular new account, recipient, file-sharing destination, or account action. For financial changes, compare the details you are about to use with the details confirmed through the trusted channel. For sensitive sharing, confirm the intended people and scope before granting access.
If the independent contact cannot confirm, gives conflicting details, or seems unaware of the request, do not proceed. Contact the appropriate person through another established route, such as a manager or your organisation’s finance or security contact, if one exists. Keep the questionable message available for your organisation’s handling process; avoid forwarding sensitive content more widely than necessary.
Check that the action is actually complete
After confirmation, verify the result through the normal system or record for that action. Check that a payment was prepared for the confirmed recipient, a password change was made through the genuine service, or shared access was granted only to the intended people. Do not treat a reassuring reply in the original thread as proof that the action was correct.
A quick final check can catch a mismatch before it causes further trouble: compare the confirmed details with what you entered, and make sure no extra recipient or unexpected change was included. If something does not match, stop and use the organisation’s established support or escalation process. The goal is not to distrust every conversation; it is to give consequential changes a confirmation that the conversation itself cannot provide.
- Did I confirm through contact details I trusted before this request?
- Did the authorised person confirm the exact change and its destination?
- Does the completed action match that confirmation?
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction