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...
[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:
Further Configuration Options for Send Connectors
Some additional configuration options you can explore are:
- Proxying email through Front End/Client Access Servers
- Configuring protocol logging for Exchange 2013
- Configuring outbound message size limits for Exchange 2013
- Configuring the FQDN for HELO/EHLO on a send connector