IBM Support

Diagnosing and Resolving Unexpected Email Delivery to Users Not Listed in an Email Group

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)

A group can contain other groups. Exchange recursively expands them.

 

Cause 3: Dynamic Distribution Group Membership
 
Dynamic Distribution Groups evaluate recipients using directory attributes at send time.

 

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

 

Cause 6: Mailbox Forwarding or Inbox Rules
 
Mailbox-level rules or forwarding can redirect messages automatically.

 

Cause 7: Message Trace Validation
Confirms the delivery path and recipient resolution
 
 
Cause 8: Message Header Analysis Walkthrough (Step-by-Step)
This walkthrough provides a practical, repeatable process to analyze message headers and visually identify the exact reason a user received an email. This section is intended for Tier‑1 through Tier‑3 support and can be used during live customer calls.
 
Cause 9: Proxy Address / Alternate Address Matching

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

  1. 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
  1. 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"

  1. 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

  1. Run the below cmdlets:

Get-DistributionGroupMember -Identity "GroupName

  1. 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.
  1. Example Output
    Name                        RecipientType

----                          -------------

John Smith                 UserMailbox

IT-Support-Level2     MailUniversalDistributionGroup

  1. Interpretation

  • John Smith is a direct member
  • IT-Support-Level2 is a nested distribution group
  • All users inside IT-Support-Level2 inherit membership
  1. 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"

  1. 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

  1. 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

  1. Why Recursive Validation Is Required:

Nested groups may contain:

  • Other distribution groups
  • Security groups
  • Multiple layers of nesting

Recursive validation expands all nested layers

  1. 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)

Name                 RecipientType
----                 -------------
John Doe             UserMailbox
Jane Smith           UserMailbox
Carlos Lopez         UserMailbox
Ana Martinez         UserMailbox
 
Example 2:
 
Get-UnifiedGroupLinks -Identity "MarketingTeam" -LinkType Members | Format-List
 
Example Output (Detailed)
 
Name                           : John Doe
Alias                            : jdoe
PrimarySmtpAddress   : john.doe@company.com
RecipientType             : UserMailbox
ExternalEmailAddress :
 

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       : Block External Auto-Forward
Actions    : {DeleteMessage}
Conditions : {SentToScope:NotInOrganization, MessageTypeMatches:AutoForward}

Name       : Add Disclaimer to External Emails
Actions    : {ApplyHtmlDisclaimer}
Conditions : {SentToScope:NotInOrganization}
 
Name       : Redirect CEO Emails
Actions    : {RedirectMessageTo}
Conditions : {From:ceo@company.com}

 

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

 

ConditionMeaning
FromScope:NotInOrganizationSender is external
SentToScope:NotInOrganizationReceiver is external
From:user@company.comSent from specific user
SentTo:user@company.comSent to specific user
SubjectContainsWords:X;YSubject has X OR Y
AttachmentExtensionMatchesWords:.exeHas blocked file type
SentToMemberOf:GroupNameSent to group

If the affected user or a group they belong to appears here, email delivery is expected.

Example Hidden redirection:

Name       : Redirect Sales Emails
Conditions : {SentTo:sales@company.com}
Actions    : {RedirectMessageTo:john.doe@company.com}
 

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 highvolume 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:

  • Clientside 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):

  1. Open the message
  2. Select File → Properties
  3. Copy everything under Internet headers

Outlook on the Web:

  1. Open the message
  2. Select  (More actions) → View → View message details
  3. 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)

StepbyStep Procedure

1. Open the Affected Email

Open Outlook

Doubleclick the email so it opens its own window

Do not use the preview pane!!

 

2. Access Message Properties

Windows Outlook

  1. Select File

  2. Select Properties

MACOS Outlook

  1. Select Message

  2. 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

  1. Select (More actions) in the email toolbar
  2. Select View
  3. 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 RecipientFilter to properly scope membership:
 
  • Correct user attributes (Department, Title, CustomAttributes, etc.) to ensure proper evaluation:
Set-User user@domain.com -Department "CorrectValue"
 
 
 
  • 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:
Remove-UnifiedGroupLinks -Identity "GroupName" -LinkType Members -Links user@domain.com
 
 
 
  • Check and disable user subscription (if applicable):
Set-UnifiedGroup -Identity "GroupName" -AutoSubscribeNewMembers:$false
 
 
Best Practice: Confirm whether users are subscribed to inbox delivery vs. just group membership

 

Cause 5 Solution: Mail Flow (Transport) Rules

  • Identify and modify the rule causing unintended delivery:
Set-TransportRule -Identity "RuleName" -ExceptIfRecipientIs user@domain.com
 
 
 
  • Disable the rule temporarily for validation:
 
  • Remove unintended actions such as:
    • BlindCopyTo
    • AddToRecipients
    • RedirectMessageTo

Best Practice: Always include exception conditions when targeting broad rules

 

Cause 6 Solution: Mailbox Forwarding and Inbox Rules

Remove Inbox Rules:

Remove-InboxRule -Mailbox user@domain.com -Identity "RuleName"
 
 
 

Disable Mailbox Forwarding:

Set-Mailbox user@domain.com -ForwardingAddress $null -DeliverToMailboxAndForward $false
 
 
Best Practice:
  • 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 FieldMeaningAction
X-MS-Exchange-Organization-ExpandedMembersGroup expansion occurredInvestigate nested groups (Cause 1–2)
X-MS-Exchange-Organization-DynamicGroupExpansion: TrueDDG evaluatedReview DDG filter (Cause 3)
X-MS-Exchange-Organization-TransportRulesMail flow rule appliedReview transport rules (Cause 5)
X-MS-Exchange-Organization-Recipient-P2-TypeShows resolved recipient typeConfirms how recipient was categorized
Delivered-To:Final recipient mailboxConfirms delivery endpoint
X-Forwarded-For / X-MS-Exchange-Inbox-Rules-LoopForwarding or inbox ruleInvestigate mailbox rules (Cause 6)
To: vs Delivered-To: mismatchIndicates redirection or expansionValidate 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:

  1. Confirm Delivery Path
    • Use Get-MessageTrace to verify that Exchange Online processed and delivered the message.
    • Identify the exact MessageId, sender, and timestamp.
  2. Analyze Header Indicators Examine the collected headers for the following key indicators:

    Header FieldMeaningAction
    X-MS-Exchange-Organization-ExpandedMembersShows group expansion occurredInvestigate nested groups (Cause 1 & 2)
    X-MS-Exchange-Organization-DynamicGroupExpansion: TrueDynamic Distribution Group was evaluatedReview DDG filters (Cause 3)
    X-MS-Exchange-Organization-TransportRulesTransport rule modified deliveryReview mail flow rules (Cause 5)
    X-Forwarded-For / X-MS-Exchange-ForwardingLoopForwarding detectedCheck inbox/mailbox forwarding (Cause 6)
    To: vs Delivered-To: mismatchIndicates indirect deliveryCheck group expansion or redirection
  3. 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
  4. 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.
  5. 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:

  1. Start with Message Trace (Cause 7)
    Confirms that Exchange delivered the message.
  2. Use Header Analysis (Cause 8)
    Identifies why the message was delivered.
  3. 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 TypeMeaning
SMTP:user@domain.comPrimary email address (used for sending)
smtp:user.alias@domain.comAlias (also delivers mail to same mailbox)
SIP:user@domain.comUsed for Teams/Skype identity
X500:...Legacy Exchange DN (for reply consistency)

 

 

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB66","label":"Technology Lifecycle Services"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SSUCXG","label":"Microsoft Other Applications"},"ARM Category":[{"code":"a8mKe000000004SIAQ","label":"Other Applications"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":""}]

Document Information

Modified date:
26 May 2026

UID

ibm17270725