First things first, you need a Project tracking automated system. No requests of any type unless the requestor enters them into the system. This step alone will eliminate a great deal of the requests. Hey if they don't think it is important enough to request officially, then it is not important enough to do.
Now you have everything in one place you can start to make lists by client or organization or what ever you need. You can take the list to a weekly (biweekly, monthly depending on the circumstances) meeting for the client and set priorities so that you know what order things need to be done in. You can tell people that you already have 33 items ahead of this one on the list and that it will be X weeks until you get to it. If a new hot priority comes in, you can tell them exactly what is going to be delayed (this often has the effect of cooling down the priority!). Rule 1 never accept more work without delaying something currently on the list.
Your job is to keep these lists and negotiate the priorities with the client(internal or external). When you have multiple clients, you need to havea way to determine how to balance the priorities. If they are internal, I usually have just let them work it out between tehmeselves and do not delay X's Number 1 priority to get to Y's new priority. If they are outside clietns or cannot work out priorities amoing themselves, you may need to decide on dedicated people for each client. So you still set priorities but only for that client and they know that the work will be done in priority order. If a client has a sudden influx of work and another one is less busy, you can move assets around, but once you commit people to a client, they don't get removed from a priority project to work on something else unlsess it is a total emergency. If you are in dedicated person mode, priorities can shift but only within the client's projects.
In many ways the Agile practices can help you here. You commit to a set amount of work in a sprint and then don't change that. New priorities are for the next sprint. (This may take some convincing on the part of your clients but once they get used to it, I'll bet they will like it better than a steady stream of half-finished projects abandoned for the priority of the moment.) The exception of course would be a production emergency, but if you have those, you need to plan a certain number of hours in each sprint for them and thus still be able to meet your teams commitments for the sprint.
Now with all projects in some sort of tracking system, you can have details about those projects added to the tracking system as well rather than in emails. That way you can get out from under the sea of unofficial emails. (If people continue to send you stuff by email and not through the sytem, that stuff is the lowest priority by definition. Send an email to each person who does this every time telling them that the item will not be worked on until it is in the official system. Write a standard blurb so you don't have to waste more than a few seconds doing this per email. If someone won't quit doing that, make sure to copy his boss on the standard "do this through the offical system" email.)
You now know what projects are priorities, so you check the discussions in the projects each morning in priority order. With all the discussion about project A in one place, it is easier to read them all in a coherent way and to see what has to be responded to. Further, you now only need to look in priority order, so if something comes up on the lowest priority task, you aren't distracted by it becasue you don't have to read it to figure out which project it belongs to.