On-premises Microsoft Exchange supports three types of Active Directory groups – security groups, distribution groups and dynamic distribution groups. Each group has its own purpose and limitations, so which group should you use when?
Email-Enabled Security Groups
Security groups are not normally used for email distribution, but instead are a way to give access to something; such as read access to a file, or remote desktop access to a sever. However, it is possible to mail enable a security group to make it function like a distribution group while still being used for security purposes; but this is generally not recommended. A single purpose for a single group makes an environment more manageable and flexible; for example, giving a Security Group called 'Finance', giving that group access to the Finance network drive and then mail enabling it will work, but as soon as they want someone to get Finance emails but not access to their documents, you'll need to create extra groups and undo your original design... or even worse, assign individual permissions to a folder.
Now that I've hopefully convinced you to avoid mail enabled security groups, we have distribution groups. These groups cannot be used for security purposes and are purely used for containing a list of accounts and groups to send emails to. You can have nested groups (i.e. groups inside groups), but personally I wouldn't go any further than 2 layers deep or things start to get confusing.
The members of a distribution group can be changed at any time, and changes are instant; Exchange will receive an email for a distribution group and send to all the members listed. Outlook will also show all the members of a distribution group in its address book. Even if you're running Outlook in cached mode, and have an offline address book, members of a distribution list are pulled off the server on demand. This gives users the ability to always see who is in a distribution group, to know who exactly is going to receive their email.
Dynamic Distribution Groups
One negative of a distribution group is the manual management of its members. Someone will need to add and remove members as requirements change, unless you automate this somehow.
For this reason, many people consider and use Dynamic Distribution Groups. Instead of having a list of members and manually adding or removing them, you can set up filters or rules on who is a member. This can be a simple rule, such as 'Users with the department 'Finance', or it can be more complex, such as 'Users in OU 'Los Angeles' that aren't disabled, and on Exchange database 03 as long as their last name isn't Jones'. This is great for being able to set up a rule for who is and isn't in a group, that you don't need to worry about ongoing.
Automation of Group Membership
Automation of tedious tasks is usually a good thing, but there's one giant catch with Dynamic Distribution Groups; the membership of the group gets evaluated at the time an email is sent to it. That sounds OK in itself but leads to the problem of the Outlook Address Book. Because there's no static list of membership to refer to, users can't actually ever see who's in the group. Going back to the 'Finance' group example - how does a user know that all the Finance staff will get the email sent to them? What about the person who sometimes does Finance work, and sometimes HR? On the flip side, is there someone who isn't in Finance that might receive the email that they really only want Finance staff to see?
For some environments, this will be a problem that the users won't accept as a way to use distribution groups. The best answer I can give for this is to do your own automation. You can either write up your own scripts (with PowerShell or another language you're comfortable with) to run on a regular basis, that can add or remove members to a standard Distribution Group based on the filtering you define. There's also of course Adaxes that can automate AD group membership for you. It takes out the requirement of having to script it yourself and follow more of an Outlook Rules style of configuration to automate membership. E.g. here’s an example of how you can automatically add users to groups based on their department.
There's never a perfect answer that covers all usage scenarios and will make everyone happy, but it's worth understanding what the options are and the user experience of each. If you can apply logic to your groups though, automating the ongoing task of adding and removing users should be something that gives any admin more time to work on other problems and solutions, rather than performing repetitive work.