Check your inbox, it said, and nothing could reach it
The password reset said the email was on its way. The mail service had refused every one for days. A route that cannot know the answer should not pretend to.
Forgot your password, type your address, and the screen says Check your inbox. Nothing arrives. Try again: same sentence, same empty inbox. A tester filed it as a bug in the reset flow, and the reset flow was doing everything it was written to do. The email service behind it was refusing every message, and the screen had no way of knowing.
What the log knew
The platform’s own error log held the answer from the tester’s first attempt: the mail provider had refused the message because the sending domain had no configuration on its side. That is a setting in a dashboard, not a line of code, and it is the owner’s to fix. But the forgot-password route only checked whether email was set up, meaning whether the binding existed, and it did. So it said what it always says when email is set up, which is that the message is on its way.
This is a shape we keep meeting: a fallback that hides its own failure. The route cannot wait to find out whether the email landed, and it must not tell a stranger whether an address has an account, so it had settled on a sentence that was true in the happy case and never checked the other case.
Remember the last attempt
The route now writes each send down as a health row: when, and whether the provider accepted it. The next person who asks is answered from the newest row. If the last reset email could not be sent, the screen says so: Email is set up here but the last reset email could not be sent, so this one probably cannot be either. The owner has the reason in the Errors screen. Nothing about the address leaks, because the row is about the deployment, not about them. And the moment the owner fixes the domain and one email goes through, the sentence goes back to Check your inbox on its own.
Why not just fix the domain
We will, and it is written down for the owner with the exact setting. But the fix for the configuration and the fix for the screen are different fixes. A product that depends on a provider will meet this again, with a different provider and a different setting, and a screen that remembers the last outcome is the one that tells the truth that day too.
If your code says sent without hearing back, ask what it would say on the day the provider says no. If the answer is the same sentence, the sentence is a guess.