Technical analysis

Microsoft 365 Distribution List or Dynamic Group Membership Not Updating: Diagnosing the Cache, Filter, and Sync Layers

Members were added but mail isn't reaching them. Dynamic group filter was changed but the group looks the same. Walk the three sync clocks (Entra Connect, EXO directory, EXO recipient cache) and the filter scope gotchas that produce these failures.

Cover image for Microsoft 365 Distribution List or Dynamic Group Membership Not Updating: Diagnosing the Cache, Filter, and Sync Layers

The complaint that hides three different problems

"I added a person to the distribution list and they're not getting the email." Or: "I updated the dynamic group filter and it still shows the old members." Or: "Microsoft 365 Groups is showing the wrong members in Outlook but the right ones in Teams."

These look like the same problem ("group membership isn't updating") but they're three different problems with three different fixes. The unifying issue is that "the group" isn't one object — it's a directory object in Microsoft Entra, a recipient object in Exchange Online, possibly a synced object from on-prem AD, and a cached view in each Outlook client. There are at least three independent caches between an admin change and the user's mailbox.

This article gives you the three-clock model, the PowerShell to query each clock, the three group types' differences (Distribution List, Mail-Enabled Security, Microsoft 365 Group, Dynamic Distribution Group), and the most common filter mistakes that make dynamic groups silently miss members. References: Manage distribution groups, Dynamic distribution groups, Entra Connect sync cycle.

The three clocks

Any group-membership change in Microsoft 365 has to propagate through up to three independent systems before it affects mail delivery:

Clock Typical latency Why it exists
Entra Connect sync (hybrid only) 30 min default On-prem AD changes sync to Microsoft Entra
EXO directory replication 5-30 min Entra directory changes propagate to EXO's recipient database
EXO recipient cache up to 60 min EXO caches resolved recipients for performance; cache TTL applies after directory changes

In a cloud-only tenant, the first clock doesn't exist (membership changes happen directly in Entra). In a hybrid tenant where groups are managed on-prem, all three apply.

A membership change at 09:00 in on-prem AD might not affect a mail at 09:15 because Entra Connect hasn't synced yet. The same change at 09:35 might still not affect mail because EXO replication is in progress. By 10:00 everything should be aligned, but if a user reports a problem at 09:20, telling them to wait isn't a great answer — they need to know which clock is the cause.

The four group types and how they update

Each group type has different membership-update semantics. Knowing which type you're dealing with is the first diagnostic step.

Type Cmdlet identifier Membership update mechanism
Distribution List Get-DistributionGroup Direct add/remove via admin
Mail-Enabled Security Group Get-DistributionGroup (same cmdlet, RecipientTypeDetails shows MailUniversalSecurityGroup) Direct add/remove via admin
Microsoft 365 Group (Unified) Get-UnifiedGroup Direct add/remove; some flows allow self-join
Dynamic Distribution Group Get-DynamicDistributionGroup Membership computed on-the-fly from a recipient filter

The dynamic group case is fundamentally different: there is no stored membership list. Every time a mail is sent, EXO evaluates the filter against the current recipient set. So "the dynamic group isn't updating" actually means either (a) the filter doesn't match the user you expect it to, or (b) the recipient's properties don't actually match the filter.

The diagnostic in three commands

Step 1: Identify what kind of group it is

Connect-ExchangeOnline
Get-Recipient -Identity "sales-team@contoso.com" |
    Select-Object PrimarySmtpAddress, RecipientType, RecipientTypeDetails

Look at RecipientTypeDetails. If it's DynamicDistributionGroup, jump to the dynamic-group section. If it's MailUniversalDistributionGroup or MailUniversalSecurityGroup, it's a normal distribution group. If it's GroupMailbox, it's a Microsoft 365 Group.

Step 2: For a distribution group, list the actual current members

Get-DistributionGroupMember -Identity "sales-team@contoso.com" -ResultSize Unlimited |
    Select-Object DisplayName, PrimarySmtpAddress, RecipientType

If the user you expected to see isn't in the list, the change either hasn't propagated or wasn't applied. Check the audit log:

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
    -RecordType ExchangeAdmin `
    -Operations Add-DistributionGroupMember, Remove-DistributionGroupMember `
    -FreeText "sales-team@contoso.com" |
    Format-Table CreationDate, UserIds, Operations, ObjectId

This shows every membership change in the last week with who made it. If the expected add doesn't appear in the audit log, the change was never applied.

Step 3: For a Microsoft 365 Group, distinguish members vs owners

Microsoft 365 Groups have separate Members and Owners lists, and the Outlook group view shows members. Add operations sometimes mistakenly add to Owners only.

Get-UnifiedGroupLinks -Identity "marketing@contoso.com" -LinkType Members |
    Select-Object DisplayName, PrimarySmtpAddress

Get-UnifiedGroupLinks -Identity "marketing@contoso.com" -LinkType Owners |
    Select-Object DisplayName, PrimarySmtpAddress

A user in Owners but not Members will appear in Teams (which treats owners as members for most purposes) but not in some Outlook group flows. The fix is Add-UnifiedGroupLinks -Identity marketing@contoso.com -LinkType Members -Links alice@contoso.com.

The dynamic group filter trap

Dynamic groups have a recipient filter. The filter is OPATH syntax over recipient properties. Three things go wrong constantly.

Trap 1: The filter property isn't populated on the user

If the filter is (Department -eq "Sales") but the user's Department attribute is empty (or has different capitalization, or whitespace), they don't match. Verify:

$group = Get-DynamicDistributionGroup -Identity "sales-team@contoso.com"
Get-Recipient -RecipientPreviewFilter $group.RecipientFilter -ResultSize 5 |
    Format-Table DisplayName, PrimarySmtpAddress

# And check the user's relevant attribute
Get-Recipient -Identity "alice@contoso.com" |
    Select-Object DisplayName, Department, CustomAttribute1, CustomAttribute2

Get-Recipient -RecipientPreviewFilter evaluates the filter live against current recipient data and returns what would match if mail were sent now. If the user isn't in the preview, they won't get the mail.

Trap 2: Filter scope is too narrow

The RecipientContainer (OU scope) on a dynamic group limits which recipients the filter searches across. A user outside that OU never matches, regardless of attributes:

Get-DynamicDistributionGroup -Identity "sales-team@contoso.com" |
    Select-Object Name, RecipientContainer, RecipientFilter

If RecipientContainer is set to an OU that excludes the user, expand the container or move the user.

Trap 3: Filter uses IncludedRecipients instead of RecipientFilter

Legacy dynamic groups (created in older Exchange tooling) use IncludedRecipients, ConditionalDepartment, ConditionalStateOrProvince, etc. These are AND'd together. Newer dynamic groups use RecipientFilter (full OPATH). A group that has both attributes can produce confusing results because EXO evaluates the legacy attributes in addition to the modern filter.

Fix: If the group is hybrid (both styles present), pick one and clear the other:

Set-DynamicDistributionGroup -Identity "sales-team@contoso.com" `
    -IncludedRecipients $null -ConditionalDepartment $null `
    -RecipientFilter "(Department -eq 'Sales') -and (RecipientType -eq 'UserMailbox')"

The forced-sync escape hatch (hybrid tenants)

If you've verified the change is applied in on-prem AD and you can't wait for the next Entra Connect cycle:

# Run on the Entra Connect server
Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

For EXO recipient cache, there's no exposed force-refresh — the cache TTL is internal — but creating and immediately deleting a test recipient against the same affected mailbox sometimes prompts EXO to re-resolve cached entries faster. This is an unsupported workaround; treat it as last resort.

A weekly proactive check for stale dynamic groups

Dynamic groups that haven't changed their member count in months are usually broken. Either the filter is wrong, the recipient set hasn't actually changed, or admins are managing the underlying attributes manually and not realising the group depends on them.

# List all dynamic groups with their current preview count
Get-DynamicDistributionGroup -ResultSize Unlimited | ForEach-Object {
    $count = (Get-Recipient -RecipientPreviewFilter $_.RecipientFilter -ResultSize Unlimited).Count
    [pscustomobject]@{
        Name              = $_.Name
        Address           = $_.PrimarySmtpAddress
        Filter            = $_.RecipientFilter
        RecipientContainer = $_.RecipientContainer
        PreviewMemberCount = $count
    }
} | Export-Csv dynamic-group-membership.csv -NoTypeInformation

Run weekly. Sudden changes in PreviewMemberCount (especially drops to zero) indicate a recipient attribute change that broke the filter — usually an AD attribute rename done by an HR-sync script.

Common questions

How long does Entra Connect sync take by default?

The default sync cycle is 30 minutes for delta sync. Initial sync after install is 30-90 minutes depending on directory size. You can verify the schedule with Get-ADSyncScheduler.

Does removing a user from a distribution group take effect immediately?

In EXO, yes — the removal is applied to the EXO directory within minutes. But the EXO recipient cache may still resolve the user as a member for up to 60 minutes on already-cached evaluations. Test from a different client to confirm.

Can I add an external email address to a distribution list?

Yes — create a mail-enabled contact (New-MailContact) for the external address, then add the contact to the distribution group: Add-DistributionGroupMember -Identity sales@contoso.com -Member external@partner.com.

Why does Outlook show different members than the EXO portal?

Outlook clients cache the global address list (GAL) on the local machine. Until the next GAL update (default daily), the local view is stale. Manually trigger a GAL update in Outlook: Send/Receive → Send/Receive Groups → Download Address Book. Uncheck "Download changes since last Send/Receive" to force a full re-download.

What about Microsoft 365 Group membership visible in Teams but not in Outlook?

Teams uses the Microsoft Graph for membership lookups and gets near-real-time data. Outlook uses the EXO GAL cache. The Teams view is typically more current. If Outlook is consistently behind, force a GAL update as above.

A user is in the dynamic group's preview but still doesn't get mail. What now?

Check the mail trace (Get-MessageTrace) for the specific message. If the message status is Delivered but the user reports not seeing it, the issue is at the user's mailbox (rule, retention policy, archive). If the status is Failed or FilteredAsSpam for that user, the issue is downstream of group expansion.

What to take away

Group membership "not updating" is rarely a single problem. The three clocks (Entra Connect, EXO directory, EXO recipient cache) explain most timing complaints. The group-type identification step decides whether you look at stored members or evaluate a filter. The dynamic-group traps (missing attribute, narrow OU scope, hybrid filter style) account for almost every "but the filter looks right" ticket. With the diagnostic commands warm in PowerShell, these tickets close in under 10 minutes — and the weekly preview-count report catches the broken dynamic groups before users notice.

References

About the author

MU

M.UMicrosoft 365 / Entra Engineer

M.U is a hands-on Microsoft 365 and Microsoft Entra engineer. Sentinel Identity is where M.U writes the long-form troubleshooting and architecture notes that ship articles people can actually use in production tenants.

Feedback

Was this article helpful?

Anonymous — no account or comment required.

Send detailed feedback

Related reading