Fail2ban is fundamentally ineffective against distributed attacks. The elegant solution would be to monitor on a per account basis as was suggested by the OP. Of course the block would still have to be an IP block as you can't have a scenario where I can lock another user out of their account simply by spamming their login with bad passwords.
With that said, we have used fail2ban quite successfully with companies who have up to 30 employees behind a single IP. It could scale larger, it's just that our larger clients have their own mail servers and we just do spam/virus filtering for those users.
Here are a few thoughts.
3 attempts is probably too aggressive, even for a single user at a single IP. You will end up blocking a lot of users, increasing your support load unnecessarily and not making your customers/users very happy.
The reason for limiting login attempts is to prevent brute force attacks. What you really need to do is to make it statistically "impossible" for a hacker to learn credentials. In practice that means slowing them down without making life unbearable for legitimate users.
First, consider the size of your password space. Enforce password length and complexity with your accounts.
Take a simple four character alpha password "xarf". The search space depth is just 26 characters. Searching all the passwords from 1-4 characters in that space would require 475,254 attempts. On average the hacker will guess a totally random password in 50% of that, so let's call it 250,000 attempts.
If the 4 character password uses mixed case, digits and symbols, the search space depth increases to 95 characters and the average number of guesses jumps to over 41 million. Now increase the length of the password to 8 characters and the average goes to 3.3 x 10^15 attempts. If a hacker made a thousand guesses per second, it would take approximately 100,000 years to exhaust 50% of the search space.
Of course the problem is that users pick bad passwords. Consider using the 'password' plugin for Roundcube. It does some rudimentary checks and allows you to set complexity and length requirements.
If we assume your users have stronger passwords now, then we can address how fail2ban can be used successfully in your scenario.
Consider that the search space is now huge. What do we really accomplish by limiting the legitimate user to three guesses before locking them out? Certainly we don't want to allow a thousand guesses/second - even if that would take the hacker all those years to brute force their way in. With distributed attacks and the human tendency to dumb down password strength we still need to be cautious.
A serious brute force attack is going to need to make a lot of guesses in a short period of time for it to be effective. We have found that by setting the fail2ban check interval to a relatively short window and relaxing the fail count somewhat, we have crippled the attack and yet not made it so that a couple of users who took a stupid pill overnight block the entire company.
Fail2ban can be used to monitor and block all of your potential email attack surfaces. Our assumption is to block them everywhere. If they are misbehaving on one port, we shut them down everywhere.
Your other option with fail2ban is to whitelist their office IP address, but in practice, we have found this isn't necessary with judicious setting of rules accompanied with strong password policies. Whitelisting would definitely be something to look at if you have larger numbers of users at a single site.
