I have some questions regarding user experience when it comes to throttling email requests from public pages in my app such as Signup Email Verification and Password Recovery.

First of all, I want to throttle requests because I do not want to spam email recipients with my app's transactional emails. I am concerned about User A trying to signup an account using User B's email address for the sake of annoying User B at my app's expense (like getting flagged as spam)

I haven't read a fool proof approach to protect apps from these types of attacks (if you know of one, I would really appreciate it if you can tell me).

Currently I have implemented a captcha, but I would also like to implement throttling. So my questions would be:

  1. How many times would I let a user send a request before I throttle sending emails for the same request? I did a single quick test with facebook, and I learned they throttle password recovery emails after the 3rd try.

  2. How long should I throttle the request? 10 minutes? 30 minutes?

  3. Should I A) let the user know I throttled the request, like placing a notice? or B) Act like I didn't do anything? Facebook did (B). I think it is more of a security thing? But, my problem is that, if I choose (B), a legitimate user not receiving any emails would keep on requesting for the whole throttling period. Which would be very bad UX?

  • 2
    Are you sure this potential misuse situation is actually a likely one though? You could design safety features for all sorts of potential situations, but if they're never really that big a risk in the first place perhaps your energy could be best used elsewhere?
    – JonW
    Commented Jan 26, 2018 at 16:44
  • @JonW I agree with you on that 100%, but for this one the main problem is our domain's sending reputation (or sender score?). Being a startup with low sending rate, the percentage of a spam attack like this can really hurt our sending reputation with email systems and it would be very difficult to recover from it. Correct me if I am just being over paranoid.
    – Jo E.
    Commented Jan 26, 2018 at 16:49
  • 1
    No, that's a fair point - that is a valid situation. But it's more of a business driver than one of user experience. Not that it matters here though - the solutions to the problem still impact the user experience.
    – JonW
    Commented Jan 26, 2018 at 16:52
  • @JonW Yeah, we really wanted to make it more open, but we had to really consider some worst case scenarios and how great the impact will be. So we decided to do it in the end. Right now we wanted to learn some best practices from others for the throttling so that we do not over discourage potential users.
    – Jo E.
    Commented Jan 26, 2018 at 16:55

1 Answer 1


Something to remember about transactional emails is that they should be intentionally triggered by the user. What this means is a site shouldn't send a confirmation or password reset email unless the user directly requests it.

Why does that matter? Because if the user intentionally did something, you don't need to ask them to do it again. They already went through the trouble. Though you may be concerned about people exploiting the system, design for your typical user first. Once a particular form is submitted, like for a password reset, there's no reason to even have that form be available anymore until the password has been reset. This means, simply don't send the same email twice. Of course, minor exceptions exist, but for the most part there isn't a good reason for a user to receive the same email over and over again.

When it comes to throttling rates, the answer to what you should do specifically is this: For those on dedicated IPs, your throttle rate should be fine tuned to match your IP reputation. (It never hurts to know this.) If you're on a shared IP, your host might be handling that for you. This means, quite commonly, err on the safe side and throttle as much as possible. The last thing you want is to be flagged by an ISP as spam.

You don't need to let the user know about your batch process. Only inform the user about their experience and how that experience is being affected. This means saying something to the effect of:

We sent you an email [to do a thing]. You should see it in your inbox within [a timeframe]. If you don't see it, *let us know* and we'll sort things out.

If you detect that something shady is likely going on, then lock the account, but don't blame the user. Just inform them through a secure method of the steps that should be taken to fix things.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.