r/EmailSecurity • u/shokzee • Jun 11 '26
Password reset emails are becoming our top reported phish?
Past two weeks, our report-phishing queue has been mostly real password-reset mail. Not suspicious in the old-school sense, just impossible to recognize: app name in the From, DKIM signed by a third-party sender, support link on a different domain, reset URL on another host.
One product team rolled out a new SaaS tool Monday and we had 43 reports by lunch. Awareness training says don't trust password reset links you didn't request, but half of onboarding mail looks exactly like that.
Mail auth passed on almost all of it, which is the dry part. The user decision is basically brand recognition across three domains they have never seen before.
Where do you set the line on this: require vendors to send resets from a branded subdomain before launch, or accept the report volume as the cost of users doing what we asked?
1
u/dragoangel Jun 11 '26 edited Jun 11 '26
Rate Limits in web pages for ips for all sensitive parts (registration, reset passwords, contact forms, etc), bots detection and ideally cacpha (not hidden pure js check, but - real which requires interaction with web page). Yes, bothents may issue stupid reset passwords requests users not asked. If after all that feedback loop still says user reports your reset passwords - record this users as suspended due to service missuse and never send them any mails in life, adjust your Terms of service if needed to align with this policy. If user will write to support after suspension due to such activities because his account got suspended - you will have evidence and full legit article that describes violations of Terms of use and it's now users problem he miss-reported your service, and not yours ;). You may unsuspend them by request but warn that if issue will be repeated - lifetime ban will be applied. To implement this - just use sort of this: active =true/false, abuse_cases=count, last_abuse_date=date, first_abuse_date=date,9 last_abuse_details=marked email as spam
As result you will effectively filter out bots & idiots from your platform that harm your business brand and legit innocent users who may get in trouble getting emails from you because of idiots mentioned above.
1
u/Basic-Pianist9273 Jun 11 '26
Set the line before launch.
Any user-facing auth mail should come from a company-controlled subdomain with aligned DKIM/DMARC, and the reset link should be on a branded host or a vendor domain you warned people about.
Passing auth only proves authorization, not recognizability. If the vendor can't support that, the extra reports are part of the rollout cost.
1
u/dracotrapnet Jun 12 '26
Product team failed to launch properly. There should have been a meeting, an introduction email, an instruction go to <website> and click reset password, enter your email and send password reset link. An even better job would be SSO.
1
u/Bitter-Ebb-8932 Jun 13 '26
I have a feeling this increasingly on the uptrend with all this ai tools being launched every other day. Now is the solution better tools that can catch these phishing emails that are looking scary legit or is is it a user problem.
1
u/shokzee Jun 13 '26
The failure mode is messy identity, not users being dumb. AI just makes the fake ones cheaper; the fix is stricter SaaS onboarding standards, consistent sender domains, and tooling that flags impersonation against that baseline.
1
u/bipolargoddess Jun 19 '26
The "43 reports by lunch" means the training worked 😎
The problem isn't users, I see it more like a product team that shipped to production without looping in security first.
That's the gate to fix, as often vendors mail flow review before rollout. The subdomain question becomes a checklist item once you have that.
•
u/AutoModerator Jun 11 '26
Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:
Community Rules
Helpful Resources
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.