Probably not. Work at a small, software-based company and you end up dealing with lots of email, period. Server notifications, bug reports, user feedback, third-party service provider emails of all kinds, and all that happens before personal emails or ones between employees.
But, outside of that, my 5 accounts tend to get a few dozen per day, a handful more if I don't do any filtering. And they're specifically targeting people with multiple accounts. If this doesn't include work volumes, what does it include, and why do they have multiple accounts? It's not targeting the 99%, period, because it's not part of the OS or Office suite, so who are they targeting?
I've felt for a few years now that server notifications, bug reports, etc, should almost never go to email clients.
Sure you can use email to generate the ticket, but they need to go into a CRM / bug tracking system of some kind. Otherwise everyone ends up overwhelmed with meaningless repetitive emails, like it sounds is happening with you.
These are server notifications and bug reports that have gone through a couple bug tracking systems, and the new and/or exceptional exceptions generate emails. They (and I) could do better at filtering, and some tracking services are better than others, but it's one of those infinite time sinks that has generally not paid off beyond where I am now.
While great in theory, I haven't yet found a single bug tracker that provides reasonable deduplication that doesn't e.g. cause a new issue when the SLOC generating the error changes, just because you added a method to the class. Even allowing me to group two apparently-distinct bugs together manually would be an improvement, both for tracking history and severity, but I haven't found any. They're all too aggressive at grouping X, Y, and Z when they shouldn't, and make 20 piles of A. They are infinitely better than receiving an email for every single one, but still a headache, and they still generate too many false alarms to hook directly up to automated systems.
Then there's also that outright failures that need to immediately be fixed, and semi-unexpected things like insane responses from Facebook, are all useful to track. Unexpected rises in relatively normal Facebook errors can denote problems on either end, possibly fixable in some situations, while seeing a jump in quantity might imply something. If you don't track them continuously, you don't even know if it changes, so 'fixing' / suppressing them completely is hamstringing yourself. So ideally whatever I use would track fix-this-now and investigate-if-it-changes. I haven't found any that do.
Not that I've looked at too many, much less subjected them to large-enough workloads to be sure they're actually an improvement. Wiring up a new bug tracking and notification system (possibly from multiple sources and languages, and setting up paging when major problems happen, etc) is pretty non-trivial. But if you have suggestions, I'd love to hear them, and might even try one or two out professionally this year :)