## TL;DR
Need to send email to a set of people? Distribution list. Need to grant access to something? Security group (mail-enabled if you also need email). Using a distribution list for access control does not work; using a security group for a newsletter is overkill but harmless.

## The error
```text
(Design question; no error.)
```

## Steps
1. Ask what the group is for: email delivery, access control, or both. Expected: answered. The answer picks the type.
2. Email only: create a distribution list. Expected: created. Keep membership maintained by the team owner.
3. Access control: create a security group. Expected: created. If the group also needs an email address, mail-enable it.
4. If you find a distribution list being used for access (shared folder permissions, app assignments): migrate to a security group. Expected: migrated. DLs cannot be used in ACLs and cause exactly the confusion you are seeing.
5. Name it clearly: prefix with DL- or SG- (or your org's convention) so the type is visible. Expected: named. Future admins should not have to guess.

## When to use
- Creating new groups
- Auditing existing groups

## When not to use
- Dynamic membership needs (use dynamic groups)
- Microsoft 365 Groups / Teams (different object with its own rules)

## Compatibility
- Exchange Online, Active Directory, Entra ID

## Variants
### Microsoft 365 Group
Use for team collaboration (mailbox + SharePoint + Teams); not a replacement for security groups in ACLs.
### Nested groups
Security groups nest; distribution lists have limited nesting. Plan accordingly.

## Why it happens
The two objects look similar in admin consoles but serve different systems (mail transport vs access control). Mixing them creates groups that silently fail at one job.

## Edge cases
- Converting a DL to a mail-enabled security group is supported; plan the cutover.
- Audit for DLs in ACLs during access reviews; they are a common finding.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Q0LCZ7LC_L2n6myg1Vpl9A