Exchange 2010 transport servers require Send connectors to deliver messages to the next hop on the way to their destination. A Send connector controls outbound connections from the sending server to the receiving server or destination e-mail system. By default, no explicit Send connectors are created when the Hub Transport server role or the Edge Transport server role is installed. However, implicit and invisible Send connectors that are automatically computed based on the Active Directory site topology are used to route messages internally between Hub Transport servers. End-to-end mail flow is only possible after the Edge Transport server has been subscribed to the Active Directory site by using the Edge Subscription process. Other scenarios, such as an Internet-facing Hub Transport server or an unsubscribed Edge Transport server, require manual configuration of connectors to establish end-to-end mail flow. For more information, see Transport Server Post-Deployment Tasks.

Send connectors that are created on Hub Transport servers are stored in Active Directory and are available to all Hub Transport servers in the organization. If a Send connector is configured to send messages to an external domain, any Hub Transport server in the organization will route a message for that domain to a source server for that connector to be relayed to the destination domain.

The Send connector that's used to route messages to a recipient is selected during the routing resolution phase of message categorization. For more information, see Understanding Message Routing.

When you use the Exchange Management Console (EMC) to create a Send connector, the New SMTP Send Connector wizard prompts you to select a usage type for the connector. The usage type determines the default permission sets that are assigned on the connector and grants those permissions to trusted security principals. Security principals include users, computers, and security groups. A security principal is identified by a security identifier (SID).

You can also specify a usage type when you create a Send connector by using the New-SendConnector cmdlet in the Exchange Management Shell. However, the Usage parameter isn't required. If you don't specify a usage type when you run the New-SendConnector cmdlet, the default usage type is set to Custom. The following table describes the Send connector usage types and their default settings.

Send connector usage types

Note:
If Domain Name System (DNS) resolution delivery is selected for a Send connector instead of a smart host, no smart host authentication mechanism is configured.

The Send connector permissions and smart host authentication mechanisms are discussed in detail later in this topic.

 Send Connector Usage Scenarios

Each usage type is appropriate for a specific connection scenario. Select the usage type that has the default settings most applicable to the configuration that you want. You can modify permissions by using the Add-ADPermission and Remove-ADPermission cmdlets. For more information, see the following topics:

• Add-ADPermission
  
• Remove-ADPermission
  

The following table lists common connection scenarios and the usage type for each scenario.

Connector usage scenarios

Connector scenario	Usage type	Comment
Edge Transport server that sends e-mail to the Internet	Internet	A Send connector that's configured to send e-mail to all domains is created automatically when the Edge Transport server is subscribed to the Exchange organization.
Hub Transport server that sends e-mail to the Internet	Internet	This isn't a recommended configuration.
A subscribed Edge Transport server that sends e-mail to a Hub Transport server	Internal	This connector is automatically created by the Edge Subscription process.
Edge Transport server that sends e-mail to an Exchange 2003 bridgehead server	Internal	The Exchange 2003 bridgehead server is configured as a smart host for the Send connector.
Edge Transport server that sends e-mail to a Hub Transport server	Custom	When the Edge Subscription process isn't used, a manual connector must be created. Use the Add-ADPermission cmdlet to set the extended rights. Set the authentication mechanism as Basic authentication or Externally Secured.
Cross-forest Send connector for a Hub Transport server in one forest that sends e-mail to an Exchange 2010 or Exchange 2007 Hub Transport server in a second forest	Custom	For detailed configuration steps, see Configure Cross-Forest Connectors.
Cross-forest Send connector for a Hub Transport server in one forest that sends e-mail to an Exchange 2003 bridgehead server in a second forest	Custom	For detailed configuration steps, see Configure Cross-Forest Connectors.
Hub Transport server that sends e-mail to a third-party smart host	Custom	Use the Add-ADPermission cmdlet to set the extended rights. Route all messages to a smart host and set the authentication mechanism to either Basic authentication or Externally Secured.
Edge Transport server that sends e-mail to a third-party smart host	Custom	Use the Add-ADPermission cmdlet to set the extended rights. Route all messages to a smart host and set the authentication mechanism to either Basic authentication or Externally Secured.
Edge Transport server that sends e-mail to an external relay domain	Custom	The Edge Transport server can accept e-mail for an external relay domain and then relay the messages to the authoritative e-mail system for that domain. Route all messages to a smart host, set the appropriate authentication mechanism, and use the Add-ADPermission cmdlet to set the extended rights.
Edge Transport server that sends e-mail to a domain to which you have established mutual TLS authentication	Partner	Mutual TLS authentication functions correctly only if the following conditions are true: The value of the DomainSecureEnabled parameter must be $true. The value of the DNSRoutingEnabled parameter must be $true. The value of the IgnoreStartTLS parameter must be $false. For more information, see Set-SendConnector.

You assign Send connector permissions to a security principal. When a security principal establishes a session with a Send connector, the Send connector permissions determine the types of header information that can be sent with the e-mail message. If an e-mail message includes header information that isn't allowed by the Send connector permissions, those headers are stripped from the message when it's sent. The following table describes the permissions that can be assigned on a Send connector to security principals. You can't set Send connector permissions by using the EMC. To modify the default permissions for a Send connector, you must use the Add-ADPermission cmdlet in the Shell.

Send connector permissions

The address space for a Send connector specifies the recipient domains to which the Send connector will route e-mail. You can specify SMTP address spaces or non-SMTP address spaces on Send connectors that are configured on Hub Transport servers. You can only specify SMTP address spaces on Send connectors that are configured on Edge Transport servers. If you use a non-SMTP address space type, you must use a smart host to route e-mail.

Note:

Although you can configure non-SMTP address spaces on a Send connector on a Hub Transport server, the Send connector uses SMTP as the transport mechanism to send messages to other messaging servers. Delivery Agent connectors and foreign connectors on Hub Transport servers are used to send messages to non-SMTP local messaging servers, such as third-party fax gateway servers. For more information, see Understanding Delivery Agents and Understanding Foreign Connectors.

The following table lists valid entries for the SMTP address space of a Send connector.

Valid entries for the SMTP address space of a Send connector

During routing resolution, a Send connector, to which e-mail is routed for delivery to the destination address space, is selected. The Send connector whose address space most closely matches the recipient's e-mail address is selected. For example, an e-mail message addressed to Recipient@marketing.contoso.com would be routed through the connector that's configured to use the *.Contoso.com address space. When you configure a Send connector for a particular address space, e-mail sent to that address space is always routed through that connector. Also, the configuration settings for that connector are always applied to e-mail sent to that address space.

You can use the scope of a Send connector to control the visibility of the Send connector within the Exchange organization. By default, all Send connectors that you create are usable by all the Hub Transport servers in the Exchange organization. However, you can limit the scope of any Send connector so that it's only usable by other Hub Transport servers that exist in the same Active Directory site.

In Exchange 2010, the complete syntax for specifying an address space is as follows:

<AddressSpaceType>:<AddressSpace>;<AddressSpaceCost>

You can use the following methods to specify the scope of the Send connector:

• In the EMC, use the Scoped Send connector property in the Address Space page of the New SMTP Send Connector wizard, or in the Address Space tab in the properties of an existing Send connector.
  When Scoped Send connector is selected, the connector can only be used by Hub Transport servers in the same Active Directory site. When Scoped Send connector isn't selected, the connector can be used by all Hub Transport servers in the Exchange organization.
  
• In the Shell, use the IsScopedConnector parameter in the New-SendConnector cmdlet or the Set-SendConnector cmdlet.
  When the value of this parameter is $true, the connector can only be used by Hub Transport servers in the same Active Directory site. When the value of this parameter is $false, the connector can be used by all Hub Transport servers in the Exchange organization.
  

You can set Send connectors so that they deliver e-mail by using DNS address resolution or by routing the e-mail to a smart host.

 Using DNS to Route E-Mail

When the Send connector is set to use DNS MX resource records to route mail automatically, the DNS client on the source server must be able to resolve public DNS records. By default, the DNS server that's configured on the source server's internal network adapter is used for name resolution. You can configure a specific DNS server to use for internal and external DNS lookups by using the EMC to modify the DNS settings on the Exchange server properties. You can also use the Shell to configure the parameters in the Set-TransportServer cmdlet.

If you configure a specific DNS server on the transport server to use for external DNS lookups, you must select Use the external DNS lookup settings on the transport server on the Network Settings page of the New SMTP Send Connector wizard or, in the Shell, on the Set-TransportServer cmdlet, set the UseExternalDNSServersEnabled parameter to $true. The DnsRoutingEnabled parameter on the Send connector must also be set to $true.

For more information, see the following topics:

• Configure Edge Transport Server Properties
  
• Configure Hub Transport Server Properties
  
• Set-TransportServer
  

 Using a Smart Host to Route E-Mail

If you select the Internal usage type for the Send connector, you must specify a smart host. When you route mail through a smart host, the smart host handles delivery to the next hop in the delivery destination. You can use an IP address or the fully qualified domain name (FQDN) of the smart host to specify the smart host identity. The smart host identity can be the FQDN of a smart host server, an MX record, or an A (address) resource record. If you configure an FQDN as the smart host identity, the source server for the Send connector must be able to use DNS name resolution to locate the smart host server.

The smart host for a Send connector with the Internet usage type may be a server that's hosted by your Internet service provider. The smart host for a Send Connector with the Custom or Internal usage types may be another e-mail server in your organization or an e-mail server in a remote domain.

 Smart Host Security Settings

When you route mail through a smart host, you must specify how the source server will authenticate to the smart host computer. You can't require security settings for a Send connector unless a smart host destination is specified. For example, an Internet-facing connector can't be set to require TLS.

The following table lists the smart host authentication mechanism that you can configure for a Send connector.

Smart host authentication mechanisms

Security setting	Description
None	Anonymous access is allowed.
Basic authentication	Basic authentication requires that you provide a user name and password. Basic authentication sends credentials in clear text. All smart hosts with which this Send connector is authenticating must accept the same user name and password.
Basic authentication over TLS	Select TLS to encrypt the transmission of the credentials. The receiving server must have a server certificate. The exact FQDN of the smart host, MX record, or A record that's defined on the Send connector as the smart host identity must also exist in the server certificate. The Send connector will attempt to establish the TLS session by sending the STARTTLS verb to the destination server and will only perform Basic authentication after the TLS session has been established. A client certificate is also required to support mutual TLS authentication.
Exchange Server authentication	Exchange Server authentication (Generic Security Services application programming interface (GSSAPI) and Mutual GSSAPI)
Externally Secured (for example, with IPsec)	The network connection is secured using a method that's external to the Exchange server.

You must select at least one source server for a Send connector. The source server is the transport server to which messages are routed for delivery through the selected Send connector. You can set more than one source server on a Send connector that's configured for the Exchange organization. When you specify more than one source server, you provide load balancing and redundancy if a server fails. The source servers associated with Send connectors that are configured for the Exchange organization can be Hub Transport servers or subscribed Edge Transport servers.

The General tab of the Send connector properties in the EMC includes the option Specify the FQDN this connector will provide in response to HELO or EHLO. In the Shell, this property is set by using the Fqdn parameter with the Set-SendConnector cmdlet. After an SMTP session is established, an SMTP protocol conversation starts between a sending e-mail server and a receiving e-mail server. The sending e-mail server or client sends the EHLO or HELO SMTP command and its FQDN to the receiving server. In response, the receiving server sends a success code and provides its own FQDN. In Exchange 2010, you can customize the FQDN that's provided by the sending server if you configure this property on a Send connector. The value of the Fqdn parameter is displayed to connected messaging servers whenever a source server name is required, as in the following examples:

• In the most recent Received: header field of the message that's added to the message by the next hop messaging server after the message leaves the Hub Transport server or Edge Transport server
  
• During TLS authentication
  

If the Send connector is configured on a Hub Transport server that also has the Mailbox server role installed, any value that you specify for the Fqdn parameter isn't used. Instead, the FQDN of the server that's displayed by using the Get-ExchangeServer cmdlet is always used.

For servers that have both the Hub Transport server role and the Mailbox server role installed, the only way to remove the server name from the Received: headers of the outgoing message is to use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Headers-Routing permission from the security principals that use the connector. This action will remove all the Received: headers from the message as the message leaves the Hub Transport server. We recommend that you don't remove the Received: headers for internal messages, because the Received: headers are used for maximum hop count calculations. For more information about the Remove-ADPermission cmdlet and the Get-ExchangeServer cmdlet, see the following topics:

• Remove-ADPermission
  
• Get-ExchangeServer
  

The property configuration for a Send connector defines how mail is sent through that connector. Not all properties are configurable in the EMC. For more information about the properties that can be configured by using the Shell, see Set-SendConnector.