Troubleshooting
Problem
Users may receive emails sent to an email group even though they are not explicitly listed as members of that group. This behavior is intentional in Exchange Online and is typically caused by group nesting, dynamic membership rules, mail flow (transport) rules, forwarding configurations, or direct addressing. This document provides most of valid diagnostic methods and recommended corrective actions.
Symptom
Several causes identified, but not limited to the below ones:
- User receives emails sent to a group they are not marked as a member of
- User does not appear in the Exchange Admin Center (EAC) group membership list
- Group membership changes do not appear to affect delivery
- Issue persists across Outlook clients and Outlook on the web
Cause
Cause 1: Direct vs. Effective Group Membership
Exchange expands group membership at delivery time. Users may be included indirectly.
Cause 2: Nested Distribution Groups (Most Common)
Cause 4. Microsoft 365 Group or Teams Group
Emails may be sent to a Microsoft 365 Group rather than the intended DG.
Cause 5: Mail Flow (Transport) Rules
Mail flow rules can add, redirect, or BCC recipients regardless of group membership
Users may receive email because:
• They are listed as a proxy address (alias)
• Another mailbox forwards to them
• Shared mailbox or contact routing
Environment
- Microsoft 365
- Exchange Online
- Hybrid Exchange environments
- Distribution Groups (DG)
- Dynamic Distribution Groups (DDG)
- Mail-enabled Security Groups
- Microsoft 365 Groups
Diagnosing The Problem
Prerequisite:
Before starting, Open Exchange Online PowerShell to run cmdlets.
- Click Start
- Search for PowerShell
- Right‑click Windows PowerShell
- Select Run as administrator
Ensure you have:
- Exchange Online administrative permissions (e.g., Exchange Admin, Global Admin)
- Exchange Online PowerShell Module installed
- Network access to Microsoft 365
- Open Exchange Online PowerShell
- Open Windows PowerShell as Administrator
- Connect to Exchange Online by running:
Connect-ExchangeOnline
- Sign in using your Microsoft 365 admin credentials.
Cause 1: Diagnosing:
Diagnostic Steps
Run the below cmdlet:
Get-DistributionGroupMember -Identity "GroupName"
or using its expanded content version:
Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup "GroupName").RecipientFilter
- Review the output for nested groups
- If another group is listed, users may inherit membership
- Run the Diagnostic Cmdlet
- Execute the following command, replacing GroupName with the actual distribution group name or email address:
- Example:
Get-DistributionGroupMember -Identity "GroupName"
Get-DistributionGroupMember -Identity "IT-Alerts"
- Example Output:
Name RecipientType
---------- -------------
John Smith UserMailbox
Helpdesk-Team MailUniversalDistributionGroup
HR-Notifications MailUniversalDistributionGroup
Important
If you see any group objects listed, this confirms nested membership.
To view members of the nested group, run:
Get-DistributionGroupMember -Identity "Helpdesk-Team"
or using its expanded content version:
Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup "GroupName").RecipientFilter
Repeat this step if multiple layers of nesting exist.
Cause 2: Diagnosing:
Diagnostic Steps
- Run the below cmdlets:
Get-DistributionGroupMember -Identity "GroupName
Or recursive validation:
function Get-GroupMembersRecursive {
param ([string]$Group)
Get-DistributionGroupMember -Identity $Group | ForEach-Object {
if ($_.RecipientType -like 'Group') {
Get-GroupMembersRecursive $.Name
} else {
$_
}
}
}
Get-GroupMembersRecursive "GroupName"
Prerequisites
- Please consider the same prerequisites as the Cause 1.
- Please repeat the same step 1 as well as the Cause 1.
- Run the Diagnostic Cmdlet
- Please repeat the same step 2 as well as the Cause 1.
- Example Output
Name RecipientType
---- -------------
John Smith UserMailbox
IT-Support-Level2 MailUniversalDistributionGroup
Interpretation
- John Smith is a direct member
- IT-Support-Level2 is a nested distribution group
- All users inside IT-Support-Level2 inherit membership
Define the Recursive Function:
Function Get-GroupMembersRecursive {
param (
[string]$Group
)
Get-DistributionGroupMember -Identity $Group | ForEach-Object {
if ($.RecipientType -like 'Group') {
Get-GroupMembersRecursive $.Name
} else {
$_
}
}
}
Get-GroupMembersRecursive "GroupName"
What This Function Does:
Step | Description |
|---|---|
Retrieves group members | Get-DistributionGroupMember |
Detects nested groups | RecipientType -like "*Group*" |
Recursively expands | Calls itself |
Outputs only users | Final expanded membership |
Example Recursive Output
Name RecipientType
---- -------------
John Smith UserMailbox
Linda Wu UserMailbox
Olivia Mitchell UserMailbox
Interpretation
- Users Linda Wu and Olivia Mitchell are not direct members
- They are members of nested groups
- They inherit membership in Helpdesk-Team
Helpdesk-Team
├── John Smith
└── IT-Support-Level2
├── Linda Wu
└── Olivia Mitchell
Why Recursive Validation Is Required:
Nested groups may contain:
- Other distribution groups
- Security groups
- Multiple layers of nesting
Recursive validation expands all nested layers
Common Findings & Root Causes:
Scenario | Cause |
|---|---|
User receives emails unexpectedly | Nested group membership |
Group looks empty in EAC | Hidden nested groups |
Too many recipients | Legacy group nesting |
Difficult troubleshooting | No recursive audit |
Cause 3: Diagnosing
Prerequisites
- Please consider the same prerequisites as Cause 1.
- Please repeat the same step as Cause 1.
Diagnostic Steps
Run the below cmdlets:
Get-DynamicDistributionGroup -Identity "GroupName" | Format-List Name,RecipientFilter
Check user attribute match:
Get-Recipient user@domain.com | fl Department,Title,Office,CustomAttribute*
Identify Whether the Group Is Dynamic
Run the Command:
Get-DynamicDistributionGroup -Identity "GroupName
Expected Output (Example)
Name : Management-DDG
RecipientFilter : ((Department -eq 'Management'))
RecipientTypeDetails : UserMailbox
``
How to Interpret
If the command returns output → the group is Dynamic
If the command fails → the group is static (use DG diagnostics instead)
Cause 4: Diagnosing.
Prerequisites
- Please consider the same prerequisites as Cause 1.
- Please repeat the same step as Cause 1.
Important:
Get-UnifiedGroupLinks works only for Microsoft 365 Groups, not Distribution Groups.
Is it feasible to list group members and owners by using the Get-UnifiedGroupLinks cmdlet:
Diagnostic Steps
Run the below cmdlet:
Get-UnifiedGroupLinks -Identity "GroupName" -LinkType Members
Example 1:
Get-UnifiedGroupLinks -Identity "MarketingTeam" -LinkType Members
Example Output (Partial)
This confirms the group is a Microsoft 365 Group, and membership must be checked using Unified Group cmdlets.
Expected Result
Command returns group details → this is a Microsoft 365 Group
Command fails → group is not Unified (use DG or DDG diagnostics instead)
How to Interpret
- Each entry represents a direct member of the Microsoft 365 Group
- If the affected user appears in this list, email delivery is expected
- Microsoft 365 Groups do not support nested groups, so membership is always direct. Users can receive messages due to subscription settings, even if not actively viewing group membership.
Run the cmdlet:
Get-UnifiedGroupLinks -Identity "GroupName" -LinkType Subscribers
Cause 5: Diagnosing.
Prerequisites:
Same prerequisites as previous causes, including:
Exchange Online PowerShell connected
Permissions: Organization Management or Compliance Management
Affected user’s email address
Sample email with full message headers
Diagnostic Steps
Run the below cmdlet:
Get-TransportRule | Select Name,State,Mode,Priority
Message header indicators:
- X-MS-Exchange-Organization-TransportRules
List All Transport (Mail Flow) Rules
Example Output (Partial)
Name : Add BCC for Compliance
Conditions : SenderAddressLocation -eq 'Header'
Actions : BlindCopyTo recipients@domain.com
Name : Redirect Vendor Messages
Conditions : FromAddressMatchesPatterns vendor@partner.com
Actions : RedirectMessageTo audit@domain.com
Second Sample Outputs:
Name : Add Disclaimer to External Emails
How to Interpret the Output:
Focus on Actions, especially:
Action | Impact |
|---|---|
BlindCopyTo | Adds hidden recipients |
AddToRecipients | Adds visible recipients |
RedirectMessageTo | Redirects message entirely |
CopyTo | Sends a copy to another mailbox |
| Condition | Meaning |
|---|---|
FromScope:NotInOrganization | Sender is external |
SentToScope:NotInOrganization | Receiver is external |
From:user@company.com | Sent from specific user |
SentTo:user@company.com | Sent to specific user |
SubjectContainsWords:X;Y | Subject has X OR Y |
AttachmentExtensionMatchesWords:.exe | Has blocked file type |
SentToMemberOf:GroupName | Sent to group |
If the affected user or a group they belong to appears here, email delivery is expected.
Example Hidden redirection:
Even if John is NOT in the Sales group, any email sent to sales@company.com is also sent to John Doe.
Cause 6: Diagnosing.
Diagnostic Steps
Run the below cmdlets:
Get-InboxRule -Mailbox user@domain.com
Get-Mailbox user@domain.com | fl ForwardingAddress,DeliverToMailboxAndForward
Prerequisites:
Same prerequisites as previous causes, including:
Exchange Online PowerShell connected
Exchange Administrator or appropriate mailbox permissions
Affected user’s email address
Sample email for correlation (recommended)
Step 1: Check Inbox Rules for the User Mailbox
Diagnostic Command
Get-InboxRule -Mailbox user@domain.com
Example Output (Partial)
Name : Forward invoices
Enabled : True
Description : Forward invoice emails
RedirectTo : accounting@domain.com
ForwardTo : manager@domain.com
SubjectContainsWords : Invoice
How to Interpret the Output
Review the following properties carefully:
Property | Meaning |
ForwardTo | Sends a copy of the message to another recipient |
RedirectTo | Sends the message and removes the original recipient |
SendTextMessageNotificationTo | Sends alerts (not delivery-related) |
DeleteMessage | Message may never reach inbox |
Enabled | Confirms the rule is active |
If the affected user appears in ForwardTo or RedirectTo, email delivery is expected.
Step 2: Identify Rules Likely to Trigger Unexpected Delivery
Pay close attention to:
- Rules with no sender restriction
- Rules using SubjectContainsWords
- Rules forwarding to groups or shared mailboxes
Example Risky Rule
Name : Forward all external email
Enabled : True
ForwardTo : teamlead@domain.com
Every inbound message is forwarded, regardless of original recipient.
Step 3: Check Mailbox‑Level Forwarding Configuration
Inbox rules are not the only forwarding mechanism. Mailbox‑level forwarding applies globally to the mailbox.
Diagnostic Command
Get-Mailbox user@domain.com | fl ForwardingAddress,DeliverToMailboxAndForward
Example Output (Forwarding Enabled)
ForwardingAddress : sharedmailbox@domain.com
DeliverToMailboxAndForward : True
How to Interpret
Setting | Behavior |
ForwardingAddress populated | Mailbox forwards all messages |
DeliverToMailboxAndForward = True | User receives a copy + forward |
DeliverToMailboxAndForward = False | Message only forwarded |
If forwarding is configured, the user may receive email without being a direct recipient.
Cause 7: Diagnosing.
Diagnostic Steps
Run the below cmdlet:
Get-MessageTrace -RecipientAddress user@domain.com | Select MessageId,SenderAddress,Received
Prerequisites
Same prerequisites as previous causes:
Exchange Online PowerShell connected
Permissions: View-Only Recipients, Message Tracking, or higher
Affected user’s SMTP address
Approximate time the email was received (recommended)
Step 1: Run Message Trace for the Affected User
Diagnostic Command:
Get-MessageTrace -RecipientAddress user@domain.com |
Select MessageId, SenderAddress, Received
Step 2: Understand the Output
Example Output
MessageId SenderAddress Received
--------- ------------- --------
<CAEPx12345@sender.com> alerts@partner.com 3/16/2026 14:22
<BNYQx67890@domain.com> hr@domain.com 3/16/2026 09:10
Field Explanation
Field | Description |
MessageId | Unique identifier for the message across Exchange |
SenderAddress | Actual envelope sender processed by Exchange |
Received | Timestamp (UTC) when Exchange accepted the message |
If the message appears here, Exchange successfully delivered or routed it to the mailbox.
Step 3: Correlate with the Reported Email
Match the trace output with:
- Sender address
- Approximate delivery time
- Message subject (if needed, via extended trace)
This step confirms you are troubleshooting the correct message.
Step 4: Expand the Investigation (When needed)
If multiple messages appear or additional details are required:
Diagnostic Command:
Get-MessageTrace -RecipientAddress user@domain.com -StartDate 03/16/2026 -EndDate 03/17/2026
Narrows delivery dates
Reduces noise for high‑volume mailboxes
Important note:
- Get-MessageTrace cmdlet only shows last 10 days (standard)
- Older traces require:
Start-HistoricalSearch
Step 5: Interpret Message Trace Results
Scenario 1: Message appears in Message Trace
Exchange intentionally delivered the message
Next steps:
Correlate with:
Group Expansion (Causes 1–4)
Dynamic Distribution Groups (Cause 3)
Transport Rules (Cause 5)
Inbox Rules / Forwarding (Cause 6)
Use message headers to determine why
Scenario 2: Message does NOT appear in Message Trace
Exchange did not process delivery to this mailbox
Possible causes:
Client‑side rule (Outlook only)
External forwarding after delivery
User misidentified the message
Incorrect recipient address used
Cause 8: Diagnosing:
Step 1: Collect Full Message Headers (Source of Truth)
Outlook (Windows / Mac):
- Open the message
- Select File → Properties
- Copy everything under Internet headers
Outlook on the Web:
- Open the message
- Select ⋯ (More actions) → View → View message details
- Copy the full header text
Step 1 – Collect Full Message Headers (Source of Truth)
Why This Step Is Critical
Full message headers are the single authoritative source to determine:
Whether Exchange Online expanded a group
Whether a Dynamic Distribution Group was evaluated
Whether a transport (mail flow) rule modified delivery
Whether forwarding or redirection occurred
The exact recipient and routing path
Partial headers are not sufficient.
Screenshots of the email body, “View source” snippets, or copied lines from Outlook do not provide reliable diagnostic evidence.
Prerequisites:
Access to the affected mailbox
The exact email exhibiting unexpected delivery
Desktop Outlook or Outlook on the Web (OWA)
Step‑by‑Step Procedure
1. Open the Affected Email
Open Outlook
Double‑click the email so it opens its own window
Do not use the preview pane!!
2. Access Message Properties
Windows Outlook
Select File
Select Properties
MACOS Outlook
Select Message
Select Properties (or View Source, depending on version)
3. Locate the Internet Headers Section
In the Properties window, find the field labeled:
Internet headers
This field contains all routing, policy, and expansion metadata.
4. Copy the Entire Header Block
- Click inside the Internet headers text box
- Press Ctrl + A (or Cmd + A on Mac)
- Press Ctrl + C (or Cmd + C)
Ensure the copied text starts with headers such as:
Received:
Return-Path:
Authentication-Results:
and ends with the final routing entry.
Example (What a Valid Header Block Looks Like)
Received: from NAM11-MW2-obe.outbound.protection.outlook.com
X-MS-Exchange-Organization-ExpandedMembers:
X-MS-Exchange-Organization-TransportRules:
X-MS-Exchange-Organization-DynamicGroupExpansion: True
This confirms the header capture is complete and valid.
Common Mistakes (Desktop Outlook)
Mistake | Impact |
Copying only visible lines | Missing routing evidence |
Sending screenshots | Not searchable |
Copying “View source” snippets | Incomplete |
Forwarding the email | Headers are altered |
Outlook on the Web (OWA)
Objective
Capture headers directly from the Exchange Online service.
Step‑by‑Step Procedure
1. Open the Email in OWA
- Sign in to https://outlook.office.com
- Open the affected message
2. Open Message Details
- Select ⋯ (More actions) in the email toolbar
- Select View
- Select View message details
3. Copy the Full Header Text
A new pane opens titled Message details.
- Select all text in the window
- Copy the full contents
The text should include:
Received:
To:
X-MS-Exchange-Organization-*
Example (OWA Header Snippet)
X-MS-Exchange-Organization-Recipient-Expanded: True
X-MS-Exchange-Organization-TransportRules:
RuleName: Add_BCC_Compliance;
Confirms header collection was successful.
Once collected, these headers will be analyzed to diagnose.
Cause 9: Proxy Address / Alternate Address Matching
Please validate the alternate email address by using this cmdlet:
Get-Recipient user@domain.com | fl EmailAddresses
Possible Output Examples:
EmailAddresses : {SMTP:user@domain.com, smtp:user.alias@domain.com, smtp:firstname.lastname@domain.com}
where:
- SMTP: (uppercase) means Primary SMTP address
- smtp: (lowercase) means Secondary/alias addresses
EmailAddresses : {SMTP:user@domain.com,
smtp:user.alias@domain.com,
SIP:user@domain.com,
X500:/o=ExchangeLabs/ou=Exchange Administrative Group/cn=Recipients/cn=user123}
where:
- SIP: → Used for Teams/Skype for Business
- X500: → Legacy Exchange address (used for email reply compatibility)
You may also see:
- SPO: (SharePoint Online)
- EUM: (Unified Messaging, legacy scenarios)
Resolving The Problem
Resolving The Problem
Cause 1 Solution: Direct vs. Effective Membership
- Remove the nested group from the parent distribution group, or
- Remove the user from the nested group, or
- Redesign the group structure to eliminate indirect/transitive membership chains
Best Practice: Keep distribution groups flat where possible to simplify troubleshooting
Cause 2 Solution: Nested Distribution Groups
- Remove unintended nested groups from the parent group
- Flatten the group hierarchy to reduce complexity
- Replace nested groups with a single, well-defined membership list if feasible
Best Practice: Avoid multi-level nesting (more than 1–2 levels deep)
Cause 3 Solution: Dynamic Distribution Groups (DDG)
- Modify the
RecipientFilterto properly scope membership:
- Correct user attributes (Department, Title, CustomAttributes, etc.) to ensure proper evaluation:
- Convert the DDG to a static distribution group if dynamic behavior is not required
Best Practice: Use clear, documented attribute rules for DDGs
Cause 4 Solution: Microsoft 365 Groups
- Remove the user from the Microsoft 365 Group:
- Check and disable user subscription (if applicable):
Cause 5 Solution: Mail Flow (Transport) Rules
- Identify and modify the rule causing unintended delivery:
- Disable the rule temporarily for validation:
- Remove unintended actions such as:
BlindCopyToAddToRecipientsRedirectMessageTo
Best Practice: Always include exception conditions when targeting broad rules
Cause 6 Solution: Mailbox Forwarding and Inbox Rules
Remove Inbox Rules:
Disable Mailbox Forwarding:
- Periodically audit mailbox rules
- Restrict automatic forwarding where possible
Cause 7 Solution: Message Trace Validation
- Use Message Trace results to confirm delivery path
- Based on findings, apply the appropriate fix:
- Group expansion → Causes 1–4
- Transport rules → Cause 5
- Forwarding → Cause 6
Best Practice: Always correlate:
- Message ID
- Timestamp
- Sender
This ensures accuracy before applying remediation
Cause 8 Solution: Message Header Analysis (Definitive Root Cause Identification)
Step 1: Analyze Key Header Indicators
After collecting full headers, search for the following fields:
| Header Field | Meaning | Action |
|---|---|---|
X-MS-Exchange-Organization-ExpandedMembers | Group expansion occurred | Investigate nested groups (Cause 1–2) |
X-MS-Exchange-Organization-DynamicGroupExpansion: True | DDG evaluated | Review DDG filter (Cause 3) |
X-MS-Exchange-Organization-TransportRules | Mail flow rule applied | Review transport rules (Cause 5) |
X-MS-Exchange-Organization-Recipient-P2-Type | Shows resolved recipient type | Confirms how recipient was categorized |
Delivered-To: | Final recipient mailbox | Confirms delivery endpoint |
X-Forwarded-For / X-MS-Exchange-Inbox-Rules-Loop | Forwarding or inbox rule | Investigate mailbox rules (Cause 6) |
To: vs Delivered-To: mismatch | Indicates redirection or expansion | Validate routing logic |
Step 2: Correlate Header Data with Other Diagnostics
Use headers together with:
- Message Trace (Here is the completed and polished “Cause 8 Solution” section, along with a slightly enhanced closing to make the document consistent and actionable for support engineers:
Cause 8 Solution (Completed):
Use message trace results together with full message header analysis to accurately confirm the root cause of the unexpected email delivery.
Resolution Workflow:
- Confirm Delivery Path
- Use
Get-MessageTraceto verify that Exchange Online processed and delivered the message. - Identify the exact MessageId, sender, and timestamp.
- Use
Analyze Header Indicators Examine the collected headers for the following key indicators:
Header Field Meaning Action X-MS-Exchange-Organization-ExpandedMembersShows group expansion occurred Investigate nested groups (Cause 1 & 2) X-MS-Exchange-Organization-DynamicGroupExpansion: TrueDynamic Distribution Group was evaluated Review DDG filters (Cause 3) X-MS-Exchange-Organization-TransportRulesTransport rule modified delivery Review mail flow rules (Cause 5) X-Forwarded-For/X-MS-Exchange-ForwardingLoopForwarding detected Check inbox/mailbox forwarding (Cause 6) To:vsDelivered-To:mismatchIndicates indirect delivery Check group expansion or redirection - Map Header Findings to Root Cause
- Match header evidence with one of the identified causes:
- Group expansion → Causes 1 or 2
- Dynamic evaluation → Cause 3
- Rule-based routing → Cause 5
- Forwarding/redirect → Cause 6
- Match header evidence with one of the identified causes:
- Apply Corrective Action
- Once the mechanism is confirmed, apply the corresponding resolution from Causes 1–6.
- Do not make changes until the exact mechanism is verified via headers.
- Validate Resolution
- Send a test message to the group
- Re-run message trace
- Confirm:
- The affected user no longer receives the message
- No unintended recipients are included
Final Recommended Approach (Best Practice)
For consistent and accurate troubleshooting, follow this order:
- Start with Message Trace (Cause 7)
Confirms that Exchange delivered the message. - Use Header Analysis (Cause 8)
Identifies why the message was delivered. - Validate Membership and Rules (Causes 1–6)
Pinpoints the exact configuration responsible.
Key Takeaways
- Exchange Online delivery is deterministic and explainable — unexpected delivery always has a traceable cause.
- Message headers are the ultimate source of truth.
- Most cases are caused by:
- Nested groups (most common)
- Dynamic Distribution Groups
- Mail flow rules or forwarding
- Always correlate trace + headers + configuration before applying changes.
Cause 9 Solution:
The Get-Recipient user@domain.com | fl EmailAddresses cmdlet resolves the object user@domain.com to the actual Exchange recipient and then displays all email proxy addresses tied to that object. In other words, shows which mailbox (or object) owns this email, and what other addresses also route to it.
What these resolves to:
| Address Type | Meaning |
|---|---|
SMTP:user@domain.com | Primary email address (used for sending) |
smtp:user.alias@domain.com | Alias (also delivers mail to same mailbox) |
SIP:user@domain.com | Used for Teams/Skype identity |
X500:... | Legacy Exchange DN (for reply consistency) |
Document Location
Worldwide
Was this topic helpful?
Document Information
Modified date:
26 May 2026
UID
ibm17270725