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 nghcloud.co.uk’s Edge Transport and Hub Transport servers.

Here in part two, we will continue with our configuration of nghcloud.co.uk’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 nghcloud.co.uk’s internal Exchange 2010 infrastructure for domain security by running Exchange Management Shell cmdlets specifically targeted for domain security.

Send Connector for neilhobson.com

We now need to create a new Send connector on nghcloud.co.uk’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 neilhobson.com 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 nghcloud.co.uk and neilhobson.com users. By creating the new Send connector on the Hub Transport server, the connector will be synchronized onto nghcloud.co.uk’s Edge Transport server by the Edge synchronization process.

The Send connector should be created with an address space of neilhobson.com so that all emails for users within the neilhobson.com 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 nghcloud.co.uk DNS server (that the nghcloud.co.uk Edge Transport server is configured to use in this lab) must have the required MX records for the neilhobson.com Edge Transport server. To do this, we need to create a zone for neilhobson.com on the nghcloud.co.uk DNS server and add an MX record for neilhobson.com as well as an A record for the Edge Transport server. Figure 2-3 shows the MX record for the neilhobson.com domain as configured on nghcloud.co.uk’s DNS server. You can see that the host is configured as the fully qualified domain name of neilhobson.com’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 neilhobson.com Edge Transport host ds-cedge.neilhobson.com. 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 neilhobson.com Zone

On nghcloud.co.uk’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 neilhobson.com

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:

neilhobson.com   MX preference = 10, mail exchanger = ds-cedge.neilhobson.com

ds-cedge.neilhobson.com  internet address =

We can see that, as far as the nghcloud.co.uk Edge Transport server is concerned, the mail server for the neilhobson.com domain is ds-cedge.neilhobson.com with an IP address of It’s now a good idea to test connectivity via the SMTP port (port 25) between the nghcloud.co.uk and neilhobson.com 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 nghcloud.co.uk’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 neilhobson.com Edge Transport server from the nghcloud.co.uk 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 nghcloud.co.uk to neilhobson.com via the Edge Transport servers. Therefore, at this point, make sure that you send test messages from nghcloud.co.uk to neilhobson.com to ensure that email connectivity is working before we enable domain security.

Configuring Domain Security

Now that we know both nghcloud.co.uk and neilhobson.com 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 nghcloud.co.uk Exchange organization needs to be configured such that the neilhobson.com 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 neilhobson.com. This is achieved by running the following two commands:

Set-TransportConfig –TLSSendDomainSecureList neilhobson.com –TLSReceiveDomainSecureList neilhobson.com

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

Figure 2-8: Setting nghcloud.co.uk’s Inbound and Outbound Domain Secure List


Although we have made quite a few configuration changes to the nghcloud.co.uk 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:

Neil Hobson

Published by
Neil Hobson

Recent Posts

Cybersecurity 101: Close the door on open network shares

If you have open network shares on your network, you are opening the door to…

2 hours ago

Spear-phishing email results in U.S. gas pipeline ransomware attack

A spear-phishing email has resulted in a U.S. gas pipeline ransomware attack. Making the attack…

6 hours ago

Planning your Azure reserved instances and flexibility groups

To really lower your Azure costs, you need actionable information. Get info on flexibility groups…

9 hours ago

MGM Resorts customer data breach still being utilized by hackers

Data stolen from breaches often live on forever, as appears to be the case with…

1 day ago

Arranging and organizing pages in an Azure DevOps Wiki

If you have set up an Azure DevOps Wiki, there are two ways to organize…

1 day ago

Rocket to the cloud: Anthos speeds Google’s rise in the enterprise market

Anthos is Google’s hybrid and multicloud platform. This platform is cloud-agnostic and has an incredible…

1 day ago