To my knowledge, you won’t be able to achieve exactly what you mentioned with the built-in reset password functionality and this is intentional. The reason for this is that in order to guard against privacy issues the reset password API public response will not distinguish between a request issued for an email address associated with an existing user versus one associated with a non-existing user. If it did, this would open up the possibility for an unknown party to enumerate the registered users of your service.
You may want to consider tweaking the current success message to hint at the fact that the email will only be sent if the email is associated with a valid user and that the end-user should make sure they are using the correct email. If you want to disregard the privacy guard and still have a flow that would react differently depending on the fact that the user does not exist then you’ll need to implement your own custom reset password flow, however, this would not be recommended.