Exchange 2010 Domain Security (Part 2)


If you would like to read the other parts in this article series please go to:


This is the second part of an article looking at the Exchange 2010 feature known as domain security. In part one of this article, we covered the lab environment that we will be using and then proceeded to configure Edge synchronization between’s Edge Transport and Hub Transport servers.

Here in part two, we will continue with our configuration of’s Exchange infrastructure by performing operations such as configuring Send connectors, making the required DNS changes and testing both name resolution and connectivity with tools such as the Telnet client and NSLookup. We will then begin to configure’s internal Exchange 2010 infrastructure for domain security by running Exchange Management Shell cmdlets specifically targeted for domain security.

Send Connector for

We now need to create a new Send connector on’s internal Exchange 2010 server. Specifically, this must be configured on the Hub Transport server role. This Send connector will be responsible for processing email sent to the namespace and, ultimately, ensuring that it is configured for domain security. First, though, we will create the connector and simply check that we can successfully send email between and users. By creating the new Send connector on the Hub Transport server, the connector will be synchronized onto’s Edge Transport server by the Edge synchronization process.

The Send connector should be created with an address space of so that all emails for users within the domain are processed by this Send connector and not the general purpose Internet email connector created during the Edge subscription process. There are two other very important configuration elements to note regarding the creation of a Send connector when considering Edge subscriptions and also the future use of domain security. The first is that the Send connector must use DNS MX records to route email; do not configure the connector to use a smart host. This is shown in Figure 2-1. You may also note from Figure 2-1 the option to Enable Domain Security (Mutual Auth TLS); we will be enabling this later as part of the overall configuration for domain security.

Figure 2-1: Configuring the Send Connector to Use DNS MX Records

The second important configuration element with regards to the Send connector is to ensure that the Source Server tab is configured with the Edge Transport server and not the local Hub Transport server. This is shown in Figure 2-2. This must be configured in order to ensure the Send connector is synchronized into the Edge Transport server.

Figure 2-2: Setting the Edge Transport Server as the Source Server

The Edge synchronization process will create the corresponding Send connector on the Edge Transport server. You can ensure this happens straight away by running the Start-EdgeSynchronization cmdlet on the Hub Transport server. Once you’ve done this, check that you see the new Send connector in the Exchange Management Console on the Edge Transport server.

DNS Requirements

Since we have configured the Send connectors to use DNS MX records, it follows that the DNS server (that the Edge Transport server is configured to use in this lab) must have the required MX records for the Edge Transport server. To do this, we need to create a zone for on the DNS server and add an MX record for as well as an A record for the Edge Transport server. Figure 2-3 shows the MX record for the domain as configured on’s DNS server. You can see that the host is configured as the fully qualified domain name of’s Edge Transport server and that we’re using the default priority weighting of 10.

Figure 2-3: Creating the MX Record

Once the MX record has been created, we then need to create an A record for the Edge Transport host Once both records have been created, the zone will look like the example shown in Figure 2-4.

Figure 2-4: DNS Records for the Zone

On’s Edge Transport server, we can run the nslookup utility to confirm that the DNS records are configured correctly. The command to run is:

nslookup –q=mx

The –q=mx portion of the command tells nslookup to set the query type to MX records. After that, we simply specify the name of the domain that we want to query. The output returned from nslookup reads as follows:   MX preference = 10, mail exchanger =  internet address =

We can see that, as far as the Edge Transport server is concerned, the mail server for the domain is with an IP address of It’s now a good idea to test connectivity via the SMTP port (port 25) between the and Edge Transport servers. To do this, we can use the Telnet Client but note that, on Windows 2008 R2, this is not installed by default.

To install the Telnet Client on’s Edge Transport server, click Start / Administrative Tools / Server Manager to run the Server Manager program. In the left-hand pane, click Features and then select the Add Features link that appears in the right-hand pane. In the Select Features wizard, add the Telnet Client option as shown in Figure 2-5. Complete the wizard and the Telnet Client is installed; no reboot is necessary.

Figure 2-5: Installing the Telnet Client Feature

Once the Telnet Client has been installed, we can telnet to the Edge Transport server from the Edge Transport server on port 25 and confirm that the banner is displayed. This is shown in Figure 2-6.

Figure 2-6: Testing Port 25 Connectivity With the Telnet Client

At this stage we have not configured domain security yet so it’s a good idea to ensure that mail flow is possible from to via the Edge Transport servers. Therefore, at this point, make sure that you send test messages from to to ensure that email connectivity is working before we enable domain security.

Configuring Domain Security

Now that we know both and users can email each other through the Edge Transport servers, it’s now time to look at the configuration required to implement domain security. The first thing on the agenda would typically be the certificate configuration on the Edge Transport servers, but I’m going to leave that for a moment as we will use the default self-signed certificates and see what errors and/or issues we get; it will be useful for future troubleshooting if you can see how certificate issues manifest themselves when implementing domain security.

The Exchange organization needs to be configured such that the domain is both an outbound and inbound domain for domain security. To do this, we use the Set-TransportConfig cmdlet since the requirement is to make an organizational change and the Set-TransportConfig cmdlet makes organization changes to the transport configuration. Note that the Set-TransportConfig cmdlet needs to be run on the internal Exchange 2010 server, not the Edge Transport server.

The parameters of interest are TLSSendDomainSecureList and TLSReceiveDomainSecureList. These parameters contain a list of domains for which we have enabled domain security from either an inbound (receive) or outbound (send) perspective. Let’s first run the Get-TransportConfig cmdlet to see what these parameters are set to by default. As you can see from Figure 2-7, these parameters are empty.

Figure 2-7: Results of Get-TransportConfig Using Default Configuration

It follows that we must set both of these parameters to have a value of This is achieved by running the following two commands:

Set-TransportConfig –TLSSendDomainSecureList –TLSReceiveDomainSecureList

Once set, we can check the parameters have taken effect as you can see from Figure 2-8.

Figure 2-8: Setting’s Inbound and Outbound Domain Secure List


Although we have made quite a few configuration changes to the environment in this article, there still remains quite a few configuration changes to make which we will be continuing to look at in part three of this article. Specifically, we’ll be covering areas such as configuring the Send and Receive connectors with Mutual Auth TLS, and then seeing what happens when we try to send a test message when we haven’t made any certificate changes.

If you would like to read the other parts in this article series please go to:

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