Accepted Domains, Safe Senders List and You
Published Jul 08 2011 01:20 PM 131K Views

You may have noticed a change in the behavior of the Safe Senders list within Outlook starting in Exchange 2010. Users can no longer add accepted domains to Outlook’s Safe Senders list.

Screenshot: Adding an accepted domain to Outlook's Safe Senders list
Figure 1: Adding an accepted domain to Outlook's Safe Senders list

This was done as an anti-spam deterrent as we have all seen cases where Joe The Spammer spoofs the mail from your own domain. Adding your own domain to the Safe Senders list would bypass all Outlook client-side anti-spam checks, dumping that message from the Nigerian prince (spoofed using your own domain) into your users’ Inboxes. Not so good unless you were really waiting for that business opportunity.

A valid SPF record and our anti-spam agents (specifically the SenderID agent) would go a long way to block these types of spam. However, many customers out there have not exactly jumped on the SPF bandwagon.

You can learn more about SenderID filtering in Sender ID and Understanding Sender ID. Use the Sender ID Framework SPF Record Wizard to create an SPF record for your domain.

With Exchange 2010, you CAN still add individual email addresses from your own accepted domains to the Safe Senders list - you just can’t add the entire domain, as shown in the screenshot above.

What happens if you DO decide to add the whole domain?

If you try to do this for a user via the Shell, you will get the very helpful error below:

“<@yourdomain.com>” is your e-mail address or domain and can’t be added to your Safe Senders and Recipients list.


Figure 2: If you try to add an accepted domain to user’s Safe Senders list using the Shell, you get an error indicating its your domain or e-mail address

We tell you exactly why we are throwing an error.

How about when a user does this via Outlook? First, Outlook lets the user add a domain.


Figure 3: Although users can add an accepted domain to their Safe Senders list in Outlook, it is automatically removed in a few minutes

However after a few minutes the entry will magically disappear.

The Disappearing Safe Senders List

In Exchange 2010 SP1, a bug was introduced where if the user added the accepted domain to his/her Safe Senders list via Outlook - not only would the accepted domain entry disappear but it would take the user’s entire safe senders list with it. This was fixed in E2010 SP1 RU3v3 where we are back to the expected behavior.

Allowing app servers to send as your own domain

Many customers have various applications that submit mail anonymously to Exchange where the messages come from email addresses from your accepted domains.

Some of you have apps submitting from so many accepted domain addresses that it wouldn’t be feasible (let alone fun) attempting to add all of these addresses individually to the safe senders list in Outlook to ensure these messages do not end up in junk mail.

Now that we can’t add the whole domain, what are our options?

  • We know that adding all the addresses manually is an available albeit painful option
  • A second option is to disable Outlook’s client side filtering (yeah... not a good idea, so do not seriously consider it. Spam checks out the window!)
  • A third and best option is to install the anti-spam agents on your relay hub(s) and add the IPs of your app servers to the IP Allow list of the connection filtering agent as documented here.

When the sending SMTP host’s IP address is on the IP Allow List in Exchange, it bypasses all anti-spam checks (except sender/recipient filtering) and the Content Filter agent stamps an SCL of -1 on the message which Outlook will honor.

Here's what the message header will look like:

X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-Antispam-Report: IPOnAllowList
X-MS-Exchange-Organization-SCL: -1

So, go ahead and run the Install-AntispamAgents.ps1 from the Scripts folder on your Hub Transport server, and then add IP addresses or subnets of our application servers to the IP Allow List.


Figure 4: Adding IP address or address range of internal app servers to the IP Allow List using the EMC

If using the Shell, use this command to add an IP address to the IP Allow List:

Add-IPAllowListEntry –IPAddress 192.168.10.120

What Not To Do: Using Externally Secured Authentication

Now I know what you’re thinking: Why don’t we just add Externally Secured Authentication as an authentication type on a Receive Connector, scope the connector’s remote IP range to the sending application servers and call it a day?

Well, not so fast... you see, while Externally Secured gives the sending IP the ms-Exch-Bypass-Anti-Spam extended right, this only circumvents the Exchange Anti-Spam checks, not Outlook’s. And it is Outlook that’s moving the message into junk mail in this case.

Also note that Externally Secured does not stamp any SCL X-headers on the message as an SCL of -1 would’ve bypassed Outlook’s checks. The only header this authentication type creates is the one below:

X-MS-Exchange-Organization-AuthAs: Internal

If you're still confused about Exchange and Outlook anti-spam checks, take a look at Exchange anti-spam myths revealed.

Big thanks to Tak Chow for tech reviewing this post.

Tom Kern

11 Comments
Not applicable

I understand the logic with the change, and it's hard to disagree with the logic, but by the time the message makes it to the user's Outlook mailbox it has mostly been tagged and flagged as spam already (or not), and any additional processing by Outlook should, in fact, reflect the user's preferences of what is or isn't spam as the final consideration. Consider:

As a system administrator, I get a LOT of technical newsletters by email, and I've often had them misflagged as spam (SonicWALL's forum posts come to mind), so I've added the appropriate "sonicwall.com" domain to my safe list with the understanding that spoofing attempts from that domain COULD occur. I have to admit that since upgrading I've been wondering why my Outlook filters seemed inconsistent, and now I understand why.

Now I realize you're protecting John and Jane Consumer here, but, would it not have been simpler (and less disruptive to preference) to have added a dialog confirmation to Outlook confirming the choice to add a domain instead of specific address? Something like, "Adding a domain to the Safe Senders List can result in spoofed addressing reaching your inbox. Do you really want to add the domain to your Safe Senders List? Yes No"

Not applicable

Hmm, I've re-read the post, and I apologize... you're saying this change only affects the user's ability to add their own domain names, correct? If so, nevermind my earlier post... maybe. It still seems like something that should be permissable with a confirmation, since often times users don't stop to think, "maybe I should contact my admin to let him know about this."

Not applicable

@GoodThings2Life: You shouldn't be receiving email *from* your domain (i.e. where domain part in sender address is your accepted domain) sent by unauthenticated/untrusted senders. Internal or trusted senders (e.g. your app servers, etc.) should send over authenticated session or a scoped Receive Connector with appropriate permissions. See HOW TO: Prevent annoying spam from your own domain.

Not applicable

Unfortunately your approach has left us in many large non centralized academic communities high and dry.  We are left with no choice but to tell our users to disable the Outlook SPAM filtering and we have had to disable SPAM scoring all together on our on prem Exchange servers.   All very difficult to explain to users, so all they really understand at this point is that they are better off if they use Google for email instead because important emails get lost.

Not applicable

lame idea.  sorry, I know that sounds extreme, but thats my opinion based on working at large companies.  since it is not practical to use authenticated mail relay from 4000+ printer/scanners, not to mention using service accounts to send authenticated alerts from 5000+ various systems, it is not practical to address this issue from the server side.

Not applicable

@UWEmailSys, if you install the anti spam agents on the hub(s) that is receiving mail from your app servers and then put those servers on the IP allow list you will not have to disable outlook's anti-spam checks.

We do NOT advise turning off outlook's AS checks.

@Nivritti, I understand that setting up all your app servers to auth is not practical that is why I proposed installing the anti-spam agents on the hub(s) your app are relaying off of and putting those IPs on the allow list.

Ultimately while it may seem expedient to put your entire accepted domain on a safe list from a security standpoint this would be not be a good idea particularly with how spoofing one’s domain is such a prevalent tactic for spammers out there.  Using the IP allow lists or pushing out safe lists to outlook via a GPO are two good ways to handle these situations where on the one hand you'd like you app relays to send from different local addresses AND want your user's inboxes free from spam.

Thanks

Not applicable

Thanks Tom, I like the article and invetive use of Exchange anti spam agents.

This should be revised showing best practice clearly and the preference order of actions.

1. Have app servers authenticate using a service account, (they’ll likely have one anyway), use one service account over many printers/scanners and allow it to authenticate – or use a sub domain like scanners.company.com

a. Not printers, scanners and monitoring alerts in general don’t need to relay so need no additional permissions on the send connector.

b. Authenticated connections always get SCL-1

2. Move to the above authenticated model for all new relay devices and choose one of the below methods for existing devices you can’t change.

3. install the anti-spam agents on your relay hub(s) and add the IPs of your app servers to the IP Allow list of the connection filtering agent

a. also you could add entire server subnets

b. script the following - query DHCP servers for printer reservations and add them to the allow list

4. We know that adding all the addresses manually is an available albeit painful option

5. A second option is to disable Outlook’s client side filtering (yeah... not a good idea, so do not seriously consider it. Spam checks out the window!)

Tom

Not applicable

I certainly understand that you don’t advise turning off the Outlook checks, but by the statement about adding addresses to our hubs you make it clear that you do not understand or have considered real world scenarios many of us are facing. (or apparently any Office365 user for that matter.)  Ultimately, your reticence to allow the less perfect preference of not using IPs for delivery assurance will lead us to a world were either much of our email will end up in junk folders,  we will have to safe list *.*.*.*, or our users will flee for Google Apps who doesn’t have this tenant of faith.

The truth is sometimes a bit of SPAM is preferable to the dropping of important emails.

PS.  Your stance seems to completely disrespect our published SPF of ?ALL.  If you were respecting it you would treat any IPs as neutral.  Why don’t you follow SPF when it exists?  

Not applicable

Great post thanks!

Not applicable

So how does one work around this issue after migrating to Office 365? Office 365 does NOT allow adding individual email addresses from my own domain (they are removed if added thru Outlook, and rejected if added through OWA). Add-IPAllowListEntry fails from the Office 365 shell.

I've got mail from myself that Forefront passes (due to safelisted IP of my outbound SMTP host) and that has X-MS-Exchange-Organization-SCL: 0, but Outlook still drops it in Junk E-Mail. How can I convince Outlook that it is not junk?

Not applicable

With the help of MS Partner Support, I have a workaround for Office 365:  use New-TransportRule to force SCL -1 on mail from my own email address or domain. Blogged here:

Office 365, Safe Senders List and You

www.mcbsys.com/.../office-365-safe-senders-list-and-you

Version history
Last update:
‎Jul 01 2019 04:00 PM
Updated by: