We run a hybrid on-premises and Microsoft Entra ID/Exchange environment with many distribution lists nested inside larger lists, eventually leading to an All Staff-style top-level list. Occasionally, someone appears to miss messages sent to one of these lists.
I'm using PowerShell and the LDAP_MATCHING_RULE_IN_CHAIN rule (1.2.840.113556.1.4.1941) to check whether each user is a direct or indirect member of a top-level distribution list. The results show that almost nobody is missing, which makes me question whether an AD recursive membership check reflects how Exchange expands recipients.
Do nested groups need to be mail-enabled at every level for Exchange to include their members? Is there a reliable PowerShell or Exchange-based way to determine whether a particular user will actually receive mail sent to a nested distribution list?
4 Answers
Use message or mail-flow tracking for an actual message sent to the top-level list. The tracking details should show how Exchange resolved the group and whether the affected user was included. That will tell you whether this is a membership-expansion problem or something else, such as moderation, delivery restrictions, sender authentication, or a synchronization issue.
Be careful about which directory you query. If the message is being delivered by Exchange Online, checking only the local AD copy may produce misleading results because synchronization, group type, mail enablement, delivery restrictions, and moderation settings can affect the cloud recipient. Query the Exchange organization that actually handles delivery, and verify that each nested group is present and mail-enabled there.
Another practical approach is to expand the top-level list recursively, then compare that result with your expected user population. Test the script with one person who is definitely a direct member, one who is nested through mail-enabled lists, and one who should not be included. That makes it much easier to identify whether the LDAP filter or the group configuration is causing the discrepancy.
A recursive AD membership result is not necessarily the same as Exchange recipient expansion. If a security group is nested inside a distribution list, it generally needs to be mail-enabled for Exchange to treat its members as mail recipients. Check the nesting chain for mail-enabled distribution groups or mail-enabled security groups, rather than testing every AD group in the same way.
For the most accurate result, query Exchange with commands such as Get-DistributionGroup and Get-DistributionGroupMember, especially if the lists are managed in Exchange Online. The cloud directory and on-premises AD can differ after synchronization.
That makes sense. Since the list is too broad for a test message, I can inspect tracking the next time the business legitimately sends mail to it and compare the resolved recipients with the users reported as missing.