Using Safelist Aggregation (PART 1)

If you would like to read the next part in this article series please go to Using Safelist Aggregation (PART 2).


If you read my previous article, Using an Exchange 2007 Edge Server as the Mail Relay of an Exchange 2003 Organization, I explained how to take advantage of all the anti-spam, antivirus, and transport rules processing features of the Exchange 2007 Edge server, without requiring the upgrade of the internal servers. Unfortunately this configuration has some limitations, since some features that were made to work exclusively with internal Exchange 2007 servers are not available. One of those features is the safelist aggregation, a combined anti-spam functionality between Microsoft Office Outlook and the Exchange 2007 servers with the transport role: Hub and Edge (other features that are not available in the previous mentioned configuration are Domain Security and recipient lookup).

Safelist Aggregation consists of a collection of each user’s personal spam settings (Safe Recipients Lists), and applying them at the border of the organization, where email messages are accepted or rejected based on their spam classification. The whole process is a very effective way of reducing false-positives in anti-spam filtering, performed by the Exchange Transport servers because users contribute with their own personal settings.

Outlook Junk Email Options

The Outlook Junk Email options were introduced with Microsoft Outlook 2003 and are accessible to each user by going to the Tools menu and then selecting Options. On the Preferences tab (Figure 1), under E-mail, click Junk E-mail.

Figure 1: Outlook Options

There are several levels of protection that can be configured, but more important than that, for the purpose of this article, we are going to focus on the different Junk E-mail filter lists that can be populated and edited by the user:

  • Safe Senders List: A list of domain names and e-mail addresses that you want to receive messages from. E-mail addresses in Contacts and in the Global Address List (GAL) are included in this list by default.

  • Safe Recipients List: A list of mailing lists or other subscription domain names and e-mail addresses that you belong to and want to receive messages from. Messages sent to these addresses will not be treated as junk e-mail.

  • Blocked Senders List: A list of domain names and e-mail addresses that you want blocked. E-mail addresses and domain names on this list are always treated as junk e-mail or spam.

  • Blocked Encodings List: A list that allows you to block a language encoding or character set in order to filter out unwanted international e-mail messages that display in a language you do not understand.

  • Blocked Top-Level Domains List: A list that allows you to block top-level domain names. Blocking country/region top-level domains allows you to filter unwanted e-mail messages you receive from specific countries or regions.

Figure 2: Outlook Junk E-mail Options (Safe Senders)

By default, e-mail addresses in Outlook Contacts and in the Exchange Server GAL are considered safe by the Junk E-mail filter. However, the contacts are not actually added to this list unless you send messages to them while you have the Automatically add people I e-mail to the Safe Senders List check box selected.

Figure 3: Outlook Junk E-mail Options (Safe Recipients)

Safelist Collection

The combined data from the user’s Safe Senders List, Safe Recipients List and external contacts is called Safelist Collection. This data is stored in Outlook and in the Exchange mailbox, but can also be pushed to the Active Directory (stored in each user object). The Safelist Collection is only a subset from the Junk e-mail filter lists we saw on the previous section. Only the “safe” lists are aggregated and will be used by safelist aggregation. The “blocked” lists are only used by Outlook.
Let us take a deeper look into the information stored in an Outlook user’s safelist collection:

  • Safe senders and safe recipients – Safe senders and safe recipients are represented by their SMTP addresses, such as [email protected]. These entries are collected from the user’s Safe Senders and Safe Recipients in Outlook Junk-Email Options.

  • Safe domains – Safe domains ( are defined by the users in the Safe Senders list. The safe domain data can be taken into account by the safelist aggregation process, but it is not recommended, because users may include domains that may be used or spoofed by spammers. Microsoft Exchange Server 2007 Service Pack 1 adds a new switch to the update-safelist cmdlet (-IncludeDomains) that allows you to include or exclude the safe domains in the process.

  • External contacts – There are 2 options in the Safe Senders list configuration from the Outlook Junk E-mail settings: Also trust e-mail from my Contacts and Automatically add people I e-mail to the Safe Senders List. If a user selects these options, the corresponding type of contacts is added to the Safe Senders List.

In the release to manufacturing (RTM) version of Microsoft Exchange Server 2007, a user can have up to 1,024 unique entries (safe senders + safe recipients + safe domains + external contacts) in a safelist collection. With the release of Exchange Server 2007 Service Pack 1, the limit was raised to 3,072 entries.

Safelist Collection Stored in Active Directory

To make the safelist aggregation process work, the safelist collection from the Outlook user mailbox must be uploaded to the active Directory, using the PowerShell cmdlet Update-SafeList.

The safelist collection entries are hashed (SHA-256) and sorted before they are stored in Active Directory as array sets across two binary user object attributes, msExchangeSafeRecipientHash and msExchangeSafeSenderHash (Figure 4). For hashing of safelist collection entries, a 4-byte hash is produced.

Figure 4: msExchSafeSendersHash attribute in AD

One-way hashing of safelist collection entries has the following advantages:

  • It minimizes storage and replication space.

  • It renders user safelist collections unusable by malicious users, in case of a compromise of the server where the data is stored.

When a message is received from the Internet, Exchange Server hashes the sender address and compares it to the hashes that are stored on behalf of the Outlook user to whom the message was sent. If an inbound hash matches, the message bypasses content filtering.

Safelist Collection Data Flow

Uploading the data to the Active Directory is a manual process, by running the Update-SafeList cmdlet (although it can be scheduled to run regularly). Loading the same data to the Edge server is automatic, since the safelist collection data will be included in the Edge Synchronization service (Figure 5), which replicates the following data from Active Directory to ADAM:

Configuration Information

  • Accepted domains

  • Remote domains

  • Message classifications

  • Send Connectors

  • Hub Transport server list (for dynamic connector generation)

  • TLS Send and Receive Domain Secure lists

  • Internal SMTP Servers list

Recipient Information


  • Recipients

  • Proxy Addresses (Hashed)

  • Safe Senders List (Hashed)

  • Safe Recipients List (Hashed)

  • Per recipient anti-spam settings (Hashed)

Table 1: Data synchronized between AD and ADAM

Figure 5: EdgeSync synchronization process (image courtesy of Microsoft)

Let us now look in more detail at the recipient information, since this is the data relevant to the safelist aggregation process. The recipient information replicated to ADAM includes the following:

  • Recipients – The list of all the recipients with mailboxes in the Exchange organization is replicated to ADAM. Each recipient is identified by the GUID assigned to it in Active Directory (Figure 6).

  • Proxy addresses – All proxy addresses assigned to each recipient are replicated to ADAM as hashed data. Proxy addresses are referenced when the Edge Transport server performs the recipient lookup anti-spam task (Figure 7).

  • Safe Senders List and Safe Recipients List – The Safe Senders Lists and Safe Recipients Lists that are defined in each recipient’s Outlook instance are aggregated and replicated to ADAM as hashed data. Information about blocked senders is not replicated (Figure 8).

  • Per Recipient anti-spam settings – If a user has per recipient anti-spam settings, these settings override the organization-wide settings and are replicated as hashed data to the Edge ADAM. These SCL thresholds can be configured using the Set-Mailbox cmdlet (Figure 9).

Figure 6: Recipients in ADAM

Figure 7: proxyAddresses

Figure 8: msExchSafeSendersHash attribute in ADAM

Figure 9: Per-user anti-spam settings

If you remove an Edge Subscription, all the replicated data is also removed and you will no longer be able to use the Edge Transport features that rely on this recipient data.


This concludes part 1 of this 2-part article. We saw how the safelist aggregation process helps in reducing false positives in anti-spam filtering, and we examined the different kinds of data involved (safe lists) and how it flows from each user’s mailbox to the Active Directory and finally to the Exchange Edge server.

Related Links

If you would like to read the next part in this article series please go to Using Safelist Aggregation (PART 2).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top