Do You Need a Mail-Enabled Security Group for Shared Mailbox Access?
Short answer: usually not, and adding one can create a second identity to keep in sync for no benefit. Here's the actual difference and where it matters.
Mail-enabled vs. plain security group
A plain (non-mail-enabled) AD security group has no email address and exists purely to grant permissions or, via Entra Connect, to authorize access to resources. Amail-enabled security group has both jobs at once: it can be used for permissions the same way, and it also has an SMTP address so people can email the group directly and have it fan out to every member's inbox.
A distribution group only does the second job — it has an email address and fans out messages, but it cannot be used to grant permissions on its own, because it isn't security-enabled.
Which one does a desired-state reconciliation model need?
A group used as the source of truth for shared mailbox delegation is being used as amembership list, not as an email distribution mechanism. What matters is that the group is security-enabled — mail-enabled or not — so that group membership can be resolved reliably and, where relevant, that the group itself can be assigned rights elsewhere in the directory. Whether it also carries an SMTP address is a separate, optional property that doesn't change how membership-based reconciliation reads it.
Making a group mail-enabled purely so it can double as a distribution list for the same people who have mailbox access is a legitimate reason to do it — but it isn't a requirement of the delegation model itself, and it adds a second thing (the group's mail attributes) that has to stay correct alongside its membership.
What breaks if the group loses its security flag
A group that is converted from security-enabled to a plain distribution list — intentionally or by an accidental edit in the admin center — stops being usable as a permissions source. Any reconciliation process reading that group for desired state should treat a non-security group as a broken mapping and flag it rather than silently doing nothing.
Exact Tenvero-supported group types
Tenvero maps each shared mailbox to on-prem AD security groups for Full Access, Send As and Send on Behalf. If your environment relies on mail-enabled security groups specifically, or on cloud-only Entra security groups with no on-prem AD object, confirm current support against the latest Tenvero documentation or with the Tenvero team before planning a migration around it — this guide intentionally avoids asserting broader compatibility than is verified for the version you're running.