I’m often asked how to prevent an End user Spam Notification (abbreviated as ESN from this point on) from being sent to a distribution list (abbreviated as DL from this point on). Before getting to the answer, let’s start off with some background information on ESNs to see why this question comes up in the first place.
If you are using the online quarantine in Exchange Online Protection (abbreviated as EOP from this point on), an ESN is one method you can use to give your end users the ability to release items from their quarantine on their own. At a minimum of once a day (can be configured to be longer), ESNs will be sent to users that have received mail in their online quarantine since the last time an ESN was sent. The ESN will contain links that can be used to release any of the messages from their quarantine to their inbox. Here’s an example of an ESN.
Problems can arise when an ESN is sent to a DL as this is typically not desired behavior. Let’s take a look at an example to see why this can be a problem.
We have a company that is using EOP Stand Alone (not Exchange Online) to protect their on-premises Exchange environment which hosts all of their mailboxes. This company is also not using Microsoft Azure Active Directory Sync (abbreviated as DirSync from this point on). A spam message destined to a DL in the company is received by EOP and quarantined in the cloud. In this scenario EOP does not know that the recipient email address is a DL, it just sees an email address.
When the ESN is generated, EOP sends it to the recipient address which happens to be a DL. The on-premises Exchange environment receives the ESN which is destined to a DL, expands the DL, and then delivers the ESN to everyone in the DL. Now let’s say one of users decides they would like to release a quarantined message, and so, they click the Release to Inbox link in the ESN. EOP will release the message from the quarantine and send it to the DL, delivering the message to all members of the DL. This action of a single user can cause a quarantined message to be released to many users.This is certainly not wanted behavior, or at least it usually is not.
There are a few different ways this can occur. The most common is when a DL exists on-premises and is not being synced to Office 365. This could happen if DirSync is either not being used, or has been configured not to sync certain objects, which could include DLs, to Office 365. In the end, if Office 365 does not know about a DL, it will not expand it in the cloud and you will see this behavior.
If the DL exists in Office 365, or is being synced with DirSync from on-premises to your Exchange Online Office 365 tenant, you will not have this issue because the DL will be expanded in the cloud so each member will get their own separate ESN.
Lucky for you preventing this behavior is quite easy. ESNs are always sent from firstname.lastname@example.org, so all we need to do is to stop this address from sending to our distribution lists. The steps I list here are applicable to Exchange Server 2010 and Exchange Server 2013.
You could easily write a loop in PowerShell which could set this attribute for all your distribution lists in one swoop, but I’ll leave that to you to script for your environment.