Guide
Handling Verification Emails Safely
How to read a verification message before acting on it, the four checks that catch nearly every phishing attempt, and the rule for deciding which inbox a code belongs in.
Verification mail is the most reliably imitated category there is, because it arrives at a moment when you are expecting it and inclined to click quickly. This guide covers reading one carefully, and choosing where it should land in the first place.
Part one: which inbox does this belong in?
Decide before the message is sent, because the decision is hard to reverse afterwards.
The rule: send a verification to a disposable inbox only when you would not care if a stranger completed the action.
| Message type | Disposable inbox? | Reasoning |
|---|---|---|
| Confirm address to unlock a download | Yes | Nobody gains anything by completing it |
| Verify a forum account holding nothing | Usually | Low value if lost or taken |
| Login code for an account with your name on it | No | The code *is* the login |
| Password reset for anything you keep | Never | Permanent takeover, and unrecoverable later |
The subtlety is that the danger is usually not interception. It is dependency: an account whose only route back in is a mailbox that expired the same afternoon. What is an OTP email works through that distinction.
Part two: the four checks
Run these on any verification message, in any inbox, before you click anything.
1. Did I just trigger this?
The single most valuable check. A verification you did not request means somebody else is trying to use your address — or your account. Never enter the code. If it is a reset for a real account, change that password immediately from a page you navigated to yourself.
2. What is the actual sender domain?
The display name is free text and anybody can set it to a bank's name. Read the part after the @. Look specifically for near-misses: an extra word, a hyphen, a different top-level domain, a letter swapped for a similar-looking one.
3. Where does the link really go?
Hover, or read the destination ShieldMail prints beneath each link. Compare the domain against the company you expect — not against the link's *text*, which the sender chose.
Two patterns that should stop you: a shortened link in a transactional email (legitimate senders rarely need one), and a domain that merely *contains* the brand name rather than *being* it.
4. What is it actually asking for?
Legitimate verification asks you to confirm you control the address. It does not ask for a password, a card number, or a copy of an identity document. Any of those in a verification message means it is not one.
The one rule with no exceptions
Never read a code aloud, forward it, or paste it into a chat, however plausible the request.
No genuine company will ever ask. The request itself is the attack — usually a caller claiming to be support who has already started a password reset and needs the code you are about to receive.
What ShieldMail does when it renders a message
For messages read in this tool specifically:
- Scripts are removed on the server before the content reaches your browser.
- Remote images are blocked, so tracking pixels never fire and the sender learns nothing about whether you opened it.
- Iframes are stripped, closing a common embedding technique.
- Link destinations are printed in full, so the true target is visible without hovering.
What none of that can do is judge intent. A perfectly formed message from a convincing domain will render cleanly. The four checks above are still yours to run.
When the verification never arrives
In order:
- Refresh once more. Delivery is usually under ten seconds but occasionally slower.
- Wait a minute, refresh again. Some senders queue in batches.
- Assume the domain was rejected. Many services silently discard signups from disposable domains rather than saying so. Press Change for an address from a different provider and register again.
- Reconsider the tier. A service that invests in blocking disposable domains is telling you it expects a durable contact channel. That is usually a signal to use an alias.
After you verify
- Copy the code or open the link now. The mailbox will not be there later, and nothing in it is recoverable after expiry.
- If the account matters, change the address on file immediately to something permanent — while you can still log in to do it.
- Press Change before your next unrelated signup, so two accounts do not share one expiring address.
The mechanics of all this are in how to use temporary email safely.
FAQ
How long is a verification code usually valid?
Typically five to fifteen minutes for a login code, and up to an hour for a reset link. Expiry limits the exposure window without removing it.
Is a magic login link safer than a numeric code?
In a shared mailbox, slightly worse. A link is one click from access; a code must be typed into the correct page, which asks a little more of an attacker.
What if I clicked a link in a message I now think was phishing?
Do not enter anything on the page. Close it, then go to the real service by typing its address yourself and change your password there. If you did enter credentials, change that password everywhere it was reused.
Can I verify a two-factor setup with a temporary inbox?
No. A second factor only works if you alone can receive it, and a public mailbox breaks that assumption entirely.
Should I delete verification messages after use?
In a permanent mailbox, yes — it removes stale reset links. In a temporary one it changes nothing, since the whole mailbox is destroyed on expiry.