Email safety lab
Before You Click: How to Check a Suspicious Email or Verification Link
A temporary inbox can keep your everyday address out of a signup. It cannot make the message that arrives trustworthy. Treat every unexpected email like evidence: establish why it exists, inspect where it wants to take you, and only then decide whether anything deserves a click.
Case file 01 · The message arrives
Start with the event, not the email design
EXPECTATION
Did you trigger this?
A verification email that appears seconds after a signup you just submitted has context. An unexpected verification email has none yet. Do not invent a reason for it.
SENDER
Who actually sent it?
A familiar logo or display name is weak evidence. Compare the sender address and domain with the service whose action you initiated.
REQUEST
What does it want?
Read the requested action before following it. A code, password-reset link, confirmation button and account alert have different consequences.
Evidence board
How to recognize a suspicious email in a temporary inbox
No single clue proves that a message is malicious. Suspicion grows when the pieces stop matching: you did not request the action, the sender domain is unfamiliar, the destination differs from the service you expected, or the message tries to replace context with urgency.
Case file 02 · The verification link
What should you check before opening a verification link?
- 1. Reconstruct the action. Did you just ask this exact service to send a confirmation?
- 2. Match the sender. Check the actual address, not only the display name or logo.
- 3. Inspect the destination. The domain should make sense for the service and action you expect.
- 4. Ask what the click will authorize. Verification links can confirm an email, reset access or approve another remote action.
- 5. When the context is wrong, stop. Reach the service through a known official route instead of letting the email choose the route for you.
A copied link can still contain a secret
Copying a URL can help you inspect its real hostname without opening it, but verification and reset URLs may contain sensitive one-use tokens. Do not paste those URLs into public link checkers, chats, search boxes or other services merely to inspect them.
HTTPS ✓
Encrypted does not mean legitimate
HTTPS protects the connection to a site. It does not prove that the site belongs to the sender you expected or that the action is one you intended to authorize. A misleading destination can also use HTTPS.
CONTEXT + DESTINATION
Trust comes from pieces agreeing
The stronger pattern is alignment: you initiated the action, the sender fits the service, the destination fits the sender, and the requested action matches what you are trying to complete. HTTPS belongs inside that check; it cannot replace it.
Case file 03 · The invisible request
Can an email track you through images?
An HTML email can reference an image hosted on another server. When a mail client loads that remote image, it makes a network request. A sender can use a unique image URL — including a tiny tracking pixel — to record an open-like event. The important mechanism is the request, not the physical size of the image.
That signal is imperfect: proxies, scanners, caching and image blocking can make an image request differ from a human actually reading the message. But avoiding automatic remote-image loading can still reduce unnecessary contact with sender-controlled servers.
Why MailOnce may block remote images in suspicious messages
Remote content can create a network interaction before you have decided that the sender deserves one. MailOnce's defensive message handling limits automatic remote-content loading when appropriate. That reduces one class of passive contact, but it is not a declaration that every message with blocked images is malicious — or that every message without them is safe.
Message safety still depends on context. Image handling is one control inside the inspection process, not a replacement for checking the sender, destination and action.
Case file 04 · An email you never asked for
What should you do with an unexpected verification email?
Do not share the OTP, do not approve the request and do not follow the verification link merely to “see what it is.” The message may be a mistake, someone may have entered the address, or an action may have been initiated without your involvement. Until you can establish the context, there is nothing useful to authorize.
Direct open vs copy
Copying a suspicious link does not make the destination safe
Copying can give you more control to inspect a URL without immediately visiting it. But the safety question is still about the destination and the action behind it. Once you navigate to the URL, the destination receives a request whether you reached it by clicking a button or pasting the copied link.
Use copy as an inspection step when useful, not as a magic transformation from untrusted to trusted.
Close the case before you click
Expected sender. Expected destination. Expected action.
A temporary inbox protects the address you did not reveal. Careful message handling protects what happens next.
Continue through the Knowledge Center
Before you trust the next message, what else should you know?
Continue with verification context, privacy boundaries, or the delivery path that brought the message into the inbox.
Codes and requests
OTP & Verification
Learn how expected codes, resends and unexpected verification requests should be handled.
Check the verification flow →Reduce exposure
Protect Your Real Email
See where temporary email helps separate short-lived interactions from your everyday address.
Protect your address →Trace the message
Receive Messages
Understand sender delay, delivery, realtime inbox updates and missing-message troubleshooting.
Follow delivery →