Spoofed Internal Sender with Distribution Lists
- 2 Manual Solution:
- 2.1 How to detect / fix
- 2.1.1 Detecting
- 2.2 Fixing
- 2.2.1 Office 365 Only
- 2.2.2 On-Premise Active Directory
- 2.2.3 Alternatives - NOT RECOMMENDED
- 2.1 How to detect / fix
Summary
A message sent to a distribution list which a specific configuration results in the email being flagged as a “Spoofed Internal Sender.” Update an INKY connector to prevent such messages from being bannered as “Spoofed Internal Sender.”
Setting
Go to https://tools.inkyphishfence.com and login in a global admin.
Select “More”, “Update OBC-VPC-O365-RETURN Connector” and follow the prompts.
Confirm your connectors show the version as being 20210514 or newer.
Manual Solution:
This article explains the issue with “ReportToOriginatorEnabled” set to false check.
External recipients don't get distribution group email - Exchange
*There is a typo in the Cause section that MS has not fixed.
Under the cause section it should read:
"When the parameters are set to False, the Return-Path field in the header of the message is <> (blank)."
In order to utilize the Inky banner removal service we require that outbound mail be properly formatted.
Exchange provides two options for reporting NDRs (nondelivery reports) to mails addressed to distribution groups.
Report To Originator Enabled - The most straight forward / least confusing - This is the default on new group creation NDR reports are sent to the sender of the message.
Report To Manager Enabled - Slightly more confusing - This can be chosen in its place. NDRs would be sent to the groups Owner or the user specified in the groups Managed By attribute.
Exchange allows administrators to set both options to FALSE. If this is done then the Return Path / From field is set to <> and the message will not be deliverable by the Inky banner stripping process.
Also if there were to be any delivery failures on any messages they would not be reported, as no system would know where to send the NDR.
When in doubt about choosing to turn on ReportToOriginatorEnabled or ReportToManagerEnabled, choose to turn on ReportToOriginatorEnabled. There is only very specific cases in which you would want to turn ReportToManagerEnabled on. Typically these cases have very few admins on a large group where only the admins can send emails and they do so as the distribution group (not themselves). A good example of this would have to be a company wide newsletter.
How to detect / fix
Detecting
You can check for any of your groups that may have this issue by running the following powershell command on On-Prem AD or AzureAD (if in Hybrid mode choose On-Prem as any changes on AzureAD will be erased when it resyncs with the cloud).
Get-DistributionGroup | Where-Object -Property ReportToOriginatorEnabled -CEQ $false
Get-DistributionGroup | Where-Object -Property ReportToManagerEnabled -CEQ $false |
---|
Fixing
Office 365 Only
Then you could run this power shell in order to change all of the groups to true for ReportToOriginatorEnabled
$DGs = Get-DistributionGroup | Where-Object -Property ReportToOriginatorEnabled -CEQ $false | Select-Object -expand ExternalDirectoryObjectId foreach($DG in $DGs){Set-DistributionGroup -ReportToOriginatorEnabled $true -Identity $DG} |
---|
Or if you want to change all of the groups to true for ReportToManagerEnabled you could run this power shell
Get-DistributionGroup | Where-Object -Property ReportToManagerEnabled -CEQ $false | Set-DistributionGroup -ReportToManagerEnabled $true |
---|
On-Premise Active Directory
If you’re environment is utilizing on-premise active directory utilize the below commands to fix the issue.
$groups= get-adgroup -Properties name,mail,reporttooriginator -Filter *; foreach($group in $groups) |
---|
Alternatives - NOT RECOMMENDED
Try the commands above first. If they do not work you can try the commands recommended by Microsoft.
Set-DistributionGroup "<DistributionGroupName>" -ReportToOriginatorEnabled $true |
---|
Set-DistributionGroup "<DistributionGroupName>" -ReportToManagerEnabled $true |
---|