If you would like to read the next part in this article series please go to Accepted Domains (Part 2).
Introduction
We quite often think of the term namespace when planning our Client Access server infrastructure, but there is also the namespace regarding the Simple Mail Transfer Protocol (SMTP) to consider. After all, if you are creating your Exchange 2010 infrastructure, there’s a strong likelihood that you’ll want that infrastructure to receive SMTP messages from Internet-based recipients and that’s where accepted domains, amongst other things, come in.
Simply put, an accepted domain is the SMTP namespace for which Exchange 2010 is allowed to receive email. By creating an accepted domain within the Exchange 2010 configuration, we are telling the Exchange 2010 environment that it is allowed to receive SMTP messages destined for users with that domain name in their email addresses.
In Exchange 2010 there are three types of accepted domains and we will be taking a look at these within this article series. We will also be looking at how to create them and why three different types of accepted domains exist.
The Default Accepted Domain
You will see accepted domains in two places within an Exchange 2010 infrastructure:
- On the Accepted Domains tab of the Hub Transport node under the Organization Configuration node in the Exchange Management Console running against the internal Exchange 2010 organization
- On the Accepted Domains tab of the Edge Transport node in the Exchange Management Console running on the Edge Transport server role.
Figure 1-1 shows the Accepted Domains tab as seen in the Exchange Management Console when viewing the internal Exchange 2010 infrastructure. As you can see, there is a single accepted domain configured for the SMTP domain neilhobson.com.
Figure 1-1: Accepted Domains in the Exchange Management Console
How was this accepted domain created? As you can see from Figure 1-1, the action pane of the Exchange Management Console allows for the creation of accepted domains via the New Accepted Domain action.
However, in this particular example, the accepted domain that you can see was not actually created by an administrator. Rather, what you can see is the default accepted domain that is created when you install Exchange 2010. Specifically, this accepted domain was created when the first Hub Transport server role was installed. We will be looking more at what this means for the Exchange configuration as we go through this article.
You can see from Figure 1-1 that the Type column reveals that the default accepted domain is an authoritative accepted domain. In fact, there are two other types of accepted domain, namely internal relay accepted domains and external relay accepted domains. Let’s now have a look at authoritative accepted domains; we will cover internal and external relay domains in part two.
Authoritative Domains
Authoritative accepted domains are the most typical accepted domain and one that we are all generally familiar with. The reason for this is because you use authoritative accepted domains to indicate the fact that you have mailboxes in your Exchange organization that have SMTP addresses matching the accepted domain. For example, if I wanted an SMTP address on a mailbox that ends with the domain name of neilhobson.com, I must ensure that neilhobson.com is configured as an authoritative accepted domain. This instructs Exchange 2010 to receive emails that are sent to the domain neilhobson.com. If an email arrives for an SMTP address in the neilhobson.com SMTP domain but that SMTP address does not exist on any object within the Exchange organization, a non-delivery report will be issued.
The Exchange 2010 Hub Transport installation process creates the default authoritative accepted domain as you saw earlier in Figure 1-1. You might now be wondering how the Hub Transport installation program knew to use the domain name neilhobson.com as the default authoritative accepted domain. What actually happens here is that the Hub Transport installation program automatically configures the default accepted domain based on the name of the forest root domain. Therefore, since my forest root domain was neilhobson.com, the same accepted domain name was created.
An observation to make here is the situation where the forest root domain name is different to the external SMTP domain name. For example, consider the situation if I had created my Active Directory forest root domain as neilhobson.local or other such similar variation, but my external SMTP namespace was neilhobson.com. In this case, the Hub Transport installation program would have automatically created a default authoritative accepted domain of neilhobson.local; I would therefore need to create a new authoritative accepted domain for neilhobson.com.
Creating a New Authoritative Accepted Domain
What if we need to create a new authoritative accepted domain? Or consider the scenario where your Exchange organization is responsible for different SMTP namespaces and therefore contains mailboxes with different SMTP addresses. In this case, you will of course need to create additional authoritative accepted domains as required. Creating these accepted domains is really easy. In the Exchange Management Console navigate to the Organization Configuration node, then to the Hub Transport node. With the Accepted Domains tab highlighted, select the New Accepted Domain option from the action pane. This brings up the New Accepted Domain wizard as you can see in Figure 1-2 and in this example I’ve elected to configure neilhobson.com as an authoritative accepted domain.
Figure 1-2: Creating a New Authoritative Accepted Domain
The same result can be achieved using the Exchange Management Shell and the New-AcceptedDomain cmdlet. If you just run the New-AcceptedDomain cmdlet without any additional parameters, you will see that the required parameters are Name and DomainName; these parameters correspond to the fields titled Name and AcceptedDomain that you can see in Figure 1-2. By default, the New-AcceptedDomain cmdlet will create an authoritative accepted domain unless you override this by using the DomainType parameter. For example, the following command creates a new internal relay accepted domain for nghcloud.co.uk. We will be looking at the internal relay accepted domain in part two of this article series.
New-AcceptedDomain –Name nghcloud.co.uk –DomainName nghcloud.co.uk –DomainType InternalRelay
We stated earlier that the Hub Transport installation process creates a default authoritative accepted domain. This is not true for the Edge Transport server role however, as no accepted domains are created by default. You can see this in Figure 1-3 which shows the Accepted Domains tab on a brand new installation of the Edge Transport server role.
Figure 1-3: Accepted Domains on an Edge Transport Server
If the Edge Transport server is subscribed to the Exchange 2010 organization, the accepted domain information from the Exchange 2010 organization is synchronized to the Edge Transport server. However, remember that any changes that are required to the accepted domain information must be made at the Exchange 2010 organization level; these changes are then synchronized to the Edge Transport server by the Edge synchronization process. If, for whatever reason, you have not used the Edge synchronization process, you will need to create the accepted domain on both the Edge Transport server and the Exchange 2010 organization. This creation process has been described previously within this article.
Email Address Policies
Email Address Policies in Exchange 2010 are linked to accepted domains in that before you can create an Email Address Policy that uses the required SMTP namespace, you must create the accepted domain with that same namespace. You can see this in Figure 1-4 where the currently defined accepted domains are displayed when clicking the Browse button in the SMTP E-mail Address window.
Figure 1-4: Email Address Policies and Accepted Domains
Summary
That completes part one of this article on accepted domains in Exchange 2010, where we have concentrated on authoritative accepted domains. In the second and final part of this article series, we will be looking at internal and external relay domains and what their intended use is.
If you would like to read the next part in this article series please go to Accepted Domains (Part 2).
