Resources for IT Professionals
Managing Accepted Domains

Applies to: Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007 Topic Last Modified: 2007-08-14

An accepted domain is any Simple Mail Transfer Protocol (SMTP) namespace for which a Microsoft Exchange organization sends or receives e-mail. Accepted domains include those domains for which the Exchange organization is authoritative. An Exchange organization is authoritative when it handles mail delivery for recipients in the accepted domain. Accepted domains also include domains for which the Exchange organization receives mail and then relays it to an e-mail server that is outside the Active Directory directory service forest for delivery to the recipient.

 Configuring Accepted Domains

Accepted domains are configured as global settings for the Exchange organization and on computers that have the Edge Transport server role installed. The organizational settings require that all domains for which computers that have the Hub Transport server role installed process messages are configured as accepted domains. The Edge Transport server requires that all domains for which it accepts and relays messages are configured as accepted domains.

We recommend that you create and manage all accepted domains inside the organization and synchronize that information to the Edge Transport server by creating an Edge Subscription. When you subscribe the Edge Transport server to the Exchange 2007 organization, all accepted domains that are configured in the organizational settings for the Hub Transport server role are replicated to the Edge Transport server during EdgeSync synchronization. To modify the accepted domain configuration on an Edge Transport server that is subscribed to the Exchange 2007 organization, you must make the change on the Hub Transport server.

There are three types of accepted domains: authoritative, internal relay, and external relay. These accepted domain types are described in the following sections.
 Authoritative Domains

An organization may have more than one SMTP domain. The set of e-mail domains for an organization are the authoritative domains. In Exchange 2007, an accepted domain is considered authoritative when the Exchange organization hosts mailboxes for recipients in this SMTP domain. The Edge Transport servers should always accept e-mail that is addressed to any of the organization's authoritative domains.

By default, when the first Hub Transport server role is installed, one accepted domain is configured as authoritative for the Exchange organization. The default accepted domain is the fully qualified domain name (FQDN) for your forest root domain. Frequently, the internal domain name differs from the external domain name. For example, your internal domain name may be domain.local, although your external domain name is domain.com. The domain name system (DNS) MX resource record for your organization references domain.com. Domain.com is the SMTP namespace that you assign to users when you create an e-mail address policy. You must create an accepted domain to match your external domain name.

By default, no accepted domains are configured on the Edge Transport server role.
 Relay Domains

When e-mail is received from the Internet by an Edge Transport server and the recipient of the message is not a part of an authoritative domain, the sending server tries to relay through the Exchange server. When a server acts as a relay server that has no restrictions, it can put a large burden on Internet-connected servers. Administrators can prevent this open relay scenario by rejecting all e-mail that is not addressed to a recipient in the organization's authoritative domains. However, there are scenarios where an organization wants to let partners or subsidiaries relay e-mail through the Exchange servers. In Exchange 2007, you can configure accepted domains as relay domains. Your organization receives the e-mail and then relays the messages to another e-mail server.

You can configure a relay domain as an internal relay domain or as an external relay domain. These two relay domain types are described in the following sections.

 Internal Relay Domain

When you configure an internal relay domain, some or all of the recipients in this domain do not have mailboxes in this Exchange organization. Mail from the Internet is relayed for this domain through Hub Transport servers in this Exchange organization. This configuration is used in the scenarios that are described in this section.

An organization may have to share the same SMTP address space between two or more different e-mail systems. For example, you may have to share the SMTP address space between Microsoft Exchange and a third-party e-mail system, or between Exchange environments that are configured in different Active Directory forests. In these scenarios, users in each e-mail system have the same domain suffix as part of their e-mail addresses.

To support these scenarios, you must create an accepted domain that is configured as an internal relay domain. You must also add a Send connector that is sourced on a Hub Transport server and configured to send e-mail to the shared address space. If an accepted domain is configured as authoritative and a recipient is not found in the Active Directory directory service, a non-delivery report (NDR) is returned to the sender. The accepted domain that is configured as an internal relay domain first tries to deliver to a recipient in the Exchange organization. If the recipient is not found, the message is routed to the Send connector that has the closest address space match.

If an organization contains more than one forest and has configured GAL synchronization, the SMTP domain for one forest may be configured as an internal relay domain in a second forest. Messages from the Internet that are addressed to recipients in internal relay domains are received and processed by the Edge Transport server and then relayed to the Hub Transport servers in the same organization. The receiving Hub Transport servers then route the messages to the Hub Transport servers in the recipient forest. You configure the SMTP domain as an internal relay domain to make sure that e-mail that is addressed to that domain is accepted by the Exchange organization. The connector configuration of your organization determines how messages are routed.

In Figure 1, FourthCoffee.com is configured as an internal relay domain for the Exchange 2007 organization in the Contoso.com forest. The MX resource records for FourthCoffee.com reference a public IP address for the Contoso.com organization. A forest trust exists between FourthCoffee.com and Contoso.com, and GAL synchronization is configured. The Contoso.com Edge Transport server accepts messages for the FourthCoffee.com SMTP domain from the Internet and then relays those messages to the Hub Transport servers in the Contoso.com Exchange organization. The messages are then routed to the Hub Transport servers in the FourthCoffee.com Exchange organization. A cross-forest Send connector is configured for routing messages from Contoso.com to FourthCoffee.com. Messages that are sent from FourthCoffee.com to external recipients are routed to the Hub Transport servers in the Contoso.com forest. A second cross-forest Send connector is configured for routing messages from FourthCoffee.com to Contoso.com. When the Hub Transport servers in Contoso.com receive messages from the internal relay domain FourthCoffee.com, they deliver messages for recipients in authoritative domains and relay messages for Internet recipients to the Edge Transport server for delivery.

Figure 1   Configuration of an internal relay domain
Configuration of Internal Relay Domain
 External Relay Domain

When you configure an external relay domain, messages are relayed to an e-mail server that is outside the Exchange organization and outside the organization's network perimeter. The messages are relayed by the Edge Transport server.

In this scenario, the MX resource record for the external relay domain references a public IP address the Exchange 2007 organization that is relaying messages. The Edge Transport server receives the messages for recipients in the external relay domain and then routes the messages to the e-mail system for the external relay domain. A Send connector from the Edge Transport server to the external relay domain is required in this scenario. The external relay domain may also use your organization's Edge Transport server as a smart host for outgoing mail.

In Figure 2, Adatum.com is configured as an external relay domain for the Exchange 2007 organization in the Contoso.com forest. The MX resource record for Adatum.com references a public IP address for the Contoso.com organization. The Contoso.com Edge Transport server accepts messages for the Adatum.com SMTP domain from the Internet and then relays those messages to the e-mail servers in the Adatum.com organization. Adatum.com also uses the Contoso.com Edge Transport server as a smart host for routing outgoing messages. Messages that are sent from Adatum.com to external recipients are routed to the Edge Transport servers in the Contoso.com organization. When the Edge Transport servers in Contoso.com receive messages from Adatum.com, they deliver messages for recipients in authoritative domains and internal relay domains to the Hub Transport servers and route messages to the Internet.

Figure 2   Configuration of an external relay domain
Configuration of External Relay Domain
 Accepted Domains and E-Mail Address Policies

You must configure an accepted domain before that SMTP address space can be used in an e-mail address policy. When you create an accepted domain, you can use a wildcard character in the address space to indicate that all subdomains of the SMTP address space are also accepted by the Exchange organization. For example, to configure Contoso.com and all its subdomains as accepted domains, enter *.Contoso.com as the SMTP address space. The accepted domain entries are automatically available for use in an e-mail address policy.

If you delete an accepted domain that is used in an e-mail address policy, the policy is no longer valid, and recipients with e-mail addresses in that SMTP domain will be unable to send or receive e-mail.
 For More Information
Page view tracker