Incident
A user at a title company forwarded us an email with a verification code she hadn't requested. An hour later: "I've now gotten two codes that I did not request on that email I forwarded this morning." By the time we circled back she was seeing several more, back to back. The first one was a Proofpoint encryption registration code from a regional bank's secure-email portal. The follow-ups were landing in the same inbox in quick succession.
This is the exact scenario that sends people into a panic — and for good reason. Unexpected OTPs are one of the classic signs of an account takeover in progress. An attacker who has your password but not your 2FA code will hammer the login page, and each attempt kicks a code to your inbox. So when a user forwards you one of these, the first question has to be: is this an attacker trying to get INTO an account, or is someone using your email address to sign up for something OUT in the world? The responses are completely different. One is a potential incident. The other is annoying spam.
The triage playbook
We walked the user through the standard set of questions. These are the four that do most of the work:
- What service sent the code, and what was the code FOR?
- Is it the same sender every time, or different senders?
- Do you already have an account with that service?
- When you go to that service and click "forgot password" with your email, does it say an account exists?
Step 1 is the biggest tell. A code labeled "complete your registration" or "verify your email" is almost always a signup flow — someone is creating a new account and typed your address in the email field. A code labeled "sign in" or "login verification" means someone is trying to authenticate AS you, which is the scary version.
In this case the subject line said "Proofpoint Encryption Registration" and the body read "Please use this validation code to complete your registration." Registration flow language. Someone was trying to sign up for the bank's secure-email portal using her address — not logging into an account of hers.
Step 2 narrows it further. Codes from DIFFERENT services usually mean an email enumeration attack — a scripted bot cycling through signup forms that don't rate-limit. Codes from the SAME service are either one persistent idiot mistyping their own email, or a targeted attempt on a real account.
What we told the user
Short version: don't click anything inside the emails, don't enter the codes anywhere, and let them expire on their own. If she wanted to confirm nothing existed under her address at that bank's portal, go directly to the service's website (not via any link in the email) and run a password reset. The site will tell you whether an account exists. No account = signup attempt = ignore. Account exists = take it seriously.
Why this isn't a compromise signal
Her mailbox wasn't at risk from these codes. Receiving a code proves nothing about account access — anyone who knows your email can trigger one from any service with an unprotected signup form. The code is useless to the attacker unless they can read your inbox. They can't; the code was sent to HER. No action she took caused this: no link clicked, no attachment opened, no credentials entered. Her actual work email account — the one the codes were landing in — was not involved in any authentication event. Nobody tried to log into it.
What would change the answer
For contrast, here's what would have flipped this from "ignore it" to "incident response":
- codes labeled "sign in verification" or "login code" instead of registration
- password reset emails she didn't request
- login notifications from unknown locations/devices
- 2FA prompts for services she didn't just try to access
None of that was present. She had a signup-flow code followed by a burst of spam from the same pattern — textbook low-severity.
Outcome
We explained the triage logic, confirmed it was a signup enumeration, and told her to expect the codes to stop on their own once whoever typed her address got frustrated and moved on. No credentials exposed, no account access attempted, no follow-up incident. The ticket went quiet and auto-closed a week and a half later.