In the world of Microsoft Exchange, there are two types of domains that the administrator must understand and configure accordingly: accepted domains and remote domains. Accepted domains are SMTP namespaces for which Exchange is allowed to send or receive email. In the case of receiving email, accepted domains also include those SMTP namespaces for which Exchange will receive a message yet continue to send it onwards to other external email systems. Remote domains are simply those SMTP namespaces that are external to Exchange.
Remote Domain Purpose
Broadly speaking, remote domains are used to control various aspects of messages sent to recipients in domains that are external to the local Exchange organization. Application of remote domain settings permit the following configurations to be applied to messages sent to the domain specified in the remote domain entry:
The types of messages that are to be sent to that domain. The typical configuration items here are where an administrator chooses whether to send Out of Office and automatic forwards to the remote domain, but there are other configuration options here as will be explained later in this article series
The message format. Remote domains offer several different configurable parameters that affect the message format, such as the Transport Neutral Encapsulation Format (TNEF) conversion settings and message encoding options that affect areas such as the MIME and non-MIME character sets and the line wrap size
Whether simple display names are sent or not. This is where the recipient sees the sender’s display name versus only seeing the sender’s SMTP address
The Default Remote Domain
By default, when Exchange 2013 is first installed, a single default remote domain is created. To view the properties of this remote domain, the Exchange Management Shell command to use is the Get-RemoteDomain command and as can be seen from Figure 1-1, the output of this command reveals that the default remote domain has a domain name parameter value of *. This value specifies all remote domains rather than any specific remote domain.
Figure 1-1: The Default Remote Domain
One important rule for Exchange administrators to remember here is that the default remote domain settings will always be used unless other specific remote domains have been configured. For example, the administrator may create a new remote domain for contoso.com in addition to the default remote domain. In this scenario, the settings configured in the contoso.com remote domain will be used for messages that are sent to recipients with contoso.com SMTP addresses, rather than the settings configured in the default remote domain. However, since no other specific remote domains have been created, the settings configured in the default remote domain will still be used for messages that are sent to recipients with SMTP addresses other than contoso.com, such as tailspintoys.com SMTP addresses for example.
Remote Domain Commands
There are only four Exchange Management Shell commands that are used for remote domain administration. They are:
Get-RemoteDomain. As seen in the previous section, this command is used to retrieve the settings of any existing remote domains
Set-RemoteDomain. This command is used to alter the parameters of any existing remote domains. Examples of using this command will be seen throughout this article series
New-RemoteDomain. The New-RemoteDomain command is used to create a new remote domain
Remove-RemoteDomain. This command is used to remove an existing remote domain entry
In the previous section, the example given was where an administrator created a new remote domain for contoso.com. To do this, it’s simply a case of running the New-RemoteDomain command and the required parameters. In fact, the only required parameters are the Name and DomainName parameters, as all other parameters are optional. For example, to create a new remote domain for contoso.com, the administrator could run the following command:
New-RemoteDomain -Name “Contoso” -DomainName contoso.com
To remove a remote domain, the administrator just needs to use the Remove-RemoteDomain command with the Identity parameter to identify the relevant remote domain to remove. Note that the value of the Identity parameter will correspond to the value of the Name parameter used to create the remote domain. It should also be noted that the default remote domain cannot be removed.
Controlling Out of Office Replies
Exchange 2013 supports both the internal and external types of Out of Office messages. Users get the option to specify whether their Out of Office message is sent to internal, external or both types of recipients, but the success of this Out of Office message transfer depends on what is permitted by the Exchange configuration. In Outlook Web App, the Out of Office message configuration choice is presented to users via the screen that can be seen below in Figure 1-2.
Figure 1-2: Setting Internal and External Out of Office Replies
An organization may choose to empower the users themselves with the decision of whether to send Out of Office messages to external recipients, or the remote domain may be configured by the administrator to block the sending of Out of Office messages to external recipients at that domain. External recipients in this scenario means recipients that have addresses from domains that are not configured as an accepted domain within the Exchange configuration. For example, consider the scenario where users in the Exchange organization for Fabrikam ordinarily have fabrikam.com SMTP addresses, but contoso.com has also been configured as an accepted domain to provide SMTP addresses for some users as part of a different brand requirement. External recipients in this scenario would be any recipients that have SMTP addresses other than fabrikam.com or contoso.com, such as tailspintoys.com for example.
To permit Out of Office replies to be sent to recipients from the tailspintoys.com domain, the Exchange administrator for Fabrikam would need to ensure that the remote domain applicable to tailspintoys.com would need to permit external Out of Office messages. The remote domain that applies to tailspintoys.com could be either the default * remote domain or a specific remote domain for tailspintoys.com. The remote domain parameter to view is the AllowedOOFType parameter, and this has a default value of External as can be seen from Figure 1-3. Here it can be seen that the Exchange administrator uses the following command to view the properties of the default * domain and filter for the AllowedOOFType parameter:
Get-RemoteDomain -Identity Default | fl *AllowedOOFType*
Figure 1-3: Default External Setting of AllowedOOFType
It may also be noticed that the AllowedOOFType parameter is displayed by default when viewing the properties of a remote domain, as can be seen earlier in Figure 1-1. Essentially, there is no real need to filter on the AllowedOOFType parameter when using the Get-RemoteDomain command.
A value of External means that the external Out of Office message will be sent to the specific remote domain. If an organization wants to send the internal Out of Office messages to remote domains, a value of Internal must be specified on that remote domain object. To block all Out of Office messages to the specific remote domain, the Exchange administrator can set the AllowedOOFType parameter to a value of None.
There are two other values for the AllowedOOFType parameter that reference legacy clients. The values of External and Internal relate to newer versions of the Outlook client. To consider Out of Office messages sent by clients running Outlook 2003 or earlier, the values of ExternalLegacy and InternalLegacy can be used. For example, suppose Fabrikam determines the requirement to send Out of Office messages from all versions of clients, including Outlook 2003, to all recipients in a specific remote domain. To permit this, the Exchange administrator for Fabrikam configures the specific remote domain such that the AllowedOOFType parameter is set to a value of ExternalLegacy. This is achieved using the following command:
Set-RemoteDomain -Identity Default -AllowedOOFType ExternalLegacy
Controlling Delivery / Non-Delivery Reports
Delivery and non-delivery reports can contain information about the recipients that are referenced in that report. Perhaps due to security, privacy or other reasons, organizations may desire to prevent this information from being sent to one or more remote domains. With the remote domain configuration, organizations have the ability to prevent delivery and non-delivery reports, and hence the information they contain, from being sent to recipients that are not part of the local Exchange organization. The remote domain parameters that control these settings are:
DeliveryReportEnabled
NDREnabled
Both of these parameters are enabled by default and hence both delivery and non-delivery reports will be sent to remote domain recipients. To disable either delivery or non-delivery reports from being sent to remote domain recipients, the Exchange administrator simply sets the required parameter to a value of $false. For example, to disable sending non-delivery reports to a remote domain for neilhobson.com recipients the Exchange administrator could use the following command:
This example assumes that the actual name of the remote domain object is neilhobson.com, in addition to neilhobson.com being the value of the RemoteDomain parameter.
As well as preventing the sending of non-delivery reports to remote domain recipients, Exchange 2013 permits another level of configuration on remote domains. There is another remote domain parameter that is useful for those organizations that want to continue to send non-delivery reports but want to restrict the amount of diagnostic information sent with those reports. This parameter is called NDRDiagnosticInfoEnabled and is enabled by default.
For example, consider the non-delivery report shown below. As can be seen at the bottom of the non-delivery report, the start of the diagnostic information is shown. This information includes details such as the original message headers. If the NDRDiagnosticInfoEnabled parameter is set to $false for that remote domain, Exchange limits the amount of diagnostic information sent with the non-delivery report. Specifically, although the ‘received’ message headers are still present in the non-delivery report, the elements of the headers that can contain details such as server names and IP addresses are stripped.
Controlling Automatic Replies and Forwards
Not to be confused with Out of Office messages, remote domains can also be used to control automatic replies sent by clients in the local Exchange organization. In addition, remote domains also support the ability to control automatic forwarding of messages to remote domain recipients.
Sometimes an organization may choose to send automatic replies to messages, perhaps from a shared mailbox such as a customer enquiry mailbox for example. Typically, the requirement is to send an automated response to customer messages to acknowledge the request and perhaps state an expected response time to the enquiry. One way of configuring these automatic replies is to use Outlook rules with the ‘have server reply with a specific message’ action applied to incoming messages. However, there may also be a requirement to prevent automatic replies from being sent to one or more remote domains. These options can be controlled via the AutoReplyEnabled parameter of the remote domain object. Like many parameters already discussed in this article, this parameter has a simple Boolean value, hence an example command to disable automatic replies to the neilhobson.com remote domain could be:
Also, an organization may choose to disable automatic forwards for one or more remote domains, perhaps to prevent users from automatically forwarding messages outside of the organization’s messaging system. Interestingly, it was noted that the AutoForwardEnabled parameter is set to $false by default for the default remote domain, yet is set to $true by default when creating a new remote domain as shown below.
Exchange administrators may need to watch for this when creating a new remote domain as it could produce unexpected results. For example, consider the scenario where an Exchange administrator has previously used the default remote domain’s AutoForwardEnabled parameter value of $false to prevent automatic forwards from being sent to any remote domain. The administrator may discover that automatic forwards are now sent to specific remote domain recipients after creation of that remote domain object in Exchange, unless the administrator remembers that the AutoForwardEnabled parameter for that specific remote domain must also be set to $false.
Controlling Display Name Sending
Another interesting aspect of remote domain configuration is the ability to control sending display names to recipients in remote domains. The display name is the recipient name that is seen in the Global Address List (GAL). The two configuration options for remote domain recipients are either to send the user’s display name as seen in the GAL, together with the SMTP address or just send a ‘simple’ display name. The simple display name option actually means remote domain recipients will only see the sender’s SMTP address rather than the SMTP address and GAL display name. Why might an organization need to disable sending display names to remote domain recipients? If an organization uses sensitive or private information in user’s display names, there may be a requirement for preventing that sensitive or private information from being sent externally.
The ability to disable the sending of display names to remote domain recipients is controlled by the UseSimpleDisplayName parameter on the remote domain settings. Display names are sent externally by default whereas simple display names are not, meaning that the default value of the UseSimpleDisplayName parameter is $false. Therefore, the alternative is to enable simple display names by setting the UseSimpleDisplayName parameter to a value of $true. An example of doing this is shown below, where it can be seen that the ‘simple’ display name is just the sender’s SMTP address rather than the full display name and SMTP address.
Controlling Message Formats and Their Per-User Settings
Remote domains permit the configuration of a wide variety of message format and encoding options, as well as Transport Neutral Encapsulation Format (TNEF) conversion options. This is a complex area that likely warrants a dedicated article, but a brief description of the options available follows. However, the administrator should take the time to research these configuration options further if they are not familiar with them.
The ContentType parameter of the Set-RemoteDomain cmdlet controls whether messages for remote domain recipients are converted to text or HTML formatted MIME messages and hence it’s possible that an administrator may need to configure a specific remote domain for MIME messages that use text formatting only. The CharacterSet parameter controls MIME message character sets used for messages that do not already have a character set applied, while the NonMimeCharacterSet parameter controls character sets for messages that do not have a MIME character set applied.
One key configuration area that an Exchange administrator should be aware of with regards to remote domains and message formats is that several message format configuration elements can be applied on a per-user basis. In these cases, these per-user settings override the corresponding values that are applied to the remote domain. When the term ‘per-user’ is used here, it means settings that are configured against mail-enabled contacts or mail-enabled user objects.
For example, when examining the properties of a mail-enabled contact by using the Get-MailContact cmdlet, it can be seen that there are four parameters that deal with the application of message formatting options for that contact. These parameters are MacAttachmentFormat, MessageBodyFormat, MessageFormat and UsePreferMessageFormat. It’s the UsePreferMessageFormat Boolean value parameter that specifies whether the message format settings to be used should be those specified in the remote domain ($false) or those specified in the mail-enabled contact ($true). The MessageBodyFormat parameter controls whether text, HTML or both can be used to send to the remote recipient.
Therefore, if the administrator wants to ensure that messages to a particular remote recipient are always sent using text rather than HTML, the administrator would set the following two configuration options using the Set-MailContact cmdlet:
UsePreferMessageFormat to $true
MessageBodyFormat to ‘text’
The MessageFormat parameter is used to control whether text or MIME is used as the message format, while the MacAttachmentFormat is used to control the attachment format of messages in the Apple Mac operating system. For full details of all parameter settings, see the Set-MailContact documentation on TechNet.
Summary
Remote domains are one of those essential configuration elements for Exchange 2013 that administrators may need to review and/or change from time to time. Not all configuration options will necessarily be used but nevertheless, administrators should be fully aware of the available options for possible future use.