That's probably something that's best done at the email server level, and not at the filemaker server level.
Depending on how your email is setup (exchange or IMAP), you should be able to write rules that run a script that either forwards emails to an account that filemaker reads from, or to a Custom Web Publishing page that turns it into a filemaker record.
Hooking into the email box of everyone in the company would be time consuming and kludgy. Also, this type of work requires constant ongoing support as user accounts are added/deleted and the rules change.
An easier solution would be to just have the users forward the email to a single email account that is pulled into filemaker as a record.
Short answer: Yes. I'm not sure which part you need help with, so I'll describe what we do, and you can tell me if it makes sense, or which parts don't....
We use FM as our main email client, in conjunction with 360Works email plugin.
We have a table for accounts. We don't store passwords there, or use that for actual security, but we do have the username and information about the person who holds that account. An administrative (non-developer) user can fill out the record in this table then via script/button, create the actual user account.
We also have a table of email accounts, with smtp and pop or imap details. One user may have zero to many email accounts.
We have system settings for online fax details (like eFax, MetroFax, RingCentral, etc.) so that incoming emails from those senders are recognized as faxes. We also have Mobile Service Providers so that, if available for a mobile phone, we can email to text, and also recognize text to email. We also recognize anything from a voicemail email (in our case, Vonage) as actually being a voicemail instead of an email.
We read the email header to "thread" our emails, and connect them to the same elements as our original messages. So, if I have an outbound email associated with ABC project, and I get a reply, our receiving routine identifies the message to which this is a reply, and links the reply to ABC project, as well.
Because the receipt of emails is a single script, we can add things there such as recognizing when the activity, though coming via email, isn't really an email, but rather a text, voicemail or fax. We can identify threads so that replies, forwards, etc. are linked, but also so that we can file/link items in the thread according to how the original message was filed/linked. We could also parse the subject or body to do other things, like create records and such.
If you do that, you'd want some control over who can send you an email that's going to "do stuff" in your solution. Depending on what you're trying to trigger with an incoming email, you may need to be concerned with who can send such a powerful email to your solution, and how to definitively tell that the email isn't from a malicious and/or incompetent sender. ;-)
Below are some screen shots to give you a further idea....
Hope this helps...