THE SHORT ANSWER
Separate the message’s claim from its actual destination. If an unexpected message asks you to log in, pay or provide account information, verify the request through a route you already trust before continuing.
1. Identify what the message wants you to do
An offer, a delivery update and an account-support request can look similar at first glance. Read the action being requested: open a product, sign in, download a file, provide information or make a payment. The requested action matters more than whether the message uses a familiar logo.
The FTC describes phishing messages that use account problems, payment issues or attractive offers as a reason to click. Those are reasons to check, not proof that every message about a problem or a coupon is false. This article provides a verification routine; it does not classify a particular sender or website.
Reference: FTC: Recognising and avoiding phishing
2. Read the actual address, not just the label
A link’s displayed words can differ from the destination. Where your browser or mail app allows it, inspect or copy the link without following it. Read the full hostname carefully rather than recognising a familiar word somewhere in the address. If a shortened link hides the destination, leave it unverified until you can establish where it goes.
The fictional example below uses reserved .example addresses and is deliberately not clickable. The word official in a path or subdomain is only text chosen by whoever controls that address. A lock or HTTPS connection describes the connection; it does not independently establish that the business is the one you intended to contact.
| Illustrative address | What the text actually shows |
|---|---|
| shop.example/help | Hostname: shop.example; path: /help |
| shop.example.other.example/login | Hostname belongs under other.example |
| other.example/official-shop | The familiar name appears only in the path |
| An unfamiliar shortened URL | The final destination is not established here |
Reference: RFC 2606: Reserved top-level DNS names · Google Chrome Help: Checking a connection
3. Use a contact route independent of the message
If the request relates to an account you use, return through a saved bookmark, the app you normally use or an address you already established independently. Open the relevant account area or contact support there. Do not use the same unexpected message as both the claim and the proof that it is genuine.
The FTC recommends checking through contact information you know is real rather than the details in the message. Our practical question is: does the request also appear in the account, or can support reached independently explain it? Keep the request unresolved if you cannot establish that connection.
Reference: FTC: Recognising and avoiding phishing
4. Resolve the request before taking a sensitive action
Avoid entering credentials or account information merely to see what an unfamiliar page does next. A request that needs verification can wait while you use the independent route. Do not send passwords, one-time login codes or recovery codes to someone claiming to be support in a chat.
If a genuine account process requires information, use the verified account flow and read exactly what is requested. An author on a public forum cannot approve that request for you based on a cropped screenshot. You can describe the general issue publicly without posting private account records.
5. Record what you verified and what remains open
Keep a short private note of the message date, claimed purpose, inspected destination and the independent check you performed. The result might be confirmed, inconsistent or still unknown. Unknown is a useful outcome: it means you have not established enough to proceed through that link.
If you already disclosed information, use the real service’s account-security process and the appropriate provider for the information involved. The FTC reference includes general next steps after suspected phishing. This website cannot inspect your account or confirm a message’s authenticity, and it does not need your private details to explain the routine.
Reference: FTC: Recognising and avoiding phishing
Your checklist
- Identify the action the message requests.
- Inspect the actual hostname and destination where possible.
- Verify through a route independent of the message.
- Keep credentials and recovery codes out of support chats.
- Record confirmed details and leave unresolved requests open.
Common questions
Does HTTPS prove a site is the official service?
No. An encrypted connection and the identity of the business are different questions. Verify the destination independently.
Is every referral or coupon link suspicious?
No. Check its destination and context. This article does not label all promotional links as fraudulent.
Can I send this website a private account screenshot for verification?
This website does not provide account verification. Use the service’s independently verified support route for an account-specific request.
Sources and scope
This original editorial article uses the references below for context. Saved listings and hypothetical examples are identified in the text. It does not describe a purchase or wear test by this website.
- FTC: Recognising and avoiding phishing
General guidance for independently checking unexpected messages. It does not determine whether any particular Oopbuy message, domain or sender is genuine.
- RFC 2606: Reserved top-level DNS names
Reserves .example for documentation examples. The illustrative addresses on this page are plain text and are not service destinations.
- Google Chrome Help: Checking a connection
Explains secure connections and advises checking the site name even when the connection is secure.