An email reply can feel routine, especially when the sender sounds familiar or says a task is urgent. But a convincing message is not proof that the person behind it is who they claim to be—or that they need the information they are asking for. Before replying, pause over any request for credentials, codes, money details, or private records. A simple rule helps: do not send sensitive information until you have independently confirmed both the requester and the reason for the request.
The useful bits
- Never reply with passwords or verification codes.
- Verify the sender and purpose using contact details you already trust.
- Share only the minimum information needed, through an approved channel.
Draw a firm line around credentials and codes
Do not send a password, passphrase, recovery code, one-time verification code, or sign-in approval in an email reply. Treat a request for one as a warning sign, even if the message uses a familiar name, logo, signature, or urgent explanation. A code can help someone complete a sign-in or account change; handing it over may defeat the protection it is meant to provide.
A legitimate need to help with an account does not make it necessary to disclose your secret. If someone asks you to forward a code, share a password, or approve an unexpected sign-in, stop and check through a separate trusted channel. Never paste real passwords or codes into an AI assistant or other tool to ask whether a message is safe.
Keep financial and identity details private
Do not put payment-card numbers, bank account details, security codes, payment credentials, or other financial information into a reply to an unverified sender. Be cautious with requests to change where an invoice should be paid or to send money to a new account. A familiar project or invoice reference does not independently confirm that the request is genuine.
Also withhold sensitive identity information, such as government identification numbers, copies of identity documents, or personal details that could be used to impersonate you. If a request appears to come from a bank, supplier, customer, or colleague, use contact details you already have on file—not a number or link supplied in the questionable message—to check it.
Confidential records need a clear reason and route
Internal reports, customer or employee records, private correspondence, access details, and unreleased business information should not be sent simply because a message asks. Confirm that the requester is authorised to receive the material and that the stated task actually requires it. A request for “the full file” may call for more disclosure than the work needs.
Ask what specific information is required, who will receive it, and how it should be shared. Follow your organisation’s approved process for sensitive records. If you cannot confirm the recipient, purpose, or permitted method, do not attach the file or paste its contents into the reply. You can acknowledge the request without providing the information while you verify it.
Verify independently, not inside the same thread
Contact the person using a phone number, messaging account, or email address you already know is theirs. For a workplace request, use an established internal contact route or ask an appropriate manager or administrator. Do not rely on the sender address, signature, phone number, or callback link in the message you are checking; those details may be part of the unverified request.
Confirm both identity and purpose. For example, ask whether the person sent the request, what exact information they need, and which approved channel they expect you to use. If you cannot reach them, wait rather than sending sensitive material under pressure. A deadline in the message does not replace verification.
Use a minimum-disclosure reply
Once a request is confirmed, share only what is necessary and only through a channel permitted for that information. Check the recipients before sending, including anyone copied on the message. Remove unrelated details from documents where appropriate, and avoid attaching a whole record when a limited answer will do. Verification confirms the request; it does not automatically make every detail suitable to share.
If the request still seems unusual, ask the requester to explain the need or use the organisation’s established approval process. Keep your response neutral: you can say that you are confirming the request before sharing private information. This gives you time to check without accusing the sender or revealing anything sensitive.
Reply while checking: “I’m confirming this request before sharing any private information. I’ll contact you through our usual channel to verify what is needed.” Then contact the person using a number or address already in your records. Do not include a password, code, account detail, or confidential attachment in the reply.
A quick check before you send
After verification, confirm that the intended recipient received the necessary information through the agreed channel. If you sent something to the wrong person or replied before checking, act promptly: contact your organisation’s security or account administrator if relevant, and contact your financial provider through a trusted route if payment details were exposed. For an account password you disclosed, use the service’s official sign-in or recovery route to secure the account. Do not continue the email exchange as your only way to resolve the incident.
- Does the reply contain a password, verification code, financial detail, identity document, or confidential record? Remove it unless a verified, approved process specifically calls for sharing it.
- Have I confirmed the requester and purpose using contact details independent of this message?
- Is this the correct recipient and approved channel, and am I sharing only what is needed?
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