Outbound mail flow in Exchange Server 2013 is managed with the use of Send Connectors.
Send Connectors are not configured by default when you first install Exchange Server 2013.
If the Exchange 2013 server is installed in an existing organization
then other Send Connectors may already exist that facilitate outbound
mail flow. Otherwise, you will need to create at least one Send
Connector yourself.
Most organizations will be dealing with one of the following outbound email flow scenarios:
- email sent directly over the internet to the recipient’s server
- email sent to the internet via a smart host
There are other scenarios as well, such as:
- email sent outbound via an Edge Transport server
- email sent directly to a partner organization using TLS encryption
An organization can have one, two, or several Send Connectors to provide the specific email routing that they need.
For this article we’ll focus on the first two scenarios, as they are
the most common; sending directly to the internet, and sending via a
smart host. We’ll also cover testing and troubleshooting a Send
Connector, and some more advanced configuration options.
Configuring Outbound Mail Flow Direct to the Internet
Configuring your Exchange 2013 organization to send means that your Exchange server will look up the MX records for the recipient’s email address, and then use those MX records as the IP address(es) to connect to via SMTP.
Looking up MX records means your server will be relying on DNS. If
the server’s TCP/IP settings are configured for DNS servers inside your
network that can’t resolve external names, then you can configure Exchange to use different DNS servers for external lookups.
To create the Send Connector for sending outbound email directly to the internet open the Exchange Admin Center and navigate to Mail Flow -> Send Connectors.
Click the + button to create a new Send Connector.
Give the connector a name and set the type to Internet. Click Next to continue.
Leave the network settings set to MX record. If you needed to configure specific external DNS servers
you should also tick the box, but if your Exchange server can already
resolve external DNS names then that should not be required. Click Next to continue.
Click the + button to add a new address space. Specify the FQDN of * (the wildcard character that effectively means “anything”). The cost can remain at the default setting of 1 if this is the only send connector for your organization. Click Save and then click Next to continue.
Click the + button to add the source servers for the
connector. These are the servers that will be responsible for routing
email out from your organization to the internet. Multiple servers will
provide redundancy for outbound mail flow. Click OK and then click Finish.
The send connector is now visible in the Exchange Admin Center.
For further configuration and tested steps refer to the last section of this article.
Configuring Outbound Mail Flow via a Smart Host
Configuring a Send Connector to send outbound internet email via a
smart host is the same process as above, with the following differences.
First, the network setting is configured to Route mail through smart hosts
instead of MX records. You must then click the + button to add at least
one smart host name or IP address. Multiple smart hosts are permitted
and are recommended for redundancy.
When you choose to use a smart host you also get the option to
configure authentication for the Send Connector. This is only necessary
if the smart host requires it. Many email security servers/appliances or
even hosted solutions will simply authenticate you based on your IP
address rather than require other credentials.
Testing a New Send Connector
The obvious way to test a new send connector is to send an email from inside the organization to an external recipient.
When the message is received in the external mailbox you can then take the message headers and use the MXToolbox header analyzer or the ExRCA Message Analyzer
to inspect the headers and confirm that the email passed through the
source servers you were expecting it to for that outbound route.
If the email does not arrive you can inspect the transport queues on your Exchange servers for stuck email.
[PS] C:\>Get-TransportService | get-queue
Identity DeliveryType Status MessageCount Velocity RiskLevel OutboundIPPool NextHopDomain
-------- ------------ ------ ------------ -------- --------- -------------- -------------
E15MB1\22206 SmtpDeliv... Ready 0 0 Normal 0 mailbox database 1
E15MB1\Submission Undefined Ready 0 0 Normal 0 Submission
E15MB1\Shadow\22204 ShadowRed... Ready 0 0 Normal 0 e15mb3.exchange2013dem...
E15MB2\22750 SmtpDeliv... Ready 0 0 Normal 0 mailbox database 2
E15MB2\Submission Undefined Ready 0 0 Normal 0 Submission
E15MB2\Shadow\22748 ShadowRed... Ready 0 0 Normal 0 e15mb1.exchange2013dem...
E15MB3\Submission Undefined Ready 0 0 Normal 0 Submission
E15MB3\Shadow\16452 ShadowRed... Ready 1 0 Normal 0 e15mb1.exchange2013dem...
E15MB3\Shadow\16456 ShadowRed... Ready 1 0 Normal 0 e15mb2.exchange2013dem...
To look more closely at the messages stuck in a single queue you can use Get-Queue and Get-Message together.
[PS] C:\>Get-Queue E15MB1\22206 | Get-Message | ft
If the properties of the stuck messages do not reveal the problem
then another valuable source of troubleshooting information is the
protocol logs. For more tips refer to the following article:
Troubleshooting Email Delivery with Exchange Server Protocol Logging